On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <[email protected]> wrote:
> > > On 07 Jun 2016, at 09:37, Guillaume Delhumeau < > [email protected]> wrote: > > > > Moving Tour Application into platform makes sense to me (it becomes a > > critical component and deserves a proper support). > > > For me, it’s really about the definition of what the XWiki github org > represents. Right now with the new strategy == “Everything needed for the > default XWiki runtime, a.k.a base/default flavor” (what we’ve been calling > XE so far but that we’ll slim down a bit, for example by removing the Blog > app and move it to contrib). > "Everything needed for the default XWiki runtime" is a bit vague. I hope we're not going to move code from platform to contrib and back each time we decide to not bundle or bundle some extension. > > Now we could still decide to have some flavor in contrib and have the tour > app included in that flavor but not in “the default XWiki runtime”. In > practice this would mean promoting this flavor instead of the base/default > flavor. The question will arise anyway when we next talk about other > flavors that we may want to have in contrib such a KB flavor, workgroup > flavor, web flavor, etc. > > > However, the current > > application supports XWiki >= 6.4.1. By moving it to platform, we will > only > > support the last XWiki version. > > This is a tough topic indeed. For the tour there’s the solution of keeping > it in contrib and introducing a flavor but for CKEditor it’s harder to > justify that it’s not part of the base flavor IMO but maybe it’s possible > and we would offer only the wiki editor in the base flavor. Of course we > could modify our functional tests fwk to support running on various > versions of the dependencies and have CI builds to ensure that an extension > works with all versions but it’s not perfect and it would mean that for the > first time we would have code in the xwiki github org that would not use > the latest APIs/latest JDK features. > > The other option is Marius’s, i.e. accept that we hand-pick some > extensions from contrib that we bundle in the base/default flavor such as > the Tour app, CKEditor integration, etc. In this case, we would just need > to redefine what “xwiki github org” means. Saying “core component” would > not be enough, it would needs a more precise definition. > > Interesting topic ;) > > Any other option that we have? > > Thanks > -Vincent > > > 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: > > > >> > >>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < > >> [email protected]> wrote: > >>> > >>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <[email protected]> > >> wrote: > >>> > >>>> > >>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < > >>>> [email protected]> wrote: > >>>>> > >>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < > >>>>> [email protected]> wrote: > >>>>> > >>>>>> Hello all, > >>>>>> > >>>>>> As it was decided already, a Homepage Tour have to be implemented. > >>>> However, > >>>>>> no option regarding the place where the Tour Application should be > >>>> added as > >>>>>> dependency was discussed. > >>>>>> > >>>>>> There are some possible options: > >>>>>> 1) XWiki Enterprise > >>>>>> 2) XWiki Platform Distribution > >>>>>> 3) XWiki Platform Helper > >>>>>> > >>>>>> 4) Is there any option to have the Tour Application as a part of the > >>>> Core ? > >>>>>> > >>>>>> What would be the best way to include the Contrib applications in > >> XWiki? > >>>>>> > >>>>> > >>>>> On this topic (sorry if I hijack your thread) I was wondering why > don't > >>>> we > >>>>> have dependencies from platform/enterprise to contrib. We have lots > of > >>>>> third party dependencies, contrib could be considered as such. > >> Moreover, > >>>>> we're in the process of moving non-core (vertical) extensions out of > >>>>> platform to contrib. It would be a pity to move something from > contrib > >> to > >>>>> platform and then back to contrib. I have the same issue with the > >>>> CKEditor > >>>>> Integration extension. We want CKEditor as the default editor, > bundled > >>>> with > >>>>> the default distribution, but do we need to move it to platform? Same > >> for > >>>>> the Welcome Tour. > >>>> > >>>> I’d personally not like this for the following reasons: > >>>> > >>>> > >>> > >>>> 1) I like that the XWiki runtime is all released at once with all > >>>> extensions making it using the same versions and verified to work > >> together. > >>>> > >>> > >>> XWiki runtime has lots of third party dependencies. Bootstrap, Solr, > >>> jQuery, just to name a few. I don't see how having the source code in > our > >>> repo (platform) makes a difference at runtime when the > >>> integration/functional tests verify they work together. > >> > >> Because they don’t! :) Just check any extension in contrib and you’ll > see > >> their func test (when they have some!) don’t test that they work with > the > >> latest version of XWiki… > >> > >>> 2) Support. The XWiki runtime is supported by the XWiki Core Dev Team. > >>>> Extensions in contrib are not supported by the XWiki Core Dev Team. > >>> > >>> > >>> So the FAQ application you moved out of platform is no longer supported > >> by > >>> the XWiki Core Dev Team? > >> > >> Correct. > >> > >>> The extension page > >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application > >>> doesn't reflect this. > >> > >> I added my name to the list as a supporter. I’ve kept “XWiki Dev Team” > >> because it's a past authors and it wouldn’t make sense to remove it. But > >> yes it’s no longer officially supported by the XWiki Core Dev Team. > >> > >> Note that e.x.o doesn’t say who maintains a given extension, it just > says > >> who participated to developing it ;) We’re currently missing the info on > >> whether the extension is actively supported and by whom. FTR Confluence > >> does this with a “supported” label that you can hover over and provides > >> info. For example: > >> > https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.numberedheadings/cloud/overview > >> > >> Thanks > >> -Vincent > >> > >>> In addition xwiki-contrib is very open and anyone can make > modifications > >>>> there and quality is thus harder to guarantee. > >>>> > >>>> We defined the xwiki github organization as containing horizontal > >> modules, > >>>> ie modules that can be required for any flavor and both CKEditor and > the > >>>> Tour Application fit the need. By opposition to vertical modules which > >> make > >>>> sense only for some use cases (like the Meeting Manager app) and not > by > >>>> default in XE. We have the option of having flavors in contrib for > >> those if > >>>> we want though. For CKEditor it’s not a good thing since we’d like it > by > >>>> default. > >>>> > >>>> One alternative (which I’m not fond of at all) would be to have > ckeditor > >>>> as a separate git repo in the xwiki github organization. > >>>> > >>>> Thanks > >>>> -Vincent > >>>> > >>>>> Thanks, > >>>>> Marius > >>>>> > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Alex > >> _______________________________________________ > >> 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
