One more pro argument for LESS: - the majority of bootstrap theme that we find in the web are written with LESS. So using LESS make XWiki compatible with them.
2014-05-12 18:09 GMT+02:00 Thomas Mortagne <[email protected]>: > On Mon, May 12, 2014 at 6:01 PM, [email protected] <[email protected]> > wrote: > > > > > > > > > > On 12 May 2014 at 17:51:32, Guillaume Louis-Marie Delhumeau ( > [email protected](mailto:[email protected])) wrote: > > > >> Just some arguments to take under consideration: > >> > >> - do we want to add the bootstrap mixins and CSS preprocessors features > in > >> the SSX objects? If so, then having a CSS preprocessor that caches the > >> bootstrap sources seems good. > >> > >> - with SASS, it is easy to add a path where to find the includes. With > >> LESS, it does not work with the Rhino version (it uses some stuff > related > >> to NodeJS). Even by modifying a bit the LessC source file, I haven't > >> managed to make it work. > >> > >> I also prefer the LESS syntax + the fact that it is the default syntax > of > >> Bootstrap, but technically, I find more and more reasons to prefer > SASS... > >> > >> --- > >> > >> We need to make a decision now, we should not wait anymore. > >> > >> LESS pros: > >> - Syntax closer to CSS > >> - Syntax not to much similar to Velocity > >> - the Boostrap's choice > >> - Very popular > >> - Caty, Denis and I like it! > >> > >> LESS cons: > >> - The java part uses Rhino and is less customizable > >> - No cache system > >> - include-path does not work with the java version so how could we > handle > >> the @import command? > >> > >> SASS pros: > >> - Good extensibility using JRuby > >> - Include-path works well > >> - Cache system so we can import Bootstrap mixin's in our SSX with better > >> performances > >> > >> SASS cons: > >> - Syntax closer to Velocity > > > > - Requires JRuby which we shouldn’t provide by default ideally whereas > Rhino is bundled in the JDK. > > In the JDK but no the JRE and XWiki does not require the JDK. > > > > > Thanks > > -Vincent > > > >> Guillaume > >> > >> > >> > >> 2014-05-06 10:02 GMT+02:00 Ecaterina Moraru (Valica) : > >> > >> > My personal opinion about LESS vs. Saas is that I prefer LESS, > >> > both from a syntax non-similarity point of view, > >> > but also because it's more close to the original CSS specifications > and > >> > thus they are more likely to keep things separate/simpler (separation > of > >> > concern of presentation vs. control structures that add complexity > and that > >> > can be achieved by a dedicated language). > >> > > >> > But this preference is more of a hunch than an experimented study, so > we > >> > can further analyze the performance and other aspects in order to get > a > >> > conclusion. > >> > Thanks, > >> > Caty > >> > > >> > > >> > On Mon, May 5, 2014 at 11:53 PM, Denis Gervalle wrote: > >> > > >> > > Hi devs, > >> > > > >> > > I am jumping in late on this debate, so do not baffle me if I have > missed > >> > > something. IMO the performance should not be a priority criteria. > >> > > Performance could always be improved over time, and may vary in any > >> > > implementation to became better but also worse. So, our decision > should > >> > be > >> > > more based on proposed features, our perception of the popularity > and > >> > > community, and also our taste, even if this could be subjective. > >> > > > >> > > Like Cathy, I am very concerned by the similarity of SASS and > Velocity, > >> > and > >> > > I see this as a misfeature of SASS for us. On an technical point of > view, > >> > > SASS seems more robust and complete than LESS, but is also a bit > more > >> > > complex and less easy to adopt. Even if not really relevant here, I > like > >> > > the idea that LESS could work client side thanks to its javascript > based > >> > > implementation. > >> > > > >> > > Bootstrap is initially made with LESS (which probably boost the > >> > popularity > >> > > of it) and since we choose Bootstrap, it seems also quite natural to > >> > prefer > >> > > LESS like they do (I would have said just the opposite if we had > opted to > >> > > adopt, lets say, Compass, which is a framework based on SASS). > >> > > > >> > > My perception of the community of both is quite the same, there is > not > >> > that > >> > > much contribution to any of them, since both are mainly driven by > one or > >> > > two developers. LESS appears after SASS and have gained popularity, > >> > enough > >> > > to be adopted by Bootstrap, does it looks like a indication... this > is > >> > > probably a bit misleading, but once again we choose Bootstrap. > >> > > > >> > > Performance seems to reflect the same as my perception of the > technical > >> > > aspect of these products. SASS is more mature and complete, and > therefore > >> > > it has been a bit more optimized, but LESS is not that bad and will > >> > surely > >> > > improve over time as well. > >> > > > >> > > So, you have probably decoded my though from the above, I have the > >> > feeling > >> > > that currently LESS fits better for us than SASS. Maybe we will > have to > >> > > adopt both in the end, but I would start with LESS. > >> > > > >> > > This was just my personal thoughts, thanks for reading, > >> > > > >> > > > >> > > > >> > > On Mon, May 5, 2014 at 5:44 PM, Guillaume "Louis-Marie" Delhumeau < > >> > > [email protected]> wrote: > >> > > > >> > > > Update: > >> > > > > >> > > > SASS have good performances because it does not always compute > all the > >> > > > sources. All imported files (using @import) are cached and not > >> > recompiled > >> > > > when there is not change on these files. > >> > > > > >> > > > It is good if we often recompute flamingo (that does a lot of > @import), > >> > > but > >> > > > it means that the SASS' performances are not that better than > LESS' > >> > when > >> > > it > >> > > > comes to compile new files, which can happen every-time we will > >> > compile a > >> > > > SSX object in the future (if we decide to). > >> > > > > >> > > > So I have done a benchmark without the cache, and then the > performances > >> > > of > >> > > > SASS are quite the same than LESS, but a bit slower (see: > >> > > > https://github.com/xwiki-contrib/less-vs-sass-benchmark ). > >> > > > > >> > > > Other thing to consider: > >> > > > In both LESS and SASS, it is possible to set a directory where the > >> > > imported > >> > > > files are searched. So we can add bootstrap sources in every SSX > >> > objects > >> > > so > >> > > > that users can use Bootstrap mixins (good thing IMO). > >> > > > > >> > > > In this case, it will be good to have the cache system that SASS > has. > >> > > > > >> > > > Thanks, > >> > > > Guillaume > >> > > > > >> > > > > >> > > > 2014-04-30 15:17 GMT+02:00 Thomas Mortagne > > >: > >> > > > > >> > > > > On Wed, Apr 30, 2014 at 3:16 PM, Thomas Mortagne > >> > > > > wrote: > >> > > > > > On Wed, Apr 30, 2014 at 3:04 PM, Caleb James DeLisle > > > > >> > > > > wrote: > >> > > > > >> > >> > > > > >> > >> > > > > >> On 04/30/2014 02:59 PM, Thomas Mortagne wrote: > >> > > > > >>> On Wed, Apr 30, 2014 at 2:33 PM, Caleb James DeLisle < > >> > [email protected] > >> > > > > >> > > > > wrote: > >> > > > > >>>> https://encrypted.google.com/search?q=less+css -> About > >> > > 116,000,000 > >> > > > > results (less is a common word so this is skewed) > >> > > > > >>>> https://encrypted.google.com/search?q=sass+css -> About > >> > 2,480,000 > >> > > > > results > >> > > > > >>>> > >> > > > > >>>> https://github.com/less/less.js -> 1756 commits, 152 > >> > > contributors, > >> > > > > 2296 forks > >> > > > > >>>> https://github.com/nex3/sass -> 5554 commits, 135 > contributors, > >> > > 650 > >> > > > > forks > >> > > > > >>>> > >> > > > > >>>> Less feels a bit safer from a community standpoint, > >> > > > > >>> > >> > > > > >>>> both have java/C/ruby/js implementations (node-sass is a > binding > >> > > to > >> > > > > the C version). > >> > > > > >>> > >> > > > > >>> No they don't, the only working implementation of less is > in js > >> > for > >> > > > > example. > >> > > > > >> > >> > > > > >> > >> > > > > >> https://github.com/less/less.ruby > >> > > > > >> https://github.com/marceloverdijk/lesscss-java <-- wrapper > around > >> > > the > >> > > > > js impl w/ rhino > >> > > > > > > >> > > > > > "working" was an important detail. Guillaume already tried > >> > > > > > https://github.com/marceloverdijk/lesscss-java. > >> > > > > > >> > > > > Actually I tough you were talking about another one, If you > really > >> > > > > look at the detail you will see this one is using rhino so no > it's > >> > not > >> > > > > a java implementation. > >> > > > > > >> > > > > > > >> > > > > >> https://github.com/BramvdKroef/clessc > >> > > > > >> > >> > > > > >> > >> > > > > >>> > >> > > > > >>>> > >> > > > > >>>> These numbers seem to be suggesting that consensus will > form > >> > > around > >> > > > > Less if anything. > >> > > > > >>>> > >> > > > > >>>> Thanks, > >> > > > > >>>> Caleb > >> > > > > >>>> > >> > > > > >>>> > >> > > > > >>>> On 04/30/2014 01:22 PM, Guillaume "Louis-Marie" Delhumeau > wrote: > >> > > > > >>>>> One point in favour of SASS (SCSS): it seems more > customizable. > >> > > For > >> > > > > >>>>> example, we can define our own SASS functions (like > >> > > > > >>>>> xwiki-colortheme-get('variable_name')) or our own > Importer (for > >> > > > > example, > >> > > > > >>>>> @import will not look in the filesystem but somewhere in > our > >> > > XWiki > >> > > > > >>>>> instance). > >> > > > > >>>>> > >> > > > > >>>>> In this case, we can simply avoid using velocity. > >> > > > > >>>>> > >> > > > > >>>>> See: > >> > > > > >>>>> > >> > > > > > >> > > > > >> > > > >> > > http://sass-lang.com/documentation/file.SASS_REFERENCE.html#defining_custom_sass_functions > >> > > > > >>>>> > >> > > > > >>>>> > >> > > > > >>>>> > >> > > > > >>>>> 2014-04-29 15:35 GMT+02:00 Jeremie BOUSQUET < > >> > > > > [email protected]>: > >> > > > > >>>>> > >> > > > > >>>>>> 2014-04-29 9:58 GMT+02:00 Caleb James DeLisle : > >> > > > > >>>>>> > >> > > > > >>>>>>> My 2 cents worth is all that matters is community. > >> > > > > >>>>>>> Between Groovy, Velocity (I think we're now the biggest > user > >> > of > >> > > > > that) and > >> > > > > >>>>>>> prototypejs, we're pretty good at backing the wrong > horse. > >> > > > > >>>>>>> > >> > > > > >>>>>>> > >> > > > > >>>>>> That may be right but as of now at least, > groovy/velocity are > >> > > > > popular at > >> > > > > >>>>>> least among xwiki current users (dev oriented ones). > >> > > > > >>>>>> I'm really glad personally that you didn't choose PHP or > JSPs > >> > > even > >> > > > > if they > >> > > > > >>>>>> were (and are) far more popular than Velocity ... ;) > >> > > > > >>>>>> > >> > > > > >>>>>> > >> > > > > >>>>>>> In 3-5 years, one of LESS/SASS (or perhaps something > else > >> > > > > entirely) will > >> > > > > >>>>>> be > >> > > > > >>>>>>> the standard for CSS preprocessing and the other will > be a > >> > > > > historical > >> > > > > >>>>>>> amusement. > >> > > > > >>>>>>> > >> > > > > >>>>>> > >> > > > > >>>>>> Maybe CSS preprocessing as we know now, will be a > historical > >> > > > > amusement. > >> > > > > >>>>>> It's still very very young. To me it mostly looks like > hacks > >> > > added > >> > > > > to > >> > > > > >>>>>> workaround things that pure css SHOULD manage ideally, or > >> > should > >> > > > > not have > >> > > > > >>>>>> to manage at all... Not saying that css preprocessing is > bad > >> > > > though > >> > > > > of > >> > > > > >>>>>> course :) > >> > > > > >>>>>> The problem is that the "best" and the "most popular" > are not > >> > > > > always the > >> > > > > >>>>>> same ... (to say the least) > >> > > > > >>>>>> > >> > > > > >>>>>> Lets not be the ones left holding the bag. > >> > > > > >>>>>>> > >> > > > > >>>>>>> Thanks, > >> > > > > >>>>>>> Caleb > >> > > > > >>>>>>> > >> > > > > >>>>>>> > >> > > > > >>>>>>> On 04/28/2014 06:01 PM, Guillaume "Louis-Marie" > Delhumeau > >> > > wrote: > >> > > > > >>>>>>>> 2014-04-28 16:33 GMT+02:00 Ecaterina Moraru (Valica) < > >> > > > > >>>>>> [email protected] > >> > > > > >>>>>>>> : > >> > > > > >>>>>>>> > >> > > > > >>>>>>>>> My major concern about Sass is the syntax very > similar to > >> > > > > Velocity and > >> > > > > >>>>>>> the > >> > > > > >>>>>>>>> way we will handle the parsable style sheets. > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> I think you talk about the fact that variables are > prefixed > >> > > with > >> > > > > $ in > >> > > > > >>>>>>> SASS. > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> 2 solutions: > >> > > > > >>>>>>>> - it should be possible to escape the $ when velocity > should > >> > > > > ignore the > >> > > > > >>>>>>>> variable > >> > > > > >>>>>>>> - when the variable does not exist in the velocity > context, > >> > it > >> > > > > displays > >> > > > > >>>>>>>> $variable and it does not fail. > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> I personally prefer LESS for the reason for this > reason, but > >> > > > > regarding > >> > > > > >>>>>>> the > >> > > > > >>>>>>>> performances, we might consider the things > differently, even > >> > > > with > >> > > > > a > >> > > > > >>>>>> cache > >> > > > > >>>>>>>> system (which will be needed anyway). > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> I need more opinions about this. > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> Thanks, > >> > > > > >>>>>>>> Guillaume > >> > > > > >>>>>>>> > >> > > > > >>>>>>>> > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>>> Thanks, > >> > > > > >>>>>>>>> Caty > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>>> On Mon, Apr 28, 2014 at 5:21 PM, Guillaume > "Louis-Marie" > >> > > > > Delhumeau < > >> > > > > >>>>>>>>> [email protected]> wrote: > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>>>> Hi guys. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> Since we did not have made a strong analysis on > SASS, I > >> > have > >> > > > > played a > >> > > > > >>>>>>> bit > >> > > > > >>>>>>>>>> with it to compare. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> Thomas had the intuition that it should perform > faster, > >> > > > because > >> > > > > JRuby > >> > > > > >>>>>>> is > >> > > > > >>>>>>>>> a > >> > > > > >>>>>>>>>> better implementation for Ruby than Rhino is for JS. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> So I have published a little benchmark about them, > that > >> > you > >> > > > can > >> > > > > see > >> > > > > >>>>>>>>> there: > >> > > > > >>>>>>>>>> > https://github.com/xwiki-contrib/less-vs-sass-benchmark > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> The benchmark is about the time that it takes to > compile > >> > > > > Bootstrap. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> The results are very clear, SASS perform 2 times > faster > >> > than > >> > > > > LESS. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> Since it seems easy to switch from LESS to SASS > (bootstrap > >> > > had > >> > > > > >>>>>> written > >> > > > > >>>>>>> a > >> > > > > >>>>>>>>>> converter), maybe we should consider this option. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> Other thing: > >> > > > > >>>>>>>>>> I would like to run Velocity on the sources of my > CSS, in > >> > > > order > >> > > > > to > >> > > > > >>>>>>> easily > >> > > > > >>>>>>>>>> integrate the color theme variables. But it is risky > to > >> > run > >> > > > > velocity > >> > > > > >>>>>> on > >> > > > > >>>>>>>>> the > >> > > > > >>>>>>>>>> whole tree of bootstrap sources (just imagine that > >> > bootstrap > >> > > > > has an > >> > > > > >>>>>>> "#if" > >> > > > > >>>>>>>>>> ID...). > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> So Thomas and I suggest that we can run Velocity on > files > >> > > > > suffixed by > >> > > > > >>>>>>>>>> .scss.vm or .less.vm, to only run velocity on some > files > >> > > (for > >> > > > > >>>>>> example: > >> > > > > >>>>>>>>>> color-theme.less.vm) that we handle. > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> WDYT? > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> Thanks, > >> > > > > >>>>>>>>>> Guillaume > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>> 2014-04-23 17:29 GMT+02:00 Guillaume "Louis-Marie" > >> > > Delhumeau < > >> > > > > >>>>>>>>>> [email protected]>: > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>>>> Hello. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> In 6.0, we have released a first version of > Flamingo. It > >> > > uses > >> > > > > >>>>>>> Bootstrap > >> > > > > >>>>>>>>>>> and the LESS preprocessor during the build to > create the > >> > > > final > >> > > > > >>>>>>>>> style.css > >> > > > > >>>>>>>>>>> file. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> But currently, there is a serious regression > compared to > >> > > > > Colibri: it > >> > > > > >>>>>>>>> does > >> > > > > >>>>>>>>>>> not support color themes. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> So I have started a proposal about the color theme > >> > handling > >> > > > in > >> > > > > >>>>>>>>> Flamingo, > >> > > > > >>>>>>>>>>> that you can see there: > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>> > >> > > > > > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> My conclusion is that we need to integrate the LESS > >> > > > > preprocesor on > >> > > > > >>>>>> the > >> > > > > >>>>>>>>>>> runtime. This way, we can add velocity variables > >> > > > > (corresponding to > >> > > > > >>>>>> the > >> > > > > >>>>>>>>>>> color theme) in our LESS sources BEFORE the LESS > >> > > preprocessor > >> > > > > is > >> > > > > >>>>>>>>>> launched. > >> > > > > >>>>>>>>>>> Doing the opposite, (process velocity after LESS) > causes > >> > > some > >> > > > > >>>>>> problems > >> > > > > >>>>>>>>>> that > >> > > > > >>>>>>>>>>> I have reported on the previous link. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> To me, it would be a good step ahead for proposing > LESS > >> > to > >> > > > our > >> > > > > >>>>>> users. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> Regarding this, some ideas are coming to me: > >> > > > > >>>>>>>>>>> - it is quite easy to integrate LESS since we can > use > >> > Rhino > >> > > > to > >> > > > > >>>>>> launch > >> > > > > >>>>>>>>> the > >> > > > > >>>>>>>>>>> LESS preprocessor (which is a javascript program). > See: > >> > > > > >>>>>>>>>>> https://github.com/sandroboehme/lesscss-java > >> > > > > >>>>>>>>>>> - we need a cache system in order to not always > compute > >> > the > >> > > > > >>>>>> style.css > >> > > > > >>>>>>>>>>> served to the user (performances issue). > >> > > > > >>>>>>>>>>> - we need to add this in the "skin" action. > >> > > > > >>>>>>>>>>> - in the future, we also need to modify the skinx > >> > actions, > >> > > to > >> > > > > enable > >> > > > > >>>>>>> it > >> > > > > >>>>>>>>>>> for Skin Extensions. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> We also need to agree on the use of LESS instead of > >> > SASS. I > >> > > > > have > >> > > > > >>>>>> used > >> > > > > >>>>>>>>>> LESS > >> > > > > >>>>>>>>>>> on Flamingo because Bootstrap has originally been > written > >> > > > with > >> > > > > it > >> > > > > >>>>>>>>>> (although > >> > > > > >>>>>>>>>>> an official SASS port exists), so this choice is not > >> > based > >> > > > on a > >> > > > > >>>>>> strong > >> > > > > >>>>>>>>>>> analysis. Anyway, it looks quite simple to move > from one > >> > to > >> > > > the > >> > > > > >>>>>> other > >> > > > > >>>>>>>>> and > >> > > > > >>>>>>>>>>> it is probably too soon to predict which of these 2 > >> > > > > preprocessors > >> > > > > >>>>>> will > >> > > > > >>>>>>>>>> win > >> > > > > >>>>>>>>>>> on the long term. > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> Do you think I am going in the right direction? > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> Thanks for reading, > >> > > > > >>>>>>>>>>> Guillaume > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>>> > >> > > > > >>>>>>>>>> _______________________________________________ > >> > > > > >>>>>>>>>> devs mailing list > >> > > > > >>>>>>>>>> [email protected] > >> > > > > >>>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>>>>>>> > >> > > > > >>>>>>>>> _______________________________________________ > >> > > > > >>>>>>>>> devs mailing list > >> > > > > >>>>>>>>> [email protected] > >> > > > > >>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>>>>>> > >> > > > > >>>>>>>> _______________________________________________ > >> > > > > >>>>>>>> devs mailing list > >> > > > > >>>>>>>> [email protected] > >> > > > > >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>>>>> > >> > > > > >>>>>>> _______________________________________________ > >> > > > > >>>>>>> devs mailing list > >> > > > > >>>>>>> [email protected] > >> > > > > >>>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>>>> > >> > > > > >>>>>> _______________________________________________ > >> > > > > >>>>>> devs mailing list > >> > > > > >>>>>> [email protected] > >> > > > > >>>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>>> > >> > > > > >>>>> _______________________________________________ > >> > > > > >>>>> devs mailing list > >> > > > > >>>>> [email protected] > >> > > > > >>>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>>>> > >> > > > > >>>> _______________________________________________ > >> > > > > >>>> devs mailing list > >> > > > > >>>> [email protected] > >> > > > > >>>> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >>> > >> > > > > >>> > >> > > > > >>> > >> > > > > >> _______________________________________________ > >> > > > > >> devs mailing list > >> > > > > >> [email protected] > >> > > > > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > -- > >> > > > > > Thomas Mortagne > >> > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Thomas Mortagne > >> > > > > _______________________________________________ > >> > > > > devs mailing list > >> > > > > [email protected] > >> > > > > http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > >> > > > _______________________________________________ > >> > > > devs mailing list > >> > > > [email protected] > >> > > > http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > >> > > > >> > > > >> > > > >> > > -- > >> > > Denis Gervalle > >> > > SOFTEC sa - CEO > >> > > _______________________________________________ > >> > > devs mailing list > >> > > [email protected] > >> > > http://lists.xwiki.org/mailman/listinfo/devs > >> > > > >> > _______________________________________________ > >> > devs mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > > > _______________________________________________ > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
