On Mon, Jun 20, 2011 at 10:48, Vincent Massol <[email protected]> wrote: > Hi Fabio/Jun, > > On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote: > >> Hi Jun, >> >> thanks, for the update. >> >> I agree with Vincent... The backend should not be an explicit choice >> made for each connection. REST should be the default and if you need >> XMLRPC (for example for connecting to a veeeery old XWiki instance) >> you might have an advanced button that allows you to do this or, as >> you suggested, the URI might suggest the backend to use. > > We've been supporting REST for a very long time now. My opinion is to drop > XMLRPC support altogether in the next release of XEclipse.
Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account. > > Thanks > -Vincent > >> You should progress on the REST aspects asap though. >> >> Thanks, >> Fabio >> >> On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote: >>> Hi Vincent, >>> >>> Thanks a lot for your suggestion. >>> >>> IMHO, xmlrpc is included for the purpose of back-ward compatibility. >>> As REST API was first introduced in version 1.8 from xwiki jira, >>> xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., >>> v1.4 or v1.5). >>> >>> I agree that technical details should not be exposed to end user. >>> >>> The backend implementation may be determined via analyzing user input of >>> server endpoint. For example, if the serverurl contains "confluence" >>> (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If >>> it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest >>> is used. >>> >>> However, the current implementation will populate the specific server >>> url field according to the backend type (xmlrpc or rest). >>> There may be some better way to do this. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/19/2011 03:40 AM, Vincent Massol wrote: >>>> Hi there, >>>> >>>> I haven't followed this thread but just noticing this: why do we want to >>>> expose to users something purely technical (ie the backend implementation)? >>>> Also why do we want to have to maintain several backends? >>>> >>>> IMO we should only use one and use the REST API only. >>>> >>>> If it's only about migration from the current XMLRPC to REST, it should be >>>> a "hidden" config param not exposed to users and that we use internally >>>> only IMO. >>>> >>>> The goal should always be to make it as easy as possible for end users, >>>> i.e. they shouldn't have to think when using XEclipse. >>>> >>>> Thanks >>>> -Vincent >>>> >>>> On Jun 19, 2011, at 6:52 AM, Jun Han wrote: >>>> >>>>> Hi Fabio, >>>>> >>>>> I have already finished re-factoring the whole xmlrpc backend. >>>>> >>>>> A new combo list is added to the "new connection" wizard to provide two >>>>> choices (xmlrpc and rest), as shown in >>>>> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >>>>> >>>>> When user selects "xmlrpc", the xmlrpc implementation is used. The >>>>> navigation panel can show the xwiki resources, as shown in >>>>> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >>>>> >>>>> I will continue working on the rest backend following the previous >>>>> discussion. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> could you post a status about your work? >>>>>> Your commits stream >>>>>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>>>>> informative (are you holding commits locally? If so you should push >>>>>> more frequently!) >>>>>> >>>>>> Midterm is approaching so we need to make things advance a little bit >>>>>> faster. >>>>>> >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> After I looked into the current implementation of XEclipse and tried >>>>>>> several attempts, one plan, whose goal is to provide an abstract >>>>>>> communication layer between XEclipse and server, might be feasible. >>>>>>> A rough system diagram showing the relationships of plugins of XWiki >>>>>>> Eclipse is available at: >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>>>>> >>>>>>> In order to remove dependency of particular back-end implementation >>>>>>> (xmlrpc or rest), >>>>>>> an abstract layer, which includes two plugins (model and storage) will >>>>>>> be created. >>>>>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>>>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>>>>> abstract classes, AbstractLocalDataStorage and >>>>>>> AbstractRemoteDataStorage. >>>>>>> >>>>>>> In this way, all the core implementation and UI components (dialogs, >>>>>>> properties dialog, adapters) in ui plugin will now depend on the model >>>>>>> and storage plugins rather than the xmlrpc implementation. >>>>>>> >>>>>>> Instead of only providing the required jar files, xmlrpc and rest >>>>>>> plugins will also do the following: >>>>>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>>>>> storage plugin >>>>>>> 2. extend the model classes in model plugin >>>>>>> >>>>>>> In this way, all the abstract classes in model and storage plugins will >>>>>>> be initialized in the run time and perform the specified functions. >>>>>>> >>>>>>> If my understanding is correct, I will begin re-factoring work. >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Jun Han >>>>>>> >>>>>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> Instead of returning Object, you should return >>>>>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>>>>> >>>>>>>> So the storage abstraction needs to include and abstract model as well >>>>>>>> in >>>>>>>> order to be usable. This means that the implementation also comes with >>>>>>>> a >>>>>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them >>>>>>>> implementing >>>>>>>> org.xwiki.eclipse.core.model.Page) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eduard >>>>>>>> >>>>>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Eduard, >>>>>>>>> >>>>>>>>> Thanks a lot for prompt instruction. >>>>>>>>> >>>>>>>>> I forgot to sync the screenshot to the server. Now it is the correct >>>>>>>>> one. >>>>>>>>> >>>>>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>>>>> to devise a common storage API for both of them. >>>>>>>>> >>>>>>>>> For example, >>>>>>>>> public Object getPage(String pageId) >>>>>>>>> public List<Object> getPages(String spaceKey) >>>>>>>>> >>>>>>>>> They will return >>>>>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>>>>> >>>>>>>>> If this is the way to go, I will look more into how to implement this. >>>>>>>>> Adapter pattern may be used. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>>>>> Hi, Eduard and Fabio, >>>>>>>>>>> >>>>>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>>>>> wiki, space. >>>>>>>>>>> Please see the screenshot at >>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one >>>>>>>>>> and >>>>>>>>>> I think it's from an early stage of development. >>>>>>>>>>> Adding pages under space is straightforward too, however, it >>>>>>>>>>> requires >>>>>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>>>>> >>>>>>>>>>> I will continue work on displaying more XWiki resources after I >>>>>>>>>>> finish >>>>>>>>>>> re-factoring the properties editor, action provider (context menu), >>>>>>>>>>> and >>>>>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>>>>> It should not take that much of a refactoring on the UI part, since >>>>>>>>>> the >>>>>>>>>> heavy lifting is done in the core. >>>>>>>>>> >>>>>>>>>> What I actually wanted to tell you is that you should take the >>>>>>>>>> refactoring in a modular direction and consider your work as a >>>>>>>>>> contribution and alternative for the existing system and not only as >>>>>>>>>> a >>>>>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>>>>> integrating the rest back-end). Keep the abstraction layer >>>>>>>>>> (interfaces, >>>>>>>>>> model, etc) as the main think the ui and even core components >>>>>>>>>> communicate with and keep the implementation of that abstraction >>>>>>>>>> layer >>>>>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>>>>> act accordingly. >>>>>>>>>> >>>>>>>>>> We don`t want to do the same replacement work if, for whatever >>>>>>>>>> reason, >>>>>>>>>> we want to switch to a different back-end in the future. So keep >>>>>>>>>> that in >>>>>>>>>> mind at all time during GSoC. >>>>>>>>>> >>>>>>>>>> Besides that, keep up the good work ;) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Eduard >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> I am not sure that syntaxes should appear as a child of >>>>>>>>>>>>> connection. I >>>>>>>>>>>>> would show this information in the property panel of the >>>>>>>>>>>>> connection. >>>>>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>>>>> only >>>>>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>>>>> >>>>>>>>>>>> Connection01 >>>>>>>>>>>> - wiki1 >>>>>>>>>>>> -- spaceA >>>>>>>>>>>> --- pageX >>>>>>>>>>>> - wiki2 >>>>>>>>>>>> - etc. >>>>>>>>>>>> >>>>>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki >>>>>>>>>>>> version >>>>>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>>>>> >>>>>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>>>>> password and consider the wiki for which it applies. User Admin on >>>>>>>>>>>> the >>>>>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on >>>>>>>>>>>> subwiki1 >>>>>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), >>>>>>>>>>>> it >>>>>>>>>>>> will be resolved to the wiki of the resource you are trying to >>>>>>>>>>>> access. >>>>>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Eduard >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >>>>>>>>> wrote: >>>>>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I managed to create a top-level tree expansion when user >>>>>>>>>>>>>> requests the >>>>>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A screenshot is available at: >>>>>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now the labels display the whole<href> attribute, I plan >>>>>>>>>>>>>> to >>>>>>>>> "syntaxes" >>>>>>>>>>>>>> and "wikis" later on. >>>>>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue >>>>>>>>>>>>>> to >>>>>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It took me a while to figure out the configuration of tree >>>>>>>>>>>>>> content >>>>>>>>>>>>>> provider, tree viewer and label provider, which is a little >>>>>>>>>>>>>> different >>>>>>>>>>>>>> with what I did in Eclipse SWT development. As this has been >>>>>>>>>>>>>> sorted >>>>>>>>> out, >>>>>>>>>>>>>> I would pick up the pace. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take >>>>>>>>>>>>>>>> into >>>>>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>>>>> Also, I think that we need to display the other resources (like >>>>>>>>>>>>>>> we >>>>>>>>> do >>>>>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>>>>> ---- Main >>>>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>>>> ---------- 2 >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>>>>> change >>>>>>>>>>>>>>> to some other IDs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The advantage of such an ordering is that, highly used pages >>>>>>>>>>>>>>> (that >>>>>>>>> have >>>>>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will >>>>>>>>>>>>>>> allow >>>>>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If a list of numbers looks too blank, you could have them print >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> value of the first property it their class, just like XWiki`s >>>>>>>>>>>>>>> object >>>>>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember >>>>>>>>>>>>>>> if we >>>>>>>>>>>>>>> display them or not), but we should have them as an 'implicit' >>>>>>>>>>>>>>> first >>>>>>>>>>>>>>> class like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>>>> -------- Attachments >>>>>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. >>>>>>>>>>>>>>> Check >>>>>>>>>>>>>>> again the API specs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You can get creative with the details on how to display/handle >>>>>>>>>>>>>>> the >>>>>>>>> new >>>>>>>>>>>>>>> stuff. :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Eduard >>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>>>>> functionality >>>>>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with >>>>>>>>>>>>>>>>> username/password. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>>>>> means >>>>>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace >>>>>>>>>>>>>>>>> xmlrpc >>>>>>>>> code >>>>>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One question is what resources are to be included in >>>>>>>>>>>>>>>>> navigation >>>>>>>>> panel, >>>>>>>>>>>>>>>>> besides xwiki -> space -> pages? and >>>>>>>>>>>>>>>>> how to display >>>>>>>>> them? >>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> login/logout can be implemented in order to store on the >>>>>>>>>>>>>>>>>> client >>>>>>>>> side >>>>>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>>>>> token" >>>>>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web >>>>>>>>>>>>>>>>>> form) >>>>>>>>> so >>>>>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>>>>> previously >>>>>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials >>>>>>>>>>>>>>>>>> with >>>>>>>>> each request. >>>>>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>>>>> cookie by >>>>>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>>>>> requests. >>>>>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>>>>> OAuth-like >>>>>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements >>>>>>>>>>>>>>>>>>> IDataStorage {}. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>>>>> functionality >>>>>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>>>>> From REST API document, users can be >>>>>>>>>>>>>>>>>>> authenticated via >>>>>>>>> something like: >>>>>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header >>>>>>>>>>>>>>>>>>> to the >>>>>>>>> HTTP >>>>>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by >>>>>>>>>>>>>>>>>>> parsing >>>>>>>>> the response. >>>>>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>>>> Jun Han > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
