Hi Marius,
On 07 Jun 2016, at 11:17, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <vincent(a)massol.net> wrote:
On 07 Jun 2016, at 09:37, Guillaume Delhumeau
<
guillaume.delhumeau(a)xwiki.com> 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 <vincent(a)massol.net>et>:
>>
>>>
>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea <
>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>
>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol
<vincent(a)massol.net>
>>> wrote:
>>>>
>>>>>
>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea <
>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>
>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga <
>>>>>> alexandru.cotiuga(a)xwiki.com> 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.numbe…
>>>
>>> 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