Hi,
Rick Kenney has fixed the Foxwiki plugin available in our sandbox (it
was initially created by Robin Fernandes - Site is here: http://
soal.xwiki.com/xwiki/bin/view/Code/FoXWiki).
Rick has tried to contact Robin without success so far. We need to
find out under what license it is. But assuming the license is
correct and Robin agrees, I'd like us to vote on including it as part
of our releases. This means we are agreeing to maintaining it.
Rick has agreed to maintain it, so if we agree I'll vote to get him
write access to it so that he can be the maintainer for it.
If we agree on this, I propose the following:
1) Rick creates a JIRA issue in the XWiki Platform project for now,
component "Other" and attach his working version to it
2) I create the extension area for foxwiki in our SVN and apply your
patch there. I had already proposed such an area which we also need
for the Eclipse integration.
3) I also create the maven build for it so that it can be built as
part of our CI
4) I create a JIRA project for it and move your issue to it
5) I do a release of it (version 1.0) with maven in our remote maven
repo
6) I create an extension page for it on xwiki.org (in the Code Zone,
Extension section) and link to the download location on our remote
maven repo
7) I create a blog post on xwiki.org to announce the new project and
the availability of the 1.0 version
8) From there on, people create JIRA issues for it in its jira
project and Rick acts on them. I can act as the release manager
whenever a new version is ready
Here's my +1 for both including Foxwiki and voting Rick as committer
for *that* project only.
Thanks
-Vincent
Hi developers,
I'm on semi-holiday next week and I'll have only limited internet
connectivity so it's going to be difficult to upload the 500MB that
are required when performing a release. I can see 3 options:
1) Someone else does the release
2) I do the release on this coming Friday (the 27th)
3) We postpone by one week the release (6th of August)
As 1.1M4 is our last release before the RCs start, I think the best
is to postpone it by one week so that we have more time to add new
features into it. However I'd like the 1.1M5 (to be renamed 1.1RC1)
to remain slated for the 20th of August.
So here's my +1 for postponing by 1 week the 1.1M4 release (unless
someone else want to do the release but I doubt it :)).
Thanks
-Vincent
Hello all
I am currently working as Engineer in INRIA and we are working on
XWIKI.When i want to get XWiki source using Console of my linux , i
provided following coomand
svn co svn://svn.forge.objectweb.org/svnroot/xwiki/trunks-devs
But if require a password from me.Can you tell me please what is password
for it?
Waiting for Answer
Sarfraz
Inria , France
Hi All,
We were silent for few days due to mid-semester work load (still have some
unfinished business). Anyway, I have added the removeSpace RPC to xwiki
back-end. But now i'm having few doubts about it. The remove space RPC works
by retrieving all the page names under the given space and deleting them
individually. But following complications may happen when using this RPC,
1. If the user does not have enough privileges to delete some of the pages
within that space, an exception will be thrown half-way down. Now the RPC
invoker does not know which pages were removed and which were not. (Thus, he
is out of sync with the wiki)
2. If instead we chose to remove page by page from the client - Xeclipse
(say), we don't have this problem , and we could even display a progress
bar. (to indicate that pages are being deleted).
Since the XML RPC API requires the removeSpace() RPC, we must indeed add it.
But wouldn't it be better if we do not use this RPC within Xeclipse (due to
reasons mentioned above) ?
Or, is there a better way to implement removeSpace() RPC ? (like checking
privileges before doing anything ?) ) (+ How ? )
Thanks a lot.
Best Regards,
- Asiri
Hi Catalin,
On Jul 25, 2007, at 12:25 PM, Catalin Hritcu wrote:
> Author: hritcu
> Date: 2007-07-25 12:25:45 +0200 (Wed, 25 Jul 2007)
> New Revision: 4023
>
> Modified:
> xwiki-products/xwiki-enterprise/trunk/distribution-test/src/test/
> it/com/xpn/xwiki/it/DeletePageTest.java
> Log:
> Test for the presence of bug XWIKI-1388 (the test currently fails)
>
> Modified: xwiki-products/xwiki-enterprise/trunk/distribution-test/
> src/test/it/com/xpn/xwiki/it/DeletePageTest.java
> ===================================================================
> --- xwiki-products/xwiki-enterprise/trunk/distribution-test/src/
> test/it/com/xpn/xwiki/it/DeletePageTest.java 2007-07-25 08:45:50
> UTC (rev 4022)
> +++ xwiki-products/xwiki-enterprise/trunk/distribution-test/src/
> test/it/com/xpn/xwiki/it/DeletePageTest.java 2007-07-25 10:25:45
> UTC (rev 4023)
> @@ -109,6 +109,18 @@
> }
> }
>
> + /*
> + * This tests for regression of XWIKI-1388
> + */
This should be a javadoc I think.
> + public void testUserStaysLoggedInWhileDeleting()
> + {
> + logInAndCreatePageToBeDeleted("DeleteTest");
> + clickDeletePage();
> +
> + assertTrue("The interface should not show the user as
> logged out while deleting",
> + isAuthenticated());
> + }
> +
I don't think we should commit test that make the build fail. We
should commit them at the same time as we commit the fix IMO. When
you don't have the implementation ready, then I suggest putting them
in the JIRA issue related to the problem. That's what I did in the past.
WDYT?
Thanks
-Vincent
Hi,
I checkouted "trunks-users" on Windows XP with TortoiseSVN and see
that some files mark has modified or non versioned. I checked with
Repo-browser (tools provided by TortoiseSVN) and see that theses
problems appear with files containing a blank at the end. Theses names
are not supported by Windows that automatically delete all ending
blanks.
It can be corrected with mentioned Repo-browser or on system that
support blank ending files names.
--
Thomas Mortagne
Hi all,
The 1.1 deadline is approaching fast, and we still have a lot of
issues marked as bugs, and 2.0 is contouring very slowly. Thus, I
think we will need to decide whether we will have other 1.x releases
or start working on 2.0
Here are some factors I see:
- 2.0 will be mostly a rewrite from scratch, so all the existing bugs
will probably be fixed in 2.0
- Since there will be many differences between 2.0 and 1.x, we should
have a 1.x version without major known bugs, for those that don't want
to upgrade to 2.0
- We have a limited manpower, so working on both branches will be hard
- We will (probably) hire some new developers in the near future, so
we could split the people in two branches, if we must
- 2.0 will offer many new features that people are already asking for,
so we shouldn't delay it much longer.
I think we should make XWiki 1.2, but not more.
Sergiu
--
http://purl.org/net/sergiu
For those interested I've sent a patch for implementing a new
notification mechanism.
It's available here:
http://jira.xwiki.org/jira/browse/XWIKI-1522
I'd love to get feedback on this. Here's what I say in there:
"
At the place where you want to register for an event:
getObservationManager().addListener(new DocumentSaveEvent
("DocumentToWatch"), listener);
At the place where you want to receive for an event:
public class MyListener implements EventListener
{
public void onEvent(Event event, Object source, Object data)
{
...
}
}
At the place where you want to fire notifications to event listeners:
getObservationManager().notify(new DocumentSaveEvent("SomeDocument"),
"some source", "some data");
It's easily extensible and you can create all sorts of events as it's
fully generic.
"
Have a look at the implementation. You'll see I have even introduced
the notion of EventFilter so that we can have regex when registering
interest for an event.
Thanks
-Vincent
Hi,
I'd like to to commit the fix for http://jira.xwiki.org/jira/browse/
XWIKI-1517
This involves removing 2 of the 4 APIs. Indeed, 2 APIs take an olddoc
parameter of a XWikiDocument type. The only reason for this is
because the notification mechanism requires two documents so that it
can check if the new one has differences over the old one and send
notifications accordingly. However this need should be an
implementation need and should not surface in the API. Hence
XWIKI-1517. BTW this change allows fixing http://jira.xwiki.org/jira/
browse/XWIKI-1518 and some other potential bugs too.
Note: I'm not changing the *.api.XWiki object (only the one in
*.xwiki.XWiki).
This change will a small impact on people building XWiki applications
on top of the XWiki platform but not on end users. I feel this is
still ok because:
* We need to improve our API if we want to progress in improving XWiki
* The alternative is to create a XWiki 2.0 version but we won't have
enough manpower to 1) continue supporting the 1.x line and 2) to
build XWiki 2.0 from scratch. I think our only reasonable option is
to build on XWiki 1.x and start refactoring the internal APIs slowly,
a bit in each version.
* I'll document this in the release notes
* It's easy to fix for anyone hit by this
* End users are not touched
* It fixes current existing bugs
* It makes the API easier to use. Right now in 99% of the code I had
to change the olddoc was simply a clone of the current doc thus
making the call useless
So here's my +1
Thanks
-Vincent