OK so let me introduce my third (3) proposal properly. 3.1 - Only one WAR, containing only what we consider as core extensions. There is nothing to exclude, we manually select the modules that are indispensable so that oldcore and DW can run.
3.2 - For the Jetty/HSQLDB packaging, we use my plugin that pre-installs the extensions needed by the default flavor. 3.3 - Drop support for "ui-all" xars. Knowing that in a near future, we will let the user chose a flavor, we won't propose "ui-all" xars for all of them along with a proper WAR to run them. That should cover our use-cases. Note that when multiple flavors will be released, we won't have a Jetty/HSQLDB packaging for each one. Thanks, 2016-08-29 13:28 GMT+02:00 Thomas Mortagne <[email protected]>: > On Mon, Aug 29, 2016 at 11:56 AM, Vincent Massol <[email protected]> > wrote: > > Sending this summary email because I was a bit lost and had the feeling > we were talking at cross-purpose. So here’s my summary on this topic: > > > > - Originally Marius proposed 2 solutions based on some discussions with > Thomas: > > > > Solution 1: 2 XE WARs > > Solution 2: Exclude the JARs we don't want as core extensions from the > XE pom > > > > For each solution Marius listed drawbacks. > > > > For solution 1, he listed: > > * A) we don't fix the problem for the Jetty+HSQLDB distribution > > * B) the ui-all XAR would work only with the "all" WAR (the first one > that bundles the XAR dependencies) > > > > For solution 2 he listed: > > * The problem with this solution is the maintenance cost. We'll forget > for sure to exclude/install the JAR in XE's pom whenever we add a new JAR > > dependency to one of the contrib extensions that are bundled in XE > (CKEditor and Tour for the moment). > > > > Marius suggested that all in all he thinks that solution (1) seems the > best and asked for other ideas. > > > > - Thomas replied saying that for him 2 is better but 1 is enough. > > No It's not what I answered. I answered that the RESULT of 2 is > better. But as Marius said it's too much of a pain to maintain which > is why I said we should do 1 for now and see if we can find a better > solution for the jetty/hsqldb (which is what Guillaume proposed). > > You should differentiated what we distribute and how we end up with > it. Marius is only detailed the "how to" here but in both solutions he > proposed you get the exact same thing for WAR installs: a WAR without > the jars we want to be seen as installed extensions instead of core > extensions that will come as dependencies of the flavor. > > In your case you assumed that we want to have everything in the WAR > and all your proposals are following this assumption (and that's also > the reason why you rejected Guillaume's idea) but I really don't think > it's a requirement here. > > > > > - Since Marius asked for other ideas (because none of the proposed > solution was perfect according to Marius), I proposed Solution 3. > > > > Solution 3: Define a mechanism in our distribution to install some > extensions as non-core extensions (based on a WEB-INF/extensions mechanism) > > > > - Then Guillaume replied (and I didn’t know he was talking about > Solution 1 at the time hence our misunderstanding!), providing an answer > for problem 1) A). > > > > Shall I conclude that we think that solution 1 (2 WARs) is what we > should do now and that problem 1) B) is not a blocker? Fo we have a > solution for it? > > > > Also, can solution 1) be our long-term solution or do we still need a > better solution? In this case is 2) better? Is solution 3) needed (I agree > it’s better to not implement it if we can do without). > > > > Thanks > > -Vincent > > > >> On 29 Aug 2016, at 10:46, Thomas Mortagne <[email protected]> > wrote: > >> > >> I agree with Guillaume here. The subject of the discussion started by > >> Marius is no to package anything in the WAR, the subject is to have > >> CKEditor fully being seen as an extension like XAR extensions are so > >> that it can be upgraded. Like Guillaume said XAR extensions are not > >> packaged in the WAR so there is no reason to decide that it's > >> mandatory for JARs extensions. > >> > >> Marius already proposed an easy solution for WAR based installs (1: > >> remove the dependencies on XARs in the WAR project which essentially > >> means removing a hack). Guillaume's plugins fix the issue for > >> jetty/hsqldb so it seems to me we have everything we need. The > >> priority IMO is to fix the issue for WAR installs (A.K.A. "real > >> installs") quickly and then finish standardize a bit more what > >> Guillaume started. > >> > >> > >> On Mon, Aug 29, 2016 at 10:31 AM, Vincent Massol <[email protected]> > wrote: > >>> > >>>> On 29 Aug 2016, at 10:25, Guillaume Delhumeau < > [email protected]> wrote: > >>>> > >>>> 2016-08-22 12:00 GMT+02:00 Vincent Massol <[email protected]>: > >>>> > >>>>> > >>>>>> On 22 Aug 2016, at 11:58, Vincent Massol <[email protected]> > wrote: > >>>>>> > >>>>>> > >>>>>>> On 22 Aug 2016, at 11:45, Guillaume Delhumeau < > >>>>> [email protected]> wrote: > >>>>>>> > >>>>>>> I had a similar problem in a custom flavor for XWiki SAS. For the > >>>>>>> Jetty/HSQL package, I made a custom maven plugin, based on the > packager > >>>>>>> plugin, which install all JAR dependencies in "data/extensions" > instead > >>>>> of > >>>>>>> WEB-INF/lib, and I did not include these dependences in the WAR > >>>>>>> > >>>>>>> See: > >>>>>>> https://github.com/xwikisas/xcs/tree/master/xcs-tools/xcs- > >>>>> tools-dependenciespackager > >>>>>> > >>>>>> Thanks Guillaume. We mentioned this but it doesn’t work for the WAR > >>>>> packaging. > >>>>> > >>>>> Forgot the end of my sentence :) Here it is: > >>>>> > >>>>> That’s why I would prefer a solution that allow to auto-deploy some > >>>>> extensions and have it packaged inside the WAR (see my previous > answer for > >>>>> more details). > >>>>> > >>>> > >>>> I don't see where you explain "why" you would prefer an other > solution. > >>>> > >>>> Actually, I don't see any drawback with my current implementation: > >>>> - for Jetty/HSQLDB, my plugin installs the extension correctly, both > in the > >>>> "data/extensions" directory and in the database. > >>>> - for the WAR packaging, Distribution Wizard is already started > during the > >>>> first execution. > >>> > >>> If you put your extensions in data/extensions then you won’t have them > in the WAR since the WAR doesn’t package the data dir… So I don’t see how > your solution helps at all. > >>> > >>> The goal is to be able to package some extensions that are not core > extensions in our packagings (and distribute those packagings). The main > packaging is the WAR one and it needs to be supported. > >>> > >>> Thanks > >>> -Vincent > >>> > >>>> Bundling the dependencies in some directory inside the WAR has not > much > >>>> sense here, since we already don't do it for XAR extensions. Except > if we > >>>> want to be able to run DW without an Internet connection, and in this > case > >>>> we should also include all needed XARs. But again, it does not make > much > >>>> sense: we won't bundle all possible flavors. > >>>> > >>>> What we only needs is to put my plugin in contrib or in platform, but > for > >>>> doing it properly we need to do some refactoring with Thomas. > >>>> > >>>> Thanks, > >>>> > >>>> > >>>>> > >>>>> Would be great to have some opinions on the few proposals I made. I > think > >>>>> we need to move on quite quickly on this topic. It’s going to be a > problem > >>>>> for our users quite soon now. > >>>>> > >>>>> Thanks > >>>>> -Vincent > >>>>> > >>>>>> > >>>>>> Thanks > >>>>>> -Vincent > >>>>>> > >>>>>>> > >>>>>>> 2016-08-16 21:03 GMT+02:00 Vincent Massol <[email protected]>: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 16 Aug 2016, at 19:18, Vincent Massol <[email protected]> > wrote: > >>>>>>>>> > >>>>>>>>> Interesting problem :) > >>>>>>>>> > >>>>>>>>> So the CKEditor extension should not be considered a core > extension, > >>>>>>>> i.e. it should not find its way in WEB-INF/lib. > >>>>>>>>> > >>>>>>>>> One idea to achieve this is to allow bundling some uninstalled > >>>>>>>> extensions in WEB-INF (for example inside WEB-INF/extensions) and > have > >>>>>>>> XWiki install them when it starts the first time (as a DW step for > >>>>> example). > >>>>>>>>> > >>>>>>>>> Basically they’re considered as bundled third-party extensions > and not > >>>>>>>> as core extensions, and we define a mechanism to bundle > third-party > >>>>>>>> extensions inside an XWiki WAR. > >>>>>>>>> > >>>>>>>>> For the Jetty/HSQLDB distribution, we could install them directly > >>>>> since > >>>>>>>> we have access to the permanent directory. But we could also > leave it > >>>>> as > >>>>>>>> part of a DW step. > >>>>>>>>> > >>>>>>>>> WDYT? > >>>>>>>> > >>>>>>>> Note that an alternative would be to map WEB-INF/extensions as an > >>>>>>>> additional extension repository. However, an important issue with > this > >>>>>>>> would be that a WAR file should be considered as read only by > servlet > >>>>>>>> containers (they can do whatever they want with it, expand it in > some > >>>>>>>> custom directory, etc) and thus it would not be possible to > >>>>> remove/update > >>>>>>>> extensions. This is why I proposed that WEB-INF/extensions would > >>>>> contain > >>>>>>>> uninstalled extensions that XWiki would need to install. > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> -Vincent > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> -Vincent > >>>>>>>>> > >>>>>>>>>> On 01 Aug 2016, at 14:45, Marius Dumitru Florea < > >>>>>>>> [email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi devs, > >>>>>>>>>> > >>>>>>>>>> Thomas raised this issue http://jira.xwiki.org/browse/XE-1570 > . One > >>>>> of > >>>>>>>> the > >>>>>>>>>> reasons we decided to keep the CKEditor Integration extension in > >>>>>>>> contrib, > >>>>>>>>>> with its own release cycle, was to allow the users to upgrade it > >>>>> without > >>>>>>>>>> the need to upgrade the entire XWiki distribution. > >>>>>>>>>> > >>>>>>>>>> There wouldn't be any problem if the CKEditor Integration > extension > >>>>>>>> didn't > >>>>>>>>>> had any JAR dependencies. But it depends on the CKEditor WebJar > which > >>>>>>>> ends > >>>>>>>>>> up in the XWiki WAR and thus is considered a core extension, > and core > >>>>>>>>>> extensions cannot be upgraded. > >>>>>>>>>> > >>>>>>>>>> Here's what happens: > >>>>>>>>>> * xwiki-enterprise-ui-common depends on ckeditor-ui ( > >>>>>>>>>> https://github.com/xwiki/xwiki-enterprise/blob/xwiki- > >>>>>>>> enterprise-8.2.1/xwiki-enterprise-ui/xwiki- > >>>>> enterprise-ui-common/pom.xml# > >>>>>>>> L168 > >>>>>>>>>> ) > >>>>>>>>>> * both xwiki-enterprise-ui-mainwiki and xwiki-enterprise-ui-wiki > >>>>> depend > >>>>>>>> on > >>>>>>>>>> xwiki-enterprise-ui-common > >>>>>>>>>> * xwiki-enterprise-web depends on both > xwiki-enterprise-ui-mainwiki > >>>>> and > >>>>>>>>>> xwiki-enterprise-ui-wiki ( > >>>>>>>>>> https://github.com/xwiki/xwiki-enterprise/blob/xwiki- > >>>>>>>> enterprise-8.2.1/xwiki-enterprise-web/pom.xml#L837 > >>>>>>>>>> ) in order to "transitively include all JAR dependencies in the > >>>>>>>> generated > >>>>>>>>>> WAR" > >>>>>>>>>> > >>>>>>>>>> So the ckeditor-webjar ends up in the XE WAR, thus it becomes a > core > >>>>>>>>>> extension. In order to fix this Thomas has proposed two > solutions: > >>>>>>>>>> > >>>>>>>>>> (1) Build 2 XE WARs: one that bundles the transitive JAR > >>>>> dependencies of > >>>>>>>>>> the UI (what we have currently) and one that doesn't bundle > them. We > >>>>>>>> would > >>>>>>>>>> offer only the later for download on xwiki.org, > >>>>>>>>>> knowing that the transitive JAR dependencies will be installed > when > >>>>> the > >>>>>>>> UI > >>>>>>>>>> is installed (with the Distribution Wizard for instance). The > first > >>>>> WAR > >>>>>>>>>> would be used only for building the Jetty+HSQLDB distribution. > >>>>>>>>>> > >>>>>>>>>> The downside of this solution is: > >>>>>>>>>> * we don't fix the problem for the Jetty+HSQLDB distribution > >>>>>>>>>> * the ui-all XAR would work only with the "all" WAR (the first > one > >>>>> that > >>>>>>>>>> bundles the XAR dependencies) > >>>>>>>>>> > >>>>>>>>>> (2) Exclude the JARs we don't want as core extensions from > >>>>>>>>>> https://github.com/xwiki/xwiki-enterprise/blob/xwiki- > >>>>>>>> enterprise-8.2.1/xwiki-enterprise-web/pom.xml#L837 > >>>>>>>>>> , one by one. This would fix the WAR-based installations but > not the > >>>>>>>>>> Jetty+HSQLDB distribution which uses the Import Mojo ( > >>>>>>>>>> https://github.com/xwiki/xwiki-enterprise/blob/xwiki- > >>>>>>>> enterprise-8.2.1/xwiki-enterprise-data/pom.xml#L145 > >>>>>>>>>> ) to generate the distribution data folder and thus won't get > the > >>>>>>>>>> ckeditor-webjar. For this we would need to introduce a new > Install > >>>>> Mojo > >>>>>>>> and > >>>>>>>>>> explicitly install the JAR dependecies we want (ckeditor-webjar > in > >>>>> this > >>>>>>>>>> case). > >>>>>>>>>> > >>>>>>>>>> The problem with this solution is the maintenance cost. We'll > forget > >>>>> for > >>>>>>>>>> sure to exclude/install the JAR in XE's pom whenever we add a > new JAR > >>>>>>>>>> dependency to one of the contrib extensions that are bundled in > XE > >>>>>>>>>> (CKEditor and Tour for the moment). > >>>>>>>>>> > >>>>>>>>>> Do you have any other ideas? > >>>>>>>>>> > >>>>>>>>>> Solution (1) seems the best so far. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Marius > >>> _______________________________________________ > >>> 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 > > > > -- > 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
