Some news about that.
After having done more tests (most of them with the new improvements on the
Menu Application done by Caty
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 <thomas.mortagne(a)xwiki.com>om>:
On Wed, Dec 17, 2014 at 5:04 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> 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-Less…
* 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 (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the
XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the