Hi,
The current header copyright says:
"Copyright 2006-2007, XpertNet SARL, and individual contributors as
indicated by the contributors.txt."
2 issues:
- The sentence is not english
- We don't have such a file
I propose that we change it in favor of:
"Copyright 2006-2007, XpertNet SARL, and individual contributors."
Main Reason:
- We don't specify where the contributors are listed which means we
can decide to change that location. For example a list of
contributors is on http://www.xwiki.org/xwiki/bin/view/Community/
HallOfFame#HContributors but it's far from being accurate. Tomorrow
we may use another strategy or another location and we'd rather not
change all headers. So better not specify where we define them.
Another location is SVN.
Here's my +1 to that.
I also propose that we continue listing contributors on that
HallOfFame page. Unfortunately I've been the only one adding names
there. I need help.
Thanks
-Vincent
Hi,
We need a global solution for including/excluding pages in the XE
wiki. The needs comes from the fact that we shouldn't show internal
pages to casual xwiki users and we shouldn't show pages that they
don't have the rights to view. At least the following places need to
use this feature:
* Navigation panel
* All docs Treeview
* All docs Index
* WebSearch
* WebSearchRss
* WebRss
* Orphaned pages + Panel
I propose the following implementation:
1) Add a new API $xwiki.filterDocuments(List docNamesList, String
persmissionToCheck). It would be used like this:
for each ($item in $xwiki.filterDocuments($xwiki.searchDocuments
($sql), "view"))
...
In the XE wiki:
2) Add a XWiki.PageFiltersClass class with 1 property: Includes. This
property will contain pages to exclude, using HQL like format (one
entry per line)
3) Add a XWiki.PageFiltersClassSheet to explain what this is about,
explain how to add/remove entries, etc
4) Add a XWiki.PageFilters document that contains a
XWiki.PageFiltersClass object and which has velocity code in its wiki
content to compute the HQL clause corresponding to the exclusions
specified in its object.
5) Modify the documents listed above to use XWiki.PageFilters as
follows:
#includeInContext("XWiki.PageFilters")
#if (!$pageFiltersSqlClause)
#set ($pageFiltersSqlClause = "")
#end
#set ($sql = ".... and $pageFiltersSqlClause ...")
#set ($list = $xwiki.filterDocuments($xwiki.searchDocuments($sql ,
$nb , 0), "view"))
...
WDYT?
Thanks
-Vincent
Hi,
Sometime ago, there was a discussion regarding how should the document
history be stored in a better way.
Right now, the complete history is stored as one field in the xwikidoc
table. From my PoV, this has some major disadvantages:
- loading an older version requires parsing all the history -> memory
inefficiency
- as the documents grow older, loading a document will take a lot of time ->
time inefficiency
- queries on archives cannot return just one version, but they match the
whole document (somewhere in the history, there was a version containing
"search term")
The blocking issue with storing old version in a different table was, at
that time, the fact that a document archive should contain all information
needed for completely restoring the document, like content, metadata,
objects.
I don't think that is actually an issue. We are archiving document versions,
but we're joining all versions in one large string. Why don't we archive the
complete version, but one version per row?
So, the archive table should look like:
- document name
- version number
- language (for translations)
- content
- archived metadata (one field, or the same fields as in xwikidoc)
- archived objects (one field)
- attachment names and versions
It is not like storing the version as a normal document is, with separate
objects and properties, but at least it provides a better storage and
retrieval mechanism, and it separates a bit the parts of a wikidocument -
content, metadata, objects.
WDYT?
--
http://purl.org/net/sergiu
ok, after fighting for 2 days, TeamCity is back working fine.
http://teamcity.xwiki.org
We had a disk full problem dues to the large size of our maven repos
so I cleaned them all and then discovered the build on TC wasn't
working anymore. This was due to several errors in the build which
were hidden by the fact that the local repo on the TC machine had the
artifacts there. To be more precise, in order to do a release with
maven we cannot have any SNAPSHOT deps in our POM so we had to
"release" some external dependencies we're using in SNAPSHOT version.
One of these was the maven selenium plugin and I've discovered that
faking a release of an external maven plugin isn't as simple as it
appears... But I now know how to do that.
Thanks
-Vincent
Hi Vincent,
We are going to add copyright statements to Xeclipse source, I think we can
get them from xwiki sources, please let us know if you have any concerns...
Btw, is it Xeclipse or XEclipse ? :)
Thanks.
- Tharindu & Asiri
All those errors were caused by some disk space issue that has been
fixed now.
-Vincent
On Jul 24, 2007, at 2:18 PM, teamcity(a)xwiki.org wrote:
> Build XWiki Platform Web::Maven2 #217 failed
> Agent: Default agent
> Build results: http://teamcity.xwiki.org/viewLog.html?
> buildId=1395&buildTypeId=bt7
>
> Changes included (1 change)
> ====================================================
> Change 4019 by vmassol (1 file):
> XWIKI-1519: The version shouldn't come from xwiki.cfg file
>
> see more information about changed files: http://teamcity.xwiki.org/
> viewLog.html?tab=buildChangesDiv&buildId=1395&buildTypeId=bt7
>
>
> ======================================================================
> ======
> Configure email notifications: http://teamcity.xwiki.org/
> profile.html?init=1#notifications
Hi,
I'm about to modify the SVN externals definition for trunks-users so
that they point to our own XWiki readonly SVN repo instead of
pointing to the OW repo as there are issues with it.
If you have checked out trunks-users, then do a svn update once I've
made the change. Hopefully that'll just work. If not, you might need
to do a new checkout.
Sorry for that
Thanks
-Vincent
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
xwiki.org says that XWiki uses log4j, but the code uses a mix of both
commons logging interfaces, and those particular to log4j.. Should we be
picking one? It seems that the commons logging interfaces would be
preferred (as it knows how to interact with log4j), but I'm not sure.
?
--
Waste of a good apple. --Samwise Gamgee
Hi,
I change mysql connect url setting in xwiki-2.pom (local repository) from
<xwiki.db.connection.url>"jdbc:mysql://localhost/xwiki?useServerPrepStmts=false"</xwiki.db.connection.url>
to <xwiki.db.connection.url>"jdbc:mysql://localhost/xwiki
?useUnicode=true&useServerPrepStmts=false"</xwiki.db.connection.url>
then build 'xwiki-web-standard' by 'mvn install -Pxe,mysql ', get eror:
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: unknown:xwiki-web-standard
POM Location:
E:\dev\xwiki\svnroot\xwiki-users\xwiki-platform-web\standard\pom.xml
Reason: Cannot read project model from interpolating filter of serialized
version.
I have build successfully before this modification.
Does pom file can not use the expression '&' ?
Hi everyone,
ObjectWeb (our infrastructure) is not answering as to whether we will
recover the mails lost on the 16th and 17th. I have asked OW Admins
at least 3 times for the past 6 days and they said they're working on
it (but they haven't told us whether it'll be possible or not to
recover them). Thus we cannot wait any longer as there were important
mails sent during that period. I'm going to resend my emails and I
advise everyone to do the same.
We're really sorry about this. I'm following this up on OW's side.
Please note that the emails sent this week end have also not made it
to the list yet. Let's hope they're not lost too.
Thanks and again please accept our apologies for all these emails
issues we're suffering from the past 3 months. We're working on
finding a solution real soon so that it doesn't happen again in the
future.
-Vincent Massol
XWiki Release Manager
Just a note to tell you that I have (again) asked the ObjectWeb admin
to give us a status about the missing emails and that I have not yet
received any answer... :(
This is a real *pain*. I'm fully committed that these email issues
don't happen again in the future. I'll let you know more about the
solution...
Thanks
-Vincent