On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol <vincent(a)massol.net> wrote: 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. So the FAQ application you moved out of platform is no longer supported by the XWiki Core Dev Team? The extension page http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application doesn't reflect this.

Moving Tour Application into platform makes sense to me (it becomes a critical component and deserves a proper support). However, the current application supports XWiki >= 6.4.1. By moving it to platform, we will only support the last XWiki version. 2016-06-06 15:31 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>: -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <vincent(a)massol.net> wrote: "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.

So the main concerns are: A. moving (changing history, ids, versioning scheme, version compatibility, etc.) B. commit rights & ownership C. support definition A. Maybe in the future we might want to create flavors that contain community applications, without the need to move them somewhere (like Mocca Calendar for example). I don't like moving things around, losing history, breaking ids, versioning, etc. It is an interesting topic because in the past years, when we experimented something, we first committed code outside of platform. So the move topic will happen for other apps too. B. Regarding commit rights, they can be set per repository. So we could indeed handpick apps and allow only committers to support them. Now this indeed implies changing some of our definitions and providing such a list of applications. Regarding ownership, I think preserving the initial owner of the app, gives the appropriate credits to him. From a community perspective I think is better for an app to be attribute to the initial committer, rather than switching the ownership to XWiki's Development Team. C. Now the problem is the 'support', since as you said it's hard for as committers to offer support for apps that are not in platform. Changing the commit rights from contrib to committers could be a solution, if the owner agrees. Now IMO we can easily change the definition of what 'support' means, we only need motivation and to see additional benefits. So I would: - ask the owner if he wants his app to be bundled by default - not move the app, just use as a dependency - ask if we can change the initial rights to allow committers + owner(s), instead of contrib. A note that for some apps, multiple people could be better suited to 'support' the app, rather than the committers group - ask the owner if he can 'support' the app. Bundling an app implies that the committers will support it, but additional owners can and should support it. If the owners would like to support the app, but they are not committers, I would not want us to be 'forced' to give commit rights just because we will need to move the app inside platform. Or for the owner to 'renounce' his app. - as part of the support agreement, request the app to have functional tests and have a job on ci. So the other problems remaining are different version schemes, compatibility and the list of bundled contrib apps: - Compatibility will be better since you could install new versions of the app, on older versions of XE. Now the testing will be more problematic (in mixing different version). - Compatibility field on e.x.o needs to be updated on every XE release. This could mean increased work for the RM or the owner(s). - The list of bundled apps can be generated using the 'bundled' property we have on Repository app. Anyway :) this implies some changes. I would like us not to move the app, but not sure how this will fully impact our current rules. Thanks, Caty On Tue, Jun 7, 2016 at 11:27 AM, Vincent Massol <vincent(a)massol.net> wrote:

So another option is to reduce even more the scope of the xwiki github org by saying that it’s “all the modules that are required to run a minimal runtime”. And as we progress in our decoupling of things, we move more and more things out (the minimal runtime definition contains less and less stuff till we end up with only a CLI for the Extension Manager allowing to install everything else through extensions). With this definition CKEditor and Tour modules would not be in the xwiki github org and would stay in contrib. This the same idea as the flavor in contrib that I mentioned above and in previous mails in this thread. It means that the xwiki github org would provide a base flavor (would be called minimal flavor now) and that the real flavor for users would be defined in contrib. IMO if we go in this direction we might want to rename the xwiki contrib github org since it’s not longer contrib; it’s becoming all the non-core modules/extensions. That would be a pretty drastic change and I’m not sure I’m willing to go in this direction. We might also resurrect the dependency hell we had before. But I thought I should mention it. I’m still preferring to continue with the definition we currently have though. More options? Thanks -Vincent

It also means to move the tour application in that old branches too. 2016-06-07 13:59 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>: -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

