11 Sep
2016
11 Sep
'16
7:33 p.m.
On 11/09/16 19:21, Vincent Massol wrote:
Hi Thomas,
+1
37MB for what is usually just {{code}} macro is a bit annoying.
On 11 Sep 2016, at 17:16, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Are those jetty/hsqldb or WAR sizes ?
I’ve used http://snippets.xwiki.org/xwiki/bin/view/Extension/Size+of+XE+Distributions
which measures the Jetty/HSQLDB packaging.
Apart from the size another important issue is
the number of external
dependencies we have which among other things makes dependency
handling a pain for extensions.
Here are some numbers from the 8.3M1 WAR:
The WEB-INF/lib takes 172M from which only 12M is pure XWiki jars.
In the WAR some of the biggest features are (size are the feature and
the dependencies used only by that feature):
* Full text search (close to 70M)
** Solr (~30M), including probably totally useless Jetty (yes in the
WAR) stuff (~2M)
** Tika (more than 33M probably not far from 40M, lots of small stuff
I was too lazy to count since Tika has an insane dependency tree full
of stuff used only by it)
70M for text search, wow, that’s huge indeed. Are there are ways to take only some parts
of SOLR (We use solr-core (36MB) and solr-solrj (654K))? Maybe we could ask on their
list.
For Tika I see only 2 jars:
* tika-core: 602K
* tika-parsers: 782K
So I see only a total of ~1.5MB. Have I missed some to get 33MB+ you counted?
* Jython and all its standard libraries (37M):
used by code and python macros
Could be good to not use the code macro in the core (I’ve actually always made sure to
not use it in the extensions I wrote) and bring the code macro as flavor dependency only.
I’ve just checked quickly and there are very few places where we use the code macro in
platform. Should be easy to remove those. Then we could move the macro to contrib and
bundle it in the XE flavor for now.
> * Old GWT Editor (~26M)
+1
> * Groovy+Ivy (7M + 1M): not really used in the XE
flavor but required
> to write a scheduler and many contrib extensions use it and don't
> declare it as dependency
-0 this is kind of nice to have {{groovy}} always available for debugging and 7M
is a lot by some standards but it's pretty small as a percentage.
Also +1 the others below...
Thanks,
Caleb
Yep we need to get rid of Groovy in the core. One area is indeed the scheduler extension
and we know we need to replace the xproperty using groovy by an xproperty using wiki
syntax to allow all script languages to be used. I don’t know of other places requiring
absolutely Groovy in the platform. Do you?
Things that would not be too hard to move to
Contrib that would also
take several external jars in their luggage (which is also nice for
extensions, the less core extensions the less dependencies issues):
* Office server related stuff (would probably be a good idea anyway to
synchronize it more with LibreOffice than XWiki)
Yep +1. Might need some additional extension points defined to integrate cleanly with
platform (in create dialog + in WYSIWYG editor).
* Chart macro and renderer
Yep, I don’t know any platform code using that. I’m going to send a proposal email on
this and I could move it.
* Rendering syntaxes not enabled by default (we
already started this
with markdown and mediawiki which are the most used, all the others
are probably never used or very rarely)
Agreed, we have a few more to move out.
* Captcha macro/renderer
Yep
* Formula macro/renderer
Yep
8.3M1 still includes CKEditor and Tour extensions
jars which should
not be there anymore in 8.3 final.
You mean that we should start distributing the platform distribution instead of XE and
make XE a flavor (probably under another name, I’ll send a proposal mail about that) that
users would pick at runtime, right?
[snip]
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs