Re: [xwiki-devs] [GSoc] XDroid Platform

As just did a commit with last version of android plugin and some cleanup. Seems to work well. On Thu, Jun 7, 2012 at 12:19 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: > BTW if you have quick questions it's probaly better to use IRC (I'm > tmortgane on the channel and I'm on GMT+2 tome zone but you can ask > anyone when I'm not around). See > http://dev.xwiki.org/xwiki/bin/view/Community/IRC. > > On Thu, Jun 7, 2012 at 12:17 PM, Thomas Mortagne > &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >> Not need to send this kind of mail privately to me. >> >> On Thu, Jun 7, 2012 at 5:33 AM, sasinda rukshan >> &lt;sasindarukshan(a)gmail.com&gt; wrote: >>> Thanks, >>> The project is building perfectly well in eclipse (and runs well too) [I >>> configured the build paths for eclipse opening each module as a project and >>> giving project dependencies and etc.]. This is because android facet and >>> maven-android plugin for eclipse [m2e-android] (not the jayway  androi maven >>> plugin)does not work together well. >>> Maven build does not work with newer jayway android maven plugins because of >>> the simplexml library. I checked with another helloworld app that does not >>> have simplexml dependancy and have simplexml dependancy. When we have the >>> dependancy it does not work. Also when packaged with the beta version maven >>> plugin I get runtime error logs notifying that the exact classes informed >>> missed in the compile time for newer maven plugin are missing. But the app >>> is running ok. >>> I will try with it some more and if I can't can you help me with it a >>> little. >> >> Sure If it's just related to simplexml it's probably not much. I will >> try to take a look today. At worst the version we are using right now >> is working fine so you can continue with it anyway. >> >>> >>> I looked at the Enterprise platform apis just to make my apis similar when >>> possible.Source code is not at all relevant to me. But as you say It will be >>> imperfect if I use its style heavily for the mobile version as well. >> >> Yes there is several issues here: >> * most APIs in oldcore module are old and bad and we are trying to get >> rif of them so better not getting too much attached to it ;) >> * they are designed to run in an enironment with lots of resources and >> don't care as much as a mobile API should about memory, etc. >> >>> >>> >>> Thank you. >>> Best Regards. >>> Sasinda. >>> >>> >>> On Wed, Jun 6, 2012 at 1:03 PM, Thomas Mortagne < thomas.mortagne(a)xwiki.com&gt; >>> wrote: >>>> >>>> On Tue, Jun 5, 2012 at 7:07 PM, sasinda rukshan >>>> &lt;sasindarukshan(a)gmail.com&gt; wrote: >>>> > Hi, >>>> > *1: User Config Saving* >>>> > * >>>> > * >>>> > Xwiki android can now save user login data. >>>> > I refered >>>> > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki. >>>> > Currently assuming the authority >>>> > >>>> > part(platform.xwiki.org< http://platform.xwiki.org/xwiki/bin/view/AdminGuide/AccessWiki>) >>>> > only >>>> > as a unique wiki identifier. But in the org.xwiki.android.entity.User I >>>> > have the method >>>> > setXWikiRealm(String url);: >>>> > Here I have intended the meaning realm as the url root path for a unique >>>> > wiki instance. >>>> > i.e. it should identify a wiki using path upto >>>> > http://host/xwiki/wiki/wikialias/ >>>> > But that functionality is not implemented.I just mailed this asking for >>>> > the >>>> > opinion wether the usage of word realm was right here. >>>> > Also do you have seperate users for  wikis for path based wiki access.Or >>>> > are they the same with the main wiki *http://<host>/xwiki*. >>>> >>>> Both actually, you can have global users (which are the one on main >>>> wiki) and local users. >>>> >>>> > *2: Entity model* >>>> > * >>>> > * >>>> > About the convention for using C_ prefix for core entity tables. I >>>> > was referring to make the android versions of these entities >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchemaand >>>> > start >>>> > there db prefixes with C_ >>>> > This is because other apps may need to store some specific tables needed >>>> > for them. Rather than having a seperate DB schema for them we can put >>>> > those >>>> > tables here as well prefixing them with <appname>_ . >>>> > I added more entities like User as well to the core entities(table >>>> > C_User).Also will implement a Log Entity(C_Log table) for logging some >>>> > important application activities(such as login attempts) But the Log may >>>> > be >>>> > a little additional weight to the space and performance.I may implement >>>> > a >>>> > generic DBCleaning service to clean the tables like Log, if I have time. >>>> > (Perhaps this description will resolve the confusion about the DB >>>> > conventions. Sorry I was not very clear in that earlier mail. ;-).) >>>> > >>>> > I am sorry to say I am somewhat confused with all those entities in >>>> > http://platform.xwiki.org/xwiki/bin/view/DevGuide/DatabaseSchema. >>>> >>>> The XWiki model is based on generic classes and objects wich is why >>>> you see lots of tables (class properties, object properties , etc.). >>>> There is no table for users for example, its an object of class >>>> XWiki.XWikiUsers. >>>> >>>> > >>>> > Any way to reduce my confusion >>>> > I refered >>>> > 1)  XWiki Data >>>> > Model<http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel > >>>> > : >>>> >   can you give me a link to a documentation that explains the workflow >>>> > of >>>> > how a normal request is converted in to the requested page by the >>>> > bin View action . So I can get a better understanding of how classes , >>>> > objects are used. >>>> >>>> Not sure there is one. but basically you get either: >>>> * document content executed >>>> * if a class sheet is defined for one of the document objects classes, >>>> the class sheet is executed >>>> * if a document sheet is defined for the documment, the document sheet >>>> is executed >>>> >>>> That's pretty much all, then is a matter of free script and wiki >>>> syntax to actually display the content. >>>> >>>> > 2)  package com.xpn.xwiki.api: I don't need to consider this, do I? >>>> >>>> That's limited scripting API so you should not consider this. >>>> >>>> > 3) >>>> >  Cache< http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Module> >>>> >  : Need not implement similar component. Android OS does it nicely for >>>> > the >>>> > REST responses >>>> > but still don't have a clear picture on this. >>>> > To save a blog doc >>>> > option 1)Seems like I have to convert a document entity to relevent >>>> > xwiki-model-simplexml entities and send to server. >>>> > option 2) We also can edit the relevent simplexml model object fields >>>> > directly. (Looks a bad option to me.It does not hide the complexity of >>>> > lower levels for the client layer.Anyway my work load  is reduced with >>>> > opt:2 ;-)) >>>> >>>> IMO you should not even look at >>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Cache+Moduleand >>>> instead look at how caching is usually done in Android. The idea is >>>> not to port the xwiki-platform to Android IMO but to follow Android >>>> standards to provide a library to manipulate XWiki model. >>>> >>>> You can set the annotation you want to the simplexml model but the >>>> classes/methods should remain an exact copy of what's on >>>> xwiki-platform-rest-model. The idea being that we could decide to >>>> change the implementation from simplexml to anything (JAXB, gson, >>>> etc.) without breaking anything. >>>> >>>> > >>>> > >>>> > *3: Development/architectural approach Change* >>>> > * >>>> > * >>>> > I was first thinking for a addon like architecture for the XWiki android >>>> > app. We have the client.Main app (with all platfrom libs included) and >>>> > Blog >>>> > app as a seperate apk. >>>> > But here Blog app will need to have the platform lib also. That would be >>>> > a >>>> > complete waste of space. But dynamically extending the app is lot >>>> > easier. >>>> > The client.Main app can add the activities defined in other apks in to >>>> > its >>>> > launcher interface using android PackageManager class. >>>> > >>>> > http://stackoverflow.com/questions/9236803/android-build-an-application-tha… >>>> > But with this approach rises additional complexities. For example naming >>>> > conflicts in the Components library module when two apps have the same >>>> > library with same activities defined. Sync issues etc etc.... >>>> > So we will go with single .apk approach. >>>> > When going with single .apk we dont need a content provider to share >>>> > config/ preferences data. So sharing module is now not needed. The >>>> > client >>>> > applications now can directly access the Configuration.java class to >>>> > get/put configuration entries. >>>> > Also since I am having a User entity a configuration like >>>> > defaultUser(currently the admin user , hard coded in login.xml layout >>>> > file) >>>> > will only be needed for the first use of the app. Otherwise users need >>>> > not >>>> > configure a default user as the application now suggests the user names >>>> > and >>>> > automatically fill the rest. >>>> >>>> Keep in mind that the main goal of this project is to provide tools >>>> for any application to access an XWiki instance and manipulate its >>>> datas easily an improving those libraries should always be the first >>>> goal. Your blog application is here as a good demo and because it's >>>> hard to design a library without using it. >>>> >>>> I really don't understand why you talk about naming conflict. Of >>>> course a library should never provide a complete final activity but >>>> only interface components (View), fragments or base activities to >>>> extend. Putting those elements in an activity is each application job. >>>> An activity is by definition unique so it has nothing to do in a >>>> library. The complete activities in >>>> >>>> https://github.com/xwiki-contrib/android-client/tree/master/xwiki-android-c… >>>> should have never been there, it's actually a mistake. >>>> >>>> > >>>> > *4: Plan for this week* >>>> >>>> As a priority you should really merge your branch as soon as you have >>>> something building fine. So that it goes through Jenkins and deploy >>>> snapshot build of what you do. Jenkins will tells you in live when >>>> your project does not build anymore or if there is any test failing >>>> and it allows anyone to very easily test the current test of the >>>> client just by installing the apks on >>>> http://maven.xwiki.org/snapshots/org/xwiki/android/. You need to have >>>> something working and in good shape to succeed the GSOC so fixing when >>>> you break something in your build should be your priority over adding >>>> more features. >>>> >>>> Also as I commented in your commit you should be more careful on what >>>> you commit. There is many binaries and Eclipse stuff in your branch. >>>> >>>> > * >>>> > * >>>> > Make a launch pad .We can launch XWiki Navigator, blog etc from this. >>>> > The >>>> > launch pad is shown when we launch XWiki main client. >>>> > Consider adding the WYSIWYG to my blog. It will be useless without the >>>> > ability to convert text formatting to xwiki syntax.So I may just >>>> > integrate >>>> > it and ignore the uselessness for now. >>>> >>>> Not exactly, you could actually reuse WYSIWYG service to send html and >>>> let it convert it to wiki syntax. Note that you are not limited to >>>> what you can find in the current Android library. This is just what >>>> Chamika had the time to do. There is others REST (or not REST) server >>>> interfaces you can use in your client or even add more if its generic >>>> enough and make sense for something else than just Android client. >>>> >>>> > We currently don't have any config to save( Other than default user) >>>> > config. I will add some demo config data and have a developer tools app >>>> > added to the above mentioned XWiki launch pad that can view/edit the >>>> > config >>>> > file. >>>> > >>>> > That will complete milestone 1. But it is not the Sharing >>>> > module(intended >>>> > to share data with other .apks).That is the configuration component does >>>> > not have a ContentProvider to share config data with other apks. Also I >>>> > will define a seperate class to have preferences which will be edited by >>>> > users. Config files are for configuration stuff and will be edited by >>>> > developers. Users have preferences files(natively supported by android) >>>> > to >>>> > change app preferences. For example users will add the default login >>>> > username as a preference.(This will invalidate the use of default User >>>> > entry in the config file which is used until the user edits his >>>> > preferences) >>>> >>>> I'm fine with not sharing datas between applications but it does not >>>> prevent the libraries to  provide tools to manage those datas in a per >>>> application basis. >>>> >>>> > >>>> > Beg your pardon if the mail is too lengthy.;-) >>>> >>>> No problem, never too much information for this ;) >>>> >>>> > Thank you. >>>> > Best Regards. >>>> > >>>> > Sasinda Rukshan. >>>> > >>>> > >>>> > Best Regards. >>>> > >>>> > >>>> > On Wed, May 30, 2012 at 1:11 PM, Thomas Mortagne >>>> > &lt;thomas.mortagne(a)xwiki.com&gt;wrote;wrote: >>>> > >>>> >> On Wed, May 30, 2012 at 4:28 AM, sasinda rukshan >>>> >> &lt;sasindarukshan(a)gmail.com&gt; wrote: >>>> >> > Hi, >>>> >> > I am studying ORM Lite these days. >>>> >> > Please It would be comforting if you can confirm whether it is worth >>>> >> > the >>>> >> > overhead to use ORM Lite. >>>> >> > >>>> >> >>>> >> http://logic-explained.blogspot.com/2011/12/using-ormlite-in-android-projec… >>>> >> > http://ormlite.com/ >>>> >> > ORM Lite features: >>>> >> > Automatically Creates standard DAOs for an annotated entity. >>>> >> > Coding will be lot easier. >>>> >> >>>> >> Remember it's a framework for a mobile platform so it has to remain >>>> >> light and have good performances. I can see that Android version of >>>> >> ormlite is very small but I never used it so I don't know if it's good >>>> >> or not. At least it seems petty active which is a good point so I >>>> >> don't have anything against it. >>>> >> >>>> >> > >>>> >> > Can you suggest how to name the entities. >>>> >> > I am going to go with, >>>> >> > <entity>  org.xwiki.xdroid.data.User  --> <table> C_USER >>>> >> >>>> >> Note that there is already a package name prefix and group id defined >>>> >> for the framework and it's org.xwiki.android as you can see on >>>> >> https://github.com/xwiki-contrib/android-client. Why do you want to >>>> >> change it ? It's more consistent with >>>> >> org.xwiki.commons/org.xwiki.rendering/org.xwiki.platform so I would >>>> >> prefer to keep it that way unless you can give arguments. The goal is >>>> >> not to redo something completely but complete and improve the existing >>>> >> framework. >>>> >> >>>> >> Also as far as I can see there is already several things called >>>> >> "xdroid" on Google play among which an application developer >>>> >> (https://play.google.com/store/apps/developer?id=x-droid) and an >>>> >> application ( >>>> >> >>>> >> https://play.google.com/store/apps/details?id=com.gurudigitalsolutions.xdro… >>>> >> ). >>>> >> >>>> >> > >>>> >> > Thanks, >>>> >> > Best Regards >>>> >> > >>>> >> > Sasinda. >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Wed, May 30, 2012 at 7:42 AM, sasinda rukshan >>>> >> > &lt;sasindarukshan(a)gmail.com&gt;wrote;wrote: >>>> >> > >>>> >> >> Hi, >>>> >> >> >>>> >> >> I am commiting my work to my fork >>>> >> >> https://github.com/sasinda/android-client. >>>> >> >> I ll request to pull it to xwiki-contrib later. >>>> >> >> >>>> >> >> I was running in a wrong path these days. Wanted to save login >>>> >> >> history >>>> >> and >>>> >> >> suggest login. I was going to do it using an xml file (login >>>> >> attempts.xml). >>>> >> >> Now it seems database is better. >>>> >> >> Any way before I go wrong again I will say what I am going to do. >>>> >> >> I am going to enforce following conventions.These are not yet >>>> >> >> needed, >>>> >> >> considered the small scale.But when the system grows it would be >>>> >> >> nice to >>>> >> >> have them to avoid confusions. >>>> >> >> *Database prefixes for:* >>>> >> >> *Platform tables (can begin with appropriate prefix)* >>>> >> >> AD_ //application dictionary : don't know when it will be needed ;-) >>>> >> >> C_ //core functionality >>>> >> >> *Client Applications.* >>>> >> >> X<App name prefix>  ex: XBLOG_   for Blog app// All client add in >>>> >> modules >>>> >> >> must begin with table prefix X(for xwiki and ordering) + App name. >>>> >>  This is >>>> >> >> for my blog. >>>> >> >> >>>> >> >> I will create >>>> >> >> C_User for user data. >>>> >> >> C_LoginAttempt  for saving login attempts. >>>> >> >> >>>> >> >> From C_LoginAttempt I can filter uniqe login combinations and give >>>> >> >> suggestions in the login UI component. Also save the history. >>>> >> >> >>>> >> >> All saved data for blog app will be linked to a perticular login : >>>> >> >> User, >>>> >> >> XWiki server. >>>> >> >> But only a single user will be most probably using his personal >>>> >> >> device. >>>> >> So >>>> >> >> above will be relevant only when he has multiple wikis. >>>> >> >> >>>> >> >> Best Regards, >>>> >> >> Sasinda Rukshan. >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> On Sun, May 27, 2012 at 5:43 PM, Chamika Weerasinghe < >>>> >> chamikaw(a)gmail.com&gt;wroteote: >>>> >> >> >>>> >> >>> On Fri, May 25, 2012 at 1:25 AM, Jerome Velociter < >>>> >> jerome(a)winesquare.net >>>> >> >>> >wrote: >>>> >> >>> >>>> >> >>> > On Thu, May 24, 2012 at 6:09 PM, Thomas Mortagne >>>> >> >>> > &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >>>> >> >>> > > On Thu, May 24, 2012 at 5:52 PM, sasinda rukshan >>>> >> >>> > > &lt;sasindarukshan(a)gmail.com&gt; wrote: >>>> >> >>> > >> Hi all, >>>> >> >>> > >> I am starting this thread for my XWiki Android Platform >>>> >> >>> > >> Project. >>>> >> >>> > >> >>>> >> >>> > >> Please check whether following are OK. >>>> >> >>> > >> [1] INFO >>>> >> >>> > >> I tried to start my new modules with the >>>> >> >>> de.akquinet.android.archetypes: >>>> >> >>> > >> android-quickstart:1.0.8.  (added eclipse plugins m2e, >>>> >> >>> > >> m2e-android[a.k.a  *Android >>>> >> >>> > >> Configurator* ]). But this seems buggy in eclipse. >>>> >> >>> > >> Any way the earlier project has not followed the above >>>> >> >>> > >> archtype >>>> >> >>> either. >>>> >> >>> > So >>>> >> >>> > >> I am going to write pom.xml manually for my each module. >>>> >> >>> > >> >>>> >> >>> > >> [2] ADVICE NEEDED >>>> >> >>> > >> xwiki-rest-model module contains 2 submodules >>>> >> >>> > >>  |-- xwiki-rest-model-gson  ( gson should be corrected to >>>> >> >>> > >> json) >>>> >> >>> > > >>>> >> >>> > > No the g is not a mistake, it's a model to be used with the >>>> >> >>> > > gson >>>> >> >>> > > library (http://code.google.com/p/google-gson/). See >>>> >> >>> > > >>>> >> >>> > >>>> >> >>> >>>> >> >>>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Google+Android+Client#… >>>> >> >>> > . >>>> >> >>> > > >>>> >> >>> > >>  |-- xwiki-rest-model-simplexml >>>> >> >>> > >> I think the xwiki-rest-model-gson is redundant. The classes >>>> >> >>> > >> in xwiki-rest-model-simplexml is added with simple xml >>>> >> annotations, >>>> >> >>> > >> otherwise both modules have same classes. There is no problem >>>> >> >>> > >> with >>>> >> >>> the >>>> >> >>> > >> added annotations for using the same model objects for Json >>>> >> >>> > >> REST >>>> >> web >>>> >> >>> > >> services. And I intend to add my JPA (ORMLite library for >>>> >> >>> persistence) >>>> >> >>> > >> annotations on top of it. >>>> >> >>> > >> Shall I re-factor them to a single module xwiki-rest-model. >>>> >> >>> > > >>>> >> >>> > > No keep them separated, the idea is that both are useful tool >>>> >> >>> > > to be >>>> >> >>> > > used by someone else that might be moved to xwiki-platform at >>>> >> >>> > > some >>>> >> >>> > > point along with the current xwiki-rest-model (to be renamed to >>>> >> >>> > > xwiki-rest-model-jaxb). >>>> >> >>> > > >>>> >> >>> > > Chamika initially started with gson and since XWiki REST JSON >>>> >> >>> > > representation had some limitation he moved to XML >>>> >> >>> > > representation. >>>> >> >>> > > Maybe at some point Android will have native support for jaxb >>>> >> >>> > > which >>>> >> >>> > > would obviously be the easier for us (embedding jaxb is not an >>>> >> option >>>> >> >>> > > in mobile world where size it still pretty important especially >>>> >> >>> > > on >>>> >> >>> > > phones). Maybe it's already the case on most recent versions >>>> >> >>> > > like >>>> >> 4.0 >>>> >> >>> > > I don't know. >>>> >> >>> > >>>> >> >>> > There's also Jackson that could be tried for JSON >>>> >> >>> > deserialization, if >>>> >> >>> > said limitations are actually GSON limitations. >>>> >> >>> > >>>> >> >>> GSON wasn't the limitation. >>>> >> >>> It was XWiki RESTful API which doesn't support JSON in some cases. >>>> >> >>> So >>>> >> it's >>>> >> >>> safe to go with xml. >>>> >> >>> >>>> >> >>> > >>>> >> >>> > Having full JAXB support sound a bit overweight for such an >>>> >> >>> > "embedded >>>> >> >>> > API", even if one day it is natively supported by Android. What's >>>> >> >>> > important is to have an easy and fast deserialization, IMO. >>>> >> >>> > The only advantage I can see of going JAXB would be in re-using >>>> >> >>> > the >>>> >> >>> > exact representations and body readers/writers from XWiki core. >>>> >> >>> > But >>>> >> >>> > you probably don't even want to do that since it would mean >>>> >> >>> > dragging >>>> >> >>> > XWiki core with you :) >>>> >> >>> > >>>> >> >>> > Jerome >>>> >> >>> > >>>> >> >>> > > >>>> >> >>> > >> >>>> >> >>> > >> [3] INFO >>>> >> >>> > >>  I had to change some pom.xml s. As the current project at: >>>> >> >>> > >> https://github.com/xwiki-contrib/android-client.gitdoes not >>>> >> build. >>>> >> >>> > Error >>>> >> >>> > >> with parent pom.xml coordinates. >>>> >> >>> > > >>>> >> >>> > > You probably did not setup you maven install properly since >>>> >> >>> > > what's >>>> >> on >>>> >> >>> > > https://github.com/xwiki-contrib/android-client.gitbuild >>>> >> perfectly >>>> >> >>> as >>>> >> >>> > > you can see on >>>> >> http://ci.xwiki.org/view/All/job/xwiki-android-client/ >>>> >> >>> > > which run a build every time something changes on the git >>>> >> repository.. >>>> >> >>> > > You should look at >>>> >> >>> > > http://dev.xwiki.org/xwiki/bin/view/Community/Building. >>>> >> >>> > > >>>> >> >>> > >> >>>> >> >>> > >> >>>> >> >>> > >> Thank you >>>> >> >>> > >> Best Regards. >>>> >> >>> > >> Sasinda Rukshan >>>> >> >>> > >> _______________________________________________ >>>> >> >>> > >> devs mailing list >>>> >> >>> > >> devs(a)xwiki.org >>>> >> >>> > >> http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > > >>>> >> >>> > > -- >>>> >> >>> > > Thomas Mortagne >>>> >> >>> > > _______________________________________________ >>>> >> >>> > > devs mailing list >>>> >> >>> > > devs(a)xwiki.org >>>> >> >>> > > http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > -- >>>> >> >>> > Jérôme Velociter >>>> >> >>> > Winesquare >>>> >> >>> > http://www.winesquare.net/ >>>> >> >>> > _______________________________________________ >>>> >> >>> > devs mailing list >>>> >> >>> > devs(a)xwiki.org >>>> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>> > >>>> >> >>> _______________________________________________ >>>> >> >>> devs mailing list >>>> >> >>> devs(a)xwiki.org >>>> >> >>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>> >>>> >> >> >>>> >> >> >>>> >> > _______________________________________________ >>>> >> > devs mailing list >>>> >> > devs(a)xwiki.org >>>> >> > http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Thomas Mortagne >>>> >> _______________________________________________ >>>> >> devs mailing list >>>> >> devs(a)xwiki.org >>>> >> http://lists.xwiki.org/mailman/listinfo/devs >>>> >> >>>> > _______________________________________________ >>>> > devs mailing list >>>> > devs(a)xwiki.org >>>> > http://lists.xwiki.org/mailman/listinfo/devs >>>> >>>> >>>> >>>> -- >>>> Thomas Mortagne >>> >>> >> >> >> >> -- >> Thomas Mortagne > > > > -- > Thomas Mortagne -- Thomas Mortagne