Well, very sorry to drop in so late in this discussion, but it was not obvious from the thread subject that your were discussing a major subject. IMO, moving application that works currently on 6.x to the core, has no benefit for our users, it just introduce restrictions. It does not have any benefit for us either, it just require more backports. I do not understand this move at all for application that are not minimal requirements. I do not understand your point Vincent when you say that these applications are horizontal and obviously part of platform according to your "Executive summary". Regarding the tour application, it is not require at all, it is just a nice helping tool that we want to ease newcomers, but experienced user will never need it. It could be exchanged for an alternative, and it is exactly the same kind of application than the blog that we are moving out. Regarding the CKEditor, do we consider that a WYSIWYG editor is required for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to use the platform, it is nice to have, but not required. I have use it very sparsely until now, and not having it would not have change much for me. So, I currently do not see any benefit of moving these modules to platform, since these are already well living in contrib. Your other point about reducing platform to the minimal runtime would cause platform to reduce to EM does not really looks like something that will happen. In theory, you are right, so XWiki would be even less featured then maven. But, I doubt you could reasonably use such a tools for anything useful. I doubt XWiki compare to maven. I doubt that horizontal module like security, logging, model, storage, etc… will ever be considered optional. Even a plain text editor is a minimal requirement to starts, else this is no more a wiki, and I even wonder what it is ? a tool that brings together arbitrary java module… looks weird. So no, the minimal runtime is definitely not just EM. So, I really wonder what is the direction we are taking. I will not stop you with a veto, but I have the strong feeling these decisions are wrong. For the principle of not depending on contrib for our default user flavor, exchanging the blog app with the tour app, this does not make sens for me, sorry. Thanks for reading. On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <vincent(a)massol.net> wrote: -- Denis Gervalle SOFTEC sa - CEO

Hi everyone, Thanks for the replies. I’m listening of course to everyone and I’ve tried in this mail to take all answers into account. First, let me state our current strategy and an alternative that I’ve been thinking about this morning under my shower ;) Current Voted Strategy ================== * Deliver an XWiki Runtime that is the best possible generic runtime (i.e. most usable, most useful). * As a consequence, remove all modules that vertical modules (i.e. that are clearly not useful to all flavors), such as FAQ, Blog, etc. Move them to xwiki-contrib * I want to stress out that the current voted strategy is not to produce a minimalist runtime New Strategy Proposal ================== I’ve tried to reconcile all the use cases listed in this thread before and I hope this proposal could be a good middle ground. In any case I found it worth debating to see if it could work. Also note that one aspect that we must not forget (and that led to the last proposal I sent on this thread) and that people tend to forget, is the time it takes to support various versions of XE in an extension and the manpower that exists in the xwiki community (don’t forget that everything we do is a tradeoff; if you support another version of XE in an extension, it means you’re not coding an important improvement or fixing an important bug in the platform). So here’s the idea: * Change the purpose of the XWiki Github organization from the voted one described above to be: Provide a minimalist runtime. * Since working in this direction will not happen overnight, the idea would be to very slowly take out modules, starting with obvious ones. * The issue that this strategy raises is that users will not get a good user experience since lots of things will be lacking and this is where my new idea fills the gap: ** The first time (or whenever you upgrade) your run the XWiki Runtime (be it whether your run the HSQLDB/Jetty packaging or any other packaging) you get a Configuration wizard ** This Configuration Wizard suggest some recommended extensions that the XWiki Core Dev Team hand-pick. We would start with 2: *** Propose to the user to run a Tour to learn how to use XWiki (it would install the Home Page Tour which depends on the Tour app) *** Propose to the user to install the CKEDitor WYSIWYG editor (by default we would only propose the wiki editor - We’ll need to get rid of the GWT editor, probably make it an extension) Pros: * The XWiki Core Dev Team continues to work on core stuff and as time progresses we move out non core stuff * This allows more people to contribute to the non-core stuff in the community * We control which extensions we want to recommend and thus we can always only take the very good ones and thus control the quality of the initial user experience * We get a mechanism allowing our users to get non-xwiki core dev team-supported extensions into the runtime (thus providing a good user experience) while not bundling them into the default XWiki runtime flavor. Cons: * The Tour and CKeditor extensions would still incur a higher cost of support/maintenance (but since they’ve already done the code, it’s marginal for the future and they’ll be able to abandon support for XWiki 6.x soon IMO too - Basically they probably only need to support 2 or 2.5 cycle versions). <similar idea> Ludo mentioned (and I agree with him) that it would be nice to be able to provide Demo content in the wiki so that users who want to test drive XWiki can do so with existing content and more clearly see and understand the advantages that XWiki brings. For this, I’d propose to create a Demo Content extension (some AWM app + some blog posts + etc) and once we have it, recommend it on the Configuration Wizard. </similar idea> WDYT? Thanks -Vincent

