> 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

Reply via email to