On the topic of moving stuff out of core we already have the following 2 threads: * http://markmail.org/message/viesrhmdavyvdaec * http://markmail.org/message/y3bkch37mt5iwvxu
To summarize, ATM we’ve discussed about: * xwiki-platform-blog * xwiki-platform-release * xwiki-platform-selenium * some syntaxes: twiki, apt, confluence*, creole, docbook, doxia, jspwiki, tex * some macro transformations: linkchecker, wikiword * some macros like: the ctsreport one Thanks -Vincent > On 11 Sep 2016, at 19:21, Vincent Massol <[email protected]> wrote: > > Hi Thomas, > >> On 11 Sep 2016, at 17:16, Thomas Mortagne <[email protected]> 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) >> * 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 > > 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