IMO Flavors don’t change; they’re still there and you still get them when you start with an empty wiki. When you start an empty wiki you pick the flavor you want and on the configuration screen, there are some recommended extensions that are proposed. I think that’s the difference: flavors are a fixed set of extensions. The Recommended extensions screen is just for optional stuff that you may want. If the recommended extensins are brought as part of the flavor (ie if they are already installed) then they won’t be suggested on the configuration screen. Basically flavors are distribution. Once you install a distribution you can still install additional extensions by going to the Extension Manager. However we make the user’s file easier when he starts the first time by proposing some extensions. This provides 2 advantages: * We bring extensions that we deem important but that are not maintainted by the xwiki core dev team to the user. He doesn’t need to discover the EM UI nor find out which extensions are super nice for me. * It allows to propose some extensions that need to run early in the process, such as the Tour (the user needs the Tour to know how to reach the EM UI ;)). Another way of viewing this is that it’s a new feature of the EM/DW UI. The EM/DW module would provide a Recommended Extensions view as a Wizard when XWiki runtime starts the first time (and at each upgrade). Now what we would need to be careful about is not drowning the user under 50 recommended extensions or it would loose its power. I think this config wizard view should focus on Extensions that are super useful for getting started. Then later one the user could go to the EM UI and get a full list of Recommended Extensions, not just the one important for getting started. WDYT? Thanks -Vincent

