Some news about that. After having done more tests (most of them with the new improvements on the Menu Application done by Caty http://jira.xwiki.org/browse/XWIKI-11408), I have reached 2 bugs on less4j: - https://github.com/SomMeri/less4j/issues/246 - https://github.com/SomMeri/less4j/issues/247
The second bugs breaks XWIKI-11408. On the other hand, the current implementation, with the official lessjs compiler, breaks XWIKI-11408 too. Fortunately, Caty managed to re-write XWIKI-11408 with the limitation that I have introduced previously (not using .extend()) with lessjs. The result is not as good as her previous shot but this is the best we can do now. So I update my proposal and I now propose to put less4j by default as soon as they fix the blocking issue, so that we can put back the first version of the Caty's work and enjoy it. Sorry for all these changes, I really wanted to commit something good before M2, but since we are probably going to have a M3, we will have some air to tests things serenely. Thanks, Guillaume 2014-12-18 10:50 GMT+01:00 Thomas Mortagne <[email protected]>: > > On Wed, Dec 17, 2014 at 5:04 PM, Guillaume "Louis-Marie" Delhumeau > <[email protected]> wrote: > > Hi developers. > > > > I have recently implemented the ability to use LESS in SSX: > > http://jira.xwiki.org/browse/XWIKI-10708. > > > > This feature has pointed me out some bugs, that are reported upstream: > > https://github.com/less/less.js/issues/1878 > > https://github.com/less/less.js/issues/1968 > > > > I have tried to implement a workaround, but as a result, it is preventing > > us to use an important feature of LESS: .extend(). And it simply breaks > the > > Caty work on the Menu Application. > > > > Moreover, LESS has been rewritten in version 2. But because of this > > refactoring, the Rhino version does not work. See: > > https://github.com/less/less.js/issues/2316 > > > > So we are stuck with the current version of LESS, with the bugs listed > > above (that I am not able to patch). > > > > But in parallel, I have worked to use LESS4j instead of the official LESS > > project (http://jira.xwiki.org/browse/XWIKI-11034). And today, I finally > > managed to make it work! > > > > The good news is that LESS4j does not have the bugs that are blocking us. > > > > I propose to commit this for 6.4M2 (before tomorrow), and we can still > > revert it afterwards. > > > > Advantages of LESS4j: > > * should be quicker (see: > > https://github.com/xwiki-contrib/less-vs-sass-benchmark) > > * does not have the bugs listed above > > * we can hope that the version 2 will be ported to LESS4j too. > > > > Drawbacks of LESS4j: > > * maintained by only one developer (but reactive when I report bugs) > > * not exactly the same behaviour than LESS: > > > https://github.com/SomMeri/less4j/wiki/Differences-Between-Less.js-and-Less4j > > * maybe the error messages are less kindly than lessjs ones. > > > > My implementation is configurable: an administrator can decide to use the > > LESS official version by changing a property in xwiki.properties. I just > > propose to have LESS4j by default. > > > > Here is my +1. > > > > Thanks, > > -- > > Guillaume Delhumeau ([email protected]) > > Research & Development Engineer at XWiki SAS > > Committer on the XWiki.org project > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > +1 > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
