Re: [xwiki-devs] urgent
On Sep 28, 2007, at 9:16 AM, anuj sharma wrote: hi, Yes Sergiu has answered.Actually i have not checked it before. I said: I've just added this: http://www.xwiki.org/xwiki/bin/view/AdminGuide/ Configuration#HSettingthedefaulteditortouse28WikiorWYSIWYG29 However to be honest I don't know if this works or not. I think the fact that users are in simple mode by default probably overrides this. I think this default editor should be set to WYSIWYG by default and new users should get the default editor as their editor, unless they explicitely change it in their profiles. Does anyone know how it works? Now to disable the WYSIWYG editor completely you'll need to change template files, which isn't that easy. I think it's better to fix whatever issue you have with the WYSIWYG editor. As you see I had also even taken the time to add documentation for you... And also: Nope, never heard about this. You definitely need to upgrade to 1.1 final. Lots of WYSIWYG bugs were fixed after 1.1M4. -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Release XE 1.1.1
+1 2007/9/28, Vincent Massol [EMAIL PROTECTED]: Hi, I'd like to release XE 1.1.1 ASAP. This is a bug fix release fixing the following since 1.1 has been released. It's mean to be a stable release for projects who cannot afford unstability by moving to 1.2M1 (not released yet either). Here are the stuff already fixed: * [XWIKI-1682] - Fullscreen doesn't work on IE6 or IE7 * [XWIKI-1729] - Cache issue on new document creation in multilingual mode * [XWIKI-1739] - Document change notification not sent for new documents * [XWIKI-1747] - Code macro doesn't like groovy code * [XWIKI-1766] - Backlinks are not working anymore * [XWIKI-1754] - Platform WAR should be generic and not dependent on database In addition I'd like to apply the following (I sent a VOTE email but not many responses so I'll just go ahead): * [XWIKI-1768] - Cannot delete Space with a simple quote in its name * [XWIKI-1770] - Add new searchDocuments() API that accepts named HQL queries I'll also apply the patch for this issue; * [XWIKI-1735] - Lucene Plugin does not index creation or modification dates I'll also remove a commit done in 11 that Ludovic asked me to remove: r4721 - li$item/li + lia href=$xwiki.getURL($item)$item/a/li Apparently this is causing exceptions sometimes when importing with history. I'll do this work today. Here's my +1 to release ASAP after I've finished the work hilighted above. Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [SUMMARY] Re: [Discussion] Designing the new Rendering/Parsing component/API
Hi Erin,
On Sep 27, 2007, at 10:15 PM, Erin Schnabel wrote:
On 9/26/07, Vincent Massol [EMAIL PROTECTED] wrote:
Hi xwiki devs,
This is a summary of the decisions so far and the remaining
questions. This
is also the outcome of my discussion of today with Mikhail on skype.
1) We'll be able to import all syntaxes.
2) An XWiki instance will use a single syntax at a time. Once the
database
is created using that syntax it won't be possible to change it
(except by
doing an export and reimport).
This is the only thing that makes sense to me.
We also need to decide what syntax we use by default OOB. I
propose we use
the current xwiki syntax for some time and then switch to the
Wikimodel one
(Common Syntax) later on.
3) All pages will be able to be exported to any syntax. Some
elements have
no equivalent in other syntaxes and when this happens a warning
will be
displayed and the elements in question ignored.
OUCH. It's the only possible answer, but OUCH. I can just see the
complaints about data-loss piling up.. This will have to be
well-documented, perhaps including some tips about a) how to back
things up for real, and b) how to identify those areas later to assess
the damage...
Would you convert the syntax in the document history, too? Or does a
switch in syntax imply that the history is wiped... the document
history is very sensitive to random mucking around, I've found.
These exports would be only useful for people moving away from xwiki
I think and they would be useful only to import into another wiki.
The way to import history in each wiki is different I guess so saving
the history in a format specific to each wiki will be too much work
for us so I'd say not to exporting the history. However exporting any
version of a page is doable easily.
4) Mikhail has agreed to modify wikiModel to add macro block
recognition.The
syntax isn't fully defined yet but it'll be something like:
{xxx param1=value1 param2=value2}
...
{/xxx}
(param1='value value' and param1=value value will also be
supported)
This means we'll be able to have a common syntax for xwiki's
macros and also
for groovy code:
{groovy}
...
{/groovy}
And also for HTML blocks:
{html}
...
{/html}
Consistency is good, as is the lack of smashed-together-curly-braces.
If we demarcate all scripts in nice little blocks like this, will the
WYSIWYG editor be smart enough to leave it alone?
Yep that's the point too but it means anything inside will be left
alone, including wiki syntax and HTML. But that's fine I think.
5) We need to decide if we want:
A) No velocity block but document properties/metadata to tell
xwiki to
render the page using velocity. A user putting velocity code in a
page will
have to check a box somewhere to say that this is a velocity page.
...
OR
B) Velocity blocks same as what exists for groovy/macros/html,
namely:
{velocity}
... velocity code with wiki syntax allowed
{/velocity}
Note1: For B) we would allow putting wiki syntax inside the
velocity block.
Technically we'll apply the velocity rendering and then re-apply
wikimodel
on the result.
...
My preferences goes to B) and I'm proposing to use that.
The compatibility flag in xwiki.cfg would help, but the problem is
that I wouldn't ever be able to turn the flag off if I have a large
legacy database... which means none of my new documents get whatever
performance benefit might be gained.
You'll get some benefits (since Wikimodel is faster than Radeox) but
not all performance gains.
I would like to say: I'm running in a compatibility mode, and have
flagged all of the documents that pre-dated the new syntax processing
model. Shame on me if we don't start using the scripting blocks for
new documents.
Yes I guess that's possible but requires more work. We have so much
work to do already that I think this would be left for later or left
for the community to implement with patches.
As far as adding {velocity} {/velocity} around content when in
compatibility mode.. that would apply to all pages, which means all
content would get passed through the velocity renderer, right?
Right
I would think that whether or not wikitext (or raw html for that
matter) is allowed within a script block {script} {/script} would
depend on the nature of the language being invoked, right?
Right. It would be allowe for Velocity but not for Groovy for example.
Velocity is easily integrated with wikitext and html without a lot
of fuss, so, in my view, you would be obligated to allow html and
wikitext within that block (generally agreed).
Yep, that's what I proposed.
An html block would specify that you wouldn't want any wiki parsing
at all, right?
Yes
(wait a minute, isn't that what the pre tags were
supposed to do?).
Yes. We'll deprecate the pre tag then since an html tag makes more
sense and is better named IMO.
6) Mikhail is going to add
Re: [xwiki-devs] [VOTE] Release XE 1.1.1
On Sep 28, 2007, at 9:30 AM, Vincent Massol wrote: Hi, I'd like to release XE 1.1.1 ASAP. This is a bug fix release fixing the following since 1.1 has been released. It's mean to be a stable release for projects who cannot afford unstability by moving to 1.2M1 (not released yet either). Here are the stuff already fixed: * [XWIKI-1682] - Fullscreen doesn't work on IE6 or IE7 * [XWIKI-1729] - Cache issue on new document creation in multilingual mode * [XWIKI-1739] - Document change notification not sent for new documents * [XWIKI-1747] - Code macro doesn't like groovy code * [XWIKI-1766] - Backlinks are not working anymore * [XWIKI-1754] - Platform WAR should be generic and not dependent on database In addition I'd like to apply the following (I sent a VOTE email but not many responses so I'll just go ahead): * [XWIKI-1768] - Cannot delete Space with a simple quote in its name * [XWIKI-1770] - Add new searchDocuments() API that accepts named HQL queries Done. I'll also apply the patch for this issue; * [XWIKI-1735] - Lucene Plugin does not index creation or modification dates Done. I'll also remove a commit done in 11 that Ludovic asked me to remove: r4721 - li$item/li + lia href=$xwiki.getURL($item)$item/a/li Apparently this is causing exceptions sometimes when importing with history. Done. I'll do this work today. Here's my +1 to release ASAP after I've finished the work hilighted above. I'm ready to do the release. Only missing 1 more VOTE. Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] how to EMAIL a document change notification to all users
Hello All, how can I email a document change notification to all users or a group of users, once a change is made in a xwiki document. Regards ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] [ApplicationManager] [Proposal] Insert matching string in the list of documents
Hi all, Actually application descriptor contains a field that list all document application contains. I would like to add to Application Manager a way to be able to add all the documents of space SpaceName for example. I already implemented a solution and I would like you to comment and me to modify if needed. When XWikiApplication.resolveDocumentsNames is called, it list all document and one by one look if the document name is between [ and ], if so it consider document name as sql matching string usable with like. So for example you will add [XWiki.%] if you want to add all documents in the XWiki space to the application document list. This feature is supported for documents list and also document list to include WDYT ? -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] create a JIRA project for an XWiki help desk product
On Sep 28, 2007, at 2:54 PM, Stéphane Laurière wrote: Hi all, This email is a follow up to my previous one titled XWiki help desk. I propose you to vote for the creation of a JIRA project for managing the issues related to an XWiki help desk product. Note that the tool may be used for creating an issue tracker at some point. The development will take place in the XWiki sandbox for now. Preliminary ideas about the product features and about existing products are available from [1]. [1] http://www.xwiki.org/xwiki/bin/view/Design/HelpDesk Here's my +1. +1 Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Release XE 1.1.1
+1 Stéphane Vincent Massol wrote: Hi, I'd like to release XE 1.1.1 ASAP. This is a bug fix release fixing the following since 1.1 has been released. It's mean to be a stable release for projects who cannot afford unstability by moving to 1.2M1 (not released yet either). Here are the stuff already fixed: * [XWIKI-1682] - Fullscreen doesn't work on IE6 or IE7 * [XWIKI-1729] - Cache issue on new document creation in multilingual mode * [XWIKI-1739] - Document change notification not sent for new documents * [XWIKI-1747] - Code macro doesn't like groovy code * [XWIKI-1766] - Backlinks are not working anymore * [XWIKI-1754] - Platform WAR should be generic and not dependent on database In addition I'd like to apply the following (I sent a VOTE email but not many responses so I'll just go ahead): * [XWIKI-1768] - Cannot delete Space with a simple quote in its name * [XWIKI-1770] - Add new searchDocuments() API that accepts named HQL queries I'll also apply the patch for this issue; * [XWIKI-1735] - Lucene Plugin does not index creation or modification dates I'll also remove a commit done in 11 that Ludovic asked me to remove: r4721 - li$item/li + lia href=$xwiki.getURL($item)$item/a/li Apparently this is causing exceptions sometimes when importing with history. I'll do this work today. Here's my +1 to release ASAP after I've finished the work hilighted above. Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Stéphane Laurière [EMAIL PROTECTED] XWiki http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Error number 4001 in 4 :
This is the trace - I can't make head or tail of it... Error number 4001 in 4: Error while parsing velocity page PMT.Doc Wrapped Exception: Invocation of method 'substring' in class java.lang.String threw exception java.lang.StringIndexOutOfBoundsException: String index out of range: -1 @ PMT.Doc4,26? com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while parsing velocity page PMT.Doc Wrapped Exception: Invocation of method 'substring' in class java.lang.String threw exception java.lang.StringIndexOutOfBoundsException: String index out of range: -1 @ PMT.Doc4,26? at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:148) at com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:91) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:222) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:154) at com.xpn.xwiki.XWiki.include(XWiki.java:3125) at com.xpn.xwiki.api.XWiki.includeForm(XWiki.java:1313) at com.xpn.xwiki.api.XWiki.includeForm(XWiki.java:1279) at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:194) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:170) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143) at com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:91) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:222) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:154) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:125) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderDocument(DefaultXWikiRenderingEngine.java:117) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:401) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:347) at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:107) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:240) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:143) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1271) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1240) at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:511) at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at
[xwiki-devs] Error number 4001 in 4 :
Hello. I created a class and template using the Static List class property. But when I want to create a new document, the following error is shown Error number 4001 in 4: Error while parsing velocity page PMT.NewDoc Wrapped Exception: Invocation of method 'substring' in class java.lang.String threw exception java.lang.StringIndexOutOfBoundsException: String index out of range: -1 @ PMT.NewDoc4,26? I tried to use small lists and other variations but the error seems to come from an entirely different place... please help asap. regards, V. Harikrishnan Nair || Lokah Samastah sukhino bhavantu || ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Error number 4001 in 4 :
Hi, On Sep 28, 2007, at 10:15 AM, V. Harikrishnan Nair wrote: Hello. I created a class and template using the Static List class property. But when I want to create a new document, the following error is shown Error number 4001 in 4: Error while parsing velocity page PMT.NewDoc Wrapped Exception: Invocation of method 'substring' in class java.lang.String threw exception java.lang.StringIndexOutOfBoundsException: String index out of range: -1 @ PMT.NewDoc4,26? I tried to use small lists and other variations but the error seems to come from an entirely different place... please help asap. Can you show us the content of PMT.NewDoc and send us the full stack trace? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] Error when using the 'Level class' property
Hi all, I am getting the following error when I edited my class to add the Level Class property - Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.LevelsMetaClass cannot be cast to com.xpn.xwiki.objects.classes.PropertyClass com.xpn.xwiki.XWikiException: Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.LevelsMetaClass cannot be cast to com.xpn.xwiki.objects.classes.PropertyClass at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:163) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Wrapped Exception: java.lang.ClassCastException: com.xpn.xwiki.objects.meta.LevelsMetaClass cannot be cast to com.xpn.xwiki.objects.classes.PropertyClass at com.xpn.xwiki.web.PropAddAction.action(PropAddAction.java:55) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:147) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Can anyone check this out ? regards, V. Harikrishnan Nair || Lokah Samastah sukhino bhavantu || ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [SUMMARY] Re: [Discussion] Designing the new Rendering/Parsing component/API
On Sep 28, 2007, at 12:05 PM, Vincent Massol wrote:
[snip]
It seems semi-tangential to ask questions about skin/template
rendering, but I feel there is a significant amount of
interdependency
between the skin and the content, especially if you consider the
#panel macros, for example. The #panel macros are a) velocity
macros,
b) defined in files in the filesystem, and c) are included and
used by
every document defining a panel.
Do changes to the rendering/parsing API require skin/template *.vm
files to be updated with {velocity} {/velocity} tags? Or would the
velocity engine continue to pre-read and cache those files as it does
now...
hmm... Are they cached now? I don't see how they could be since it
would mean the velocity doesn't get executed at each request.
Yes, I would assume we would use {velocity} blocks.
Actually we don't have to do that. The Velocity macro will be able to
output wiki syntax from any text so we can still keep the templates
in Velocity exactly as they are now.
[snip]
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