Hi, As far as I can see, you want to make sure that the user installs the Tour, for example, so that it is executed at the right time. However, why not let the flavor take care of this? Since the user will be choosing a flavor to install, it would also contain the tour (if it needs it) and everything will be set up. For additional extensions that the admin wants to install, we have the EM UI and we can have recommended extensions displayed there. An extra step just for the recommended extensions is too much IMO and just gets in the way. We still control what the standard flavor contains (tour, CK, etc.) and we still control what (contrib) extensions to recommend in the EM UI. IMO, that is enough. Thanks, Eduard On Thu, Jun 9, 2016 at 2:12 PM, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com > I think that if we are to have Recommended extensions inside e.x.o and EM, > I would consider it a bit too much to have them also in DW. But maybe this > is another discussion. > > Thanks, > Caty > > On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol &lt;vincent(a)massol.net> > > > > > On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com > > > > > > > > > Hi, > > > > > > Where are the Flavors in this proposal? > > > > IMO Flavors don’t change; they’re still there and you still get them when > > you start with an empty wiki. When you start an empty wiki you pick the > > flavor you want and on the configuration screen, there are some > recommended > > extensions that are proposed. I think that’s the difference: flavors are > a > > fixed set of extensions. The Recommended extensions screen is just for > > optional stuff that you may want. If the recommended extensins are > brought > > as part of the flavor (ie if they are already installed) then they won’t > be > > suggested on the configuration screen. > > > > Basically flavors are distribution. Once you install a distribution you > > can still install additional extensions by going to the Extension > Manager. > > However we make the user’s file easier when he starts the first time by > > proposing some extensions. > > > > This provides 2 advantages: > > * We bring extensions that we deem important but that are not maintainted > > by the xwiki core dev team to the user. He doesn’t need to discover the > EM > > UI nor find out which extensions are super nice for me. > > * It allows to propose some extensions that need to run early in the > > process, such as the Tour (the user needs the Tour to know how to reach > the > > EM UI ;)). > > > > Another way of viewing this is that it’s a new feature of the EM/DW UI. > > The EM/DW module would provide a Recommended Extensions view as a Wizard > > when XWiki runtime starts the first time (and at each upgrade). Now what > we > > would need to be careful about is not drowning the user under 50 > > recommended extensions or it would loose its power. I think this config > > wizard view should focus on Extensions that are super useful for getting > > started. Then later one the user could go to the EM UI and get a full > list > > of Recommended Extensions, not just the one important for getting > started. > > > > WDYT? > > > > Thanks > > -Vincent > > > > > Thanks, > > > Caty > > > > > > On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > > > > > > >> Hi everyone, > > >> > > >> Thanks for the replies. I’m listening of course to everyone and I’ve > > tried > > >> in this mail to take all answers into account. > > >> > > >> First, let me state our current strategy and an alternative that I’ve > > been > > >> thinking about this morning under my shower ;) > > >> > > >> Current Voted Strategy > > >> ================== > > >> > > >> * Deliver an XWiki Runtime that is the best possible generic runtime > > (i.e. > > >> most usable, most useful). > > >> * As a consequence, remove all modules that vertical modules (i.e. > that > > >> are clearly not useful to all flavors), such as FAQ, Blog, etc. Move > > them > > >> to xwiki-contrib > > >> * I want to stress out that the current voted strategy is not to > > produce a > > >> minimalist runtime > > >> > > >> New Strategy Proposal > > >> ================== > > >> > > >> I’ve tried to reconcile all the use cases listed in this thread before > > and > > >> I hope this proposal could be a good middle ground. In any case I > found > > it > > >> worth debating to see if it could work. > > >> > > >> Also note that one aspect that we must not forget (and that led to the > > >> last proposal I sent on this thread) and that people tend to forget, > is > > >> the time it takes to support various versions of XE in an extension > and > > the > > >> manpower that exists in the xwiki community (don’t forget that > > everything > > >> we do is a tradeoff; if you support another version of XE in an > > extension, > > >> it means you’re not coding an important improvement or fixing an > > important > > >> bug in the platform). > > >> > > >> So here’s the idea: > > >> > > >> * Change the purpose of the XWiki Github organization from the voted > one > > >> described above to be: Provide a minimalist runtime. > > >> * Since working in this direction will not happen overnight, the idea > > >> would be to very slowly take out modules, starting with obvious ones. > > >> * The issue that this strategy raises is that users will not get a > good > > >> user experience since lots of things will be lacking and this is where > > my > > >> new idea fills the gap: > > >> ** The first time (or whenever you upgrade) your run the XWiki Runtime > > (be > > >> it whether your run the HSQLDB/Jetty packaging or any other packaging) > > you > > >> get a Configuration wizard > > >> ** This Configuration Wizard suggest some recommended extensions that > > the > > >> XWiki Core Dev Team hand-pick. We would start with 2: > > >> *** Propose to the user to run a Tour to learn how to use XWiki (it > > would > > >> install the Home Page Tour which depends on the Tour app) > > >> *** Propose to the user to install the CKEDitor WYSIWYG editor (by > > default > > >> we would only propose the wiki editor - We’ll need to get rid of the > GWT > > >> editor, probably make it an extension) > > >> > > >> Pros: > > >> * The XWiki Core Dev Team continues to work on core stuff and as time > > >> progresses we move out non core stuff > > >> * This allows more people to contribute to the non-core stuff in the > > >> community > > >> * We control which extensions we want to recommend and thus we can > > always > > >> only take the very good ones and thus control the quality of the > initial > > >> user experience > > >> * We get a mechanism allowing our users to get non-xwiki core dev > > >> team-supported extensions into the runtime (thus providing a good user > > >> experience) while not bundling them into the default XWiki runtime > > flavor. > > >> > > >> Cons: > > >> * The Tour and CKeditor extensions would still incur a higher cost of > > >> support/maintenance (but since they’ve already done the code, it’s > > marginal > > >> for the future and they’ll be able to abandon support for XWiki 6.x > soon > > >> IMO too - Basically they probably only need to support 2 or 2.5 cycle > > >> versions). > > >> > > >> <similar idea> > > >> Ludo mentioned (and I agree with him) that it would be nice to be able > > to > > >> provide Demo content in the wiki so that users who want to test drive > > XWiki > > >> can do so with existing content and more clearly see and understand > the > > >> advantages that XWiki brings. For this, I’d propose to create a Demo > > >> Content extension (some AWM app + some blog posts + etc) and once we > > have > > >> it, recommend it on the Configuration Wizard. > > >> </similar idea> > > >> > > >> WDYT? > > >> > > >> Thanks > > >> -Vincent > > >> > > >> > > >>> On 08 Jun 2016, at 17:57, Denis Gervalle &lt;dgl(a)softec.lu> > >>> > > >>> Well, very sorry to drop in so late in this discussion, but it was > not > > >>> obvious from the thread subject that your were discussing a major > > >> subject. > > >>> > > >>> IMO, moving application that works currently on 6.x to the core, has > no > > >>> benefit for our users, it just introduce restrictions. It does not > have > > >> any > > >>> benefit for us either, it just require more backports. I do not > > >> understand > > >>> this move at all for application that are not minimal requirements. I > > do > > >>> not understand your point Vincent when you say that these > applications > > >> are > > >>> horizontal and obviously part of platform according to your > "Executive > > >>> summary". > > >>> > > >>> Regarding the tour application, it is not require at all, it is just > a > > >> nice > > >>> helping tool that we want to ease newcomers, but experienced user > will > > >>> never need it. It could be exchanged for an alternative, and it is > > >> exactly > > >>> the same kind of application than the blog that we are moving out. > > >>> Regarding the CKEditor, do we consider that a WYSIWYG editor is > > required > > >>> for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to > > use > > >>> the platform, it is nice to have, but not required. I have use it > very > > >>> sparsely until now, and not having it would not have change much for > > me. > > >>> > > >>> So, I currently do not see any benefit of moving these modules to > > >> platform, > > >>> since these are already well living in contrib. > > >>> > > >>> Your other point about reducing platform to the minimal runtime would > > >> cause > > >>> platform to reduce to EM does not really looks like something that > will > > >>> happen. In theory, you are right, so XWiki would be even less > featured > > >> then > > >>> maven. But, I doubt you could reasonably use such a tools for > anything > > >>> useful. I doubt XWiki compare to maven. I doubt that horizontal > module > > >> like > > >>> security, logging, model, storage, etc… will ever be considered > > optional. > > >>> Even a plain text editor is a minimal requirement to starts, else > this > > is > > >>> no more a wiki, and I even wonder what it is ? a tool that brings > > >> together > > >>> arbitrary java module… looks weird. So no, the minimal runtime is > > >>> definitely not just EM. > > >>> > > >>> So, I really wonder what is the direction we are taking. I will not > > stop > > >>> you with a veto, but I have the strong feeling these decisions are > > wrong. > > >>> For the principle of not depending on contrib for our default user > > >> flavor, > > >>> exchanging the blog app with the tour app, this does not make sens > for > > >> me, > > >>> sorry. > > >>> > > >>> Thanks for reading. > > >>> > > >>> > > >>> > > >>> On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > > >> > >>> > > >>>> FTR I’ve discussed internally with Thomas, Marius and Anca and we > all > > >>>> agreed that it makes sense to move The Tour app + CKEditor to the > > >> platform. > > >>>> > > >>>> There are various reasons but a very important one is simply the > > >> manpower > > >>>> that it requires to maintain extensions on lots of XWiki versions > and > > >>>> currently the active devs on xwiki are not enough to do that. This > is > > >> the > > >>>> reason we dropped this strategy in the past and decided to release > the > > >>>> whole platform together with the same version. > > >>>> > > >>>> As part of this the technical debt is being increased since > supporting > > >>>> several versions and old versions means doing hacks. > > >>>> > > >>>> If you see another possibility that doesn’t require more work please > > >> raise > > >>>> it here. > > >>>> > > >>>> We need to progress and have CKEditor and Tour bundled in > 8.2M2(which > > >> is > > >>>> already started) and thus, barring any negative comments, we’ll > start > > >> the > > >>>> move next week. > > >>>> > > >>>> Thanks > > >>>> -Vincent > > >>>> > > >>>>> On 07 Jun 2016, at 15:39, Guillaume Delhumeau < > > >>>> guillaume.delhumeau(a)xwiki.com> > >>>>> > > >>>>> It also means to move the tour application in that old branches > too. > > >>>>> > > >>>>> 2016-06-07 13:59 GMT+02:00 Vincent Massol &lt;vincent(a)massol.net&gt;et>: > > >>>>> > > >>>>>> > > >>>>>>> On 07 Jun 2016, at 10:27, Vincent Massol &lt;vincent(a)massol.net&gt; > > > >>>>>>> > > >>>>>>> > > >>>>>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < > > >>>>>> guillaume.delhumeau(a)xwiki.com> > >>>>>>>> > > >>>>>>>> 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). > > >>>>>>> > > >>>>>>> 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. > > >>>>>> > > >>>>>> Actually in practice we would support not only the last XWiki > > version > > >>>> but > > >>>>>> also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we > > >> could > > >>>> (we > > >>>>>> still have a stable-6.4.x branch ATM that we were supposed to > > remove) > > >>>> but > > >>>>>> it would mean changing our support strategy to support more > > branches… > > >>>> and > > >>>>>> it means supporting the whole platform for 6.4.x, not just one > > >>>> extension… > > >>>>>> > > >>>>>> Thanks > > >>>>>> -Vincent > > >>>>>> > > >>>>>> > > >>>>>>> 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 &lt;vincent(a)massol.net&gt;et>: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < > > >>>>>>>>> mariusdumitru.florea(a)xwiki.com> > >>>>>>>>>> > > >>>>>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < > > >> vincent(a)massol.net&gt; > > >>>>>>>>> > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < > > >>>>>>>>>>> mariusdumitru.florea(a)xwiki.com> > >>>>>>>>>>>> > > >>>>>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < > > >>>>>>>>>>>> alexandru.cotiuga(a)xwiki.com> > >>>>>>>>>>>> > > >>>>>>>>>>>>> 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 > > >> _______________________________________________ > > >> devs mailing list > > >> devs(a)xwiki.org > > >> http://lists.xwiki.org/mailman/listinfo/devs > > >> > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

