Hi Sergiu,

I think we already have you described or at least that's the intent. Let me explain.

* We already have a xwiki-applications/wikis directory in SVN which is meant to be the place where you put what you call Flavors (I call them wikis). Right now there's only one called "default" (actually there's a second one called xwikiorg on my machine but I've never checked it in because it's big and we don't distribute it as a generic wiki).

* This wiki-applications/ dir has a trunk/, branches/ and tags/ directories which means it's already meant to have its own release lifecycle separate from xwiki-core/ (called xwiki/ right now but needs to be renamed). The idea is that anything top level dir that has a trunk/, branches/ and tags/ is meant to have its own release lifecycle. It's just that we're not doing it now for lack of manpower and people working on the various components, and more importantly we're not using Maven2 yet for the release. When we do, it takes about 5 minutes to cleanly release any project (I know as I've made this exact transition for the Cargo project). This is the direction. But Maven2 is an absolute prerequisite.

* In term of JIRA it all derives from SVN simply in JIRA the rule is: one JIRA project per release lifecycle. Indeed each JIRA project defines its own versions (0.1, 0.2, 1.0, etc) and it's bad practice to mix different version names for different releases in one JIRA project. Thus once we start releasing any component separately from the core, we'll create a JIRA project for it.

To summarize:

1) I agree with XWiki "Flavors" (which I call wikis but we can standardize on a name, not very important - Not sure about Flavor though)

2) Our SVN structure is already meant to accomodate this

3) We need the M2 build to be finished (it's really almost there especially as our big issue with m2 has been fixed in m2 trunk). I think I need about 2-3 full days to finish it

4) JIRA projects derive from 2) and it's just a question of creating the project when the time comes.

Now there's one remaining thing to discuss: the documentation of XWiki "flavors" on xwiki.org. This is the thread started by Guillaume and to which nobody has answered yet. Right now we're mixing documentation of core and default wiki on xwiki.org. Once we get another flavor we'll need to fix this.

See "Reorganization the documentation content on XWiki.org":

http://www.nabble.com/Reorganization-the-documentation-content-on-XWiki.org-tf3541863.html#a9887423

Thanks

-Vincent

On Apr 13, 2007, at 1:16 AM, Sergiu Dumitriu wrote:

Hi,

I'd like to propose a new subproject on JIRA, called XWiki Flavors.

What is a Flavor? A flavor is a custom XWiki-based site, with one specific goal in mind. The XPN team creates such flavors when working for client project. As it is said on http://jira.xwiki.org/jira/browse/XWIKI-356 , by default XWiki comes with a collection of pages, panels, classes, a pre-selected skin, etc, which gives it a "flavor". Right now, it looks like a nice site where you can put some pages (content), articles, documentation, etc. It is a weak flavor, since it's a mixture of different ingredients put all together.

An example of a "strong" flavor is a blog-wiki. When you install XWiki and choose the blog-flavor, you will get the full functionality of any blog app (for example blogger or wordpress) without having to customize anything, without having to import one or several xar-s, editing the main page or anything. Of course, after the user gets used to the blog (and XWiki) he can customize the skin (using a friendly skin browser and a skin wizard), the displayed panels (using the panel wizard), and many other things (actually anything a user can change in XWiki, which is everything).

Other strong flavors could be content management, OpenSource project website (about, developer guide, user guide, download, ...), or just the documentation for such a project (many projects use wikis now), Social Networking site (link and photo sharing, tagging, reviews), project management, and so many more.

Why are flavors necessary? Because XWiki is too powerful. Put it in the hands of some who-knows-what "haskel model checker" developer who only knows about axioms, theorems, proving, model checking and functional programming, and he will run away very fast to a simple wiki engine, or worse, a CMS. But hide all the power behind a simple interface, with only what he needs in order to publish some info about his project, and we have a happy XWiki user.

Why do we need a new subproject? Because:
- putting all the flavor-specific issues in the "Default database" component is not efficient
- neither is putting them in a new "Flavors" component
- we don't know how many flavors we will create, so making an XWiki component for each flavor will bloat the component list
- flavors don't follow the XWiki platform release plan; they get shipped when they are ready

What is the relation between flavors, default database, and xwiki-applications?
The default database should be almost empty. It should contain mainly the setup wizard, which can be used to install a flavor.
A flavor contains some applications bundled together. It is not enough to put only the individual applications in JIRA, because a flavor is more than that: a custom skin, configuration for the applications, rights setup, other documents outside of applications, java plugins, XWiki configuration, and even more.

What should the subproject contain? First, a "global" component, regarding flavor development, deployment, integration, installation. Then a component for each flavor we are currently supporting (or starting to work on).

WDYT?