Re: [xwiki-devs] [PROPOSAL] Yet another new platform flavor proposal or how to get rid of XWiki Enterprise

> On 14 Apr 2017, at 22:34, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote: > > On 04/14/2017 09:51 AM, Thomas Mortagne wrote: >> Here is a new proposal on this subject. >> >> This supersets the following threads: >> * http://markmail.org/message/mhhurc7lbyfanph7 >> * http://markmail.org/message/nav5a77hzmhq4gq6 >> * http://markmail.org/message/fd5ijxdquzdhtykw >> >> We discussed with other committers (Vincent and Ludovic) and came to >> the conclusion that it was not core dev team job to provide a specific >> flavor like Knowledge Base and that we should focus only on a very >> generic one (pretty much XE without the Blog). >> >> Here are the details: >> >> = One flavor >> >> We develop only 1 flavor located in xwiki-platform repository. It's a >> generic flavor not targeting any specific use case (the first version >> with be XE without the Blog). We will discuss the name in another >> thread later, let's call it "Wiki Flavor" for now. >> >> Of course everyone is free and welcomed to build lots of contrib >> flavors which will be proposed when you install XWiki ("Development >> Flavor", "Demo Flavor", "Blog Flavor", etc.). >> >> = No "Base flavor" >> >> But platform will provide an extension that can be used as dependency >> by various flavors to get "core" UI extensions that we think make >> sense in any kind of flavor. >> >> = Demo package >> >> We currently have a jetty/hsqldb based package in platform which let >> you choose which flavor you want. We will show it in the download >> page. >> >> We will add another one with the Wiki Flavor already installed in it >> (pretty much like the XE jetty/hsqldb package). Listed on the download >> page too. > > Why? Is it that bad to always let the user choose the flavor? We can > split flavors into three levels: > > - The "Raw XWiki" flavor is on top, pre-selected > - Recommended flavors are next, in a list > - All flavors behind a "browse more" button > > The only case when leaving the standalone package empty might fail is in > a no-internet environment, but for this we can have a workaround: make > the jars, xars and poms needed for installing the base flavor available > in the package. Yes the reason is for the offline test use case. Bundling all flavors could be a solution indeed but it seems a bit overkill to me, especially if the user only wants a single one, don’t you think?