On Thu, Jun 9, 2016 at 2:17 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: This is true only for core jar extensions. CKEditor is a XAR. -- Thomas Mortagne

Some notes: - I prefer to have extensions in contrib instead of moving them back and forth in the platform; - I don't think CKEditor and the Tour are 'optional' extensions. IMO in the near future we will have Flavors like KB, Groupware. Each of this Flavors needs a Tour, with very different steps. We cannot add the Tour in the Recommended area, since we should have the Tour + custom steps for each Flavor preinstalled. Same for CKEditor if we want it to be the new default editor. So I don't see how CKEditor and Tour would be good candidates for this 'Recommended' step inside DW. - I don't like adding additional steps into DW, when we should improve the EM interface, to allow filtering these Recommended extensions. Thanks, Caty On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote:

Before you ask, no the DW is not disabled in jetty/hsqldb, it just does not find anything to do. In this case it would since the only way to not have this step is to validate it (or that the flavor disable it). On Tue, Jun 14, 2016 at 10:52 AM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: -- Thomas Mortagne

Ok so I’ve brainstormed with Denis and we worked on option A) below. Here’s what we could do: * Make XWiki Github org == minimal runtime, where minimal means “basic wiki” (page edition, history, linking, wiki markup, etc). The notion of “basic wiki” would need to be better defined but this can be done later on. * Provide a "Base Flavor" which corresponds to this “basic wiki”, as part of xwiki-platform (this would be xwiki-platform-distribution). * Provide another flavor, the "Default Flavor” which would add some hand-picked third-party extensions (i.e. from contrib) such as the Tour app and CKEditor (to start with, we could also add the markdown syntax for example which is one of the most asked syntaxes). Note that this Default Flavor would actually be a “replacement" of xwiki-enterprise. * The Default Flavor would have at least the same release cycle as the base flavor but it could have more releases (if some of the bundled third-party extensions has some important bug fixes or new features that we want to offer quickly without waiting for the next base flavor release). * The consequence is that the XWiki Dev Team would need to be a bit more careful to monitor the quality of bundled third-party extensions in contrib (check commits, do some smoke testing, etc). Note that the goal of the Default flavor would not be to offer verticals (for this there should be some contrib flavors) and thus it wouldn’t bundle a lot of third-party extensions. Basically we’ll need to validate the version of those third-party extensions that include in the flavor. My POV is that globally this would offer more flexibility for our users (they’ll be able to install extensions such as CK and Tour in older XWiki versions and they’ll get more frequent releases) at the cost of some overhead to develop extensions that work in several versions. The dev team is pretty small and thus it means developing a bit less fast but it’s probably as important, if not more important, to make the code we develop available in older xwiki versions, as XWiki gains traction. WDYT? Thanks -Vincent

I prefer this proposal too. 2016-06-20 15:10 GMT+02:00 Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt;om>: -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

Yes it’s core by the definition we’ve used so far. The simplest definition of core is: “all extensions/modules that are bundled by default in XE”. Core doesn’t mean the minimal thing to make xwiki run (that would be just the EM). ATM core means what’s required to run XE. If we wanted to go to the minimal core, we would need to move the majority of things to contrib, including XE and have the xwiki github organization be just a repository of modules. In practices, it would means commons and rendering and almost all platform would move to contrib. I don’t think we’re ready for this and I don’t think it’s the right time for the project. I’d prefer that we go for moving out all non-bundled extensions first as was proposed. Thanks -Vincent