Hi Marius, > On 07 Jun 2016, at 11:17, Marius Dumitru Florea > <[email protected]> wrote: > > 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.
Yes indeed; it’s very precise for the existing XE (which is well-defined) but doesn’t say anything about future. A better definition is what we defined in the "xwiki core” thread (source: http://markmail.org/message/w6veilqhhnjqcw3e): " Executive summary: * Reduce the scope of all the code located in the xwiki github organization by only keeping “core” modules * A “core" module is defined by being a generic transversal module (i.e. that can be used in lots of XWiki flavors, if not all). This is opposed to “vertical” modules which are modules specific of a usage of XWiki. ** Examples of “core" modules: logging module, configuration module, distribution wizard, annotations, active installs, one base flavor (the “XWiki” flavor), etc ** Example of “vertical” modules: meeting manager application, blog application, FAQ application, flavors (except the base flavor), etc " According to this definition the Tour and CKEditor are both core modules. Related threads: - Move rendering extensions out: http://markmail.org/message/y3bkch37mt5iwvxu - Terminology: http://markmail.org/message/hl4xwdxwpi7gnia2 - Move platform extensions out: http://markmail.org/message/viesrhmdavyvdaec - XWiki Core - Take 3: http://markmail.org/message/w6veilqhhnjqcw3e > 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. That’s the idea and what you voted on, see for example: - Move rendering extensions out: http://markmail.org/message/y3bkch37mt5iwvxu - Move platform extensions out: http://markmail.org/message/viesrhmdavyvdaec Thanks -Vincent > 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
