atom feed25 messages in org.xwiki.devsRe: [xwiki-devs] [Proposal] XWiki Core
FromSent OnAttachments
vinc...@massol.netDec 3, 2014 6:57 am 
Thomas MortagneDec 3, 2014 7:16 am 
Eduard MoraruDec 3, 2014 1:35 pm 
vinc...@massol.netDec 4, 2014 12:44 am 
Guillaume "Louis-Marie" DelhumeauDec 4, 2014 1:28 am 
vinc...@massol.netDec 4, 2014 1:37 am 
Ecaterina Moraru (Valica)Dec 4, 2014 4:35 am 
Marius Dumitru FloreaDec 5, 2014 7:19 am 
Denis GervalleDec 6, 2014 12:56 pm 
Thomas MortagneDec 7, 2014 1:52 am 
vinc...@massol.netAug 2, 2015 10:43 am 
Gabriela SmeriaAug 7, 2015 2:46 am 
Eduard MoraruAug 7, 2015 7:52 am 
Thomas MortagneAug 7, 2015 8:06 am 
Denis GervalleAug 8, 2015 2:58 pm 
Marius Dumitru FloreaAug 19, 2015 2:07 am 
vinc...@massol.netJan 18, 2016 8:05 am 
Thomas MortagneJan 18, 2016 8:22 am 
Denis GervalleJan 18, 2016 11:37 am 
Eduard MoraruJan 18, 2016 1:27 pm 
Marius Dumitru FloreaJan 18, 2016 10:06 pm 
Guillaume "Louis-Marie" DelhumeauJan 19, 2016 1:24 am 
Ecaterina Moraru (Valica)Jan 19, 2016 3:00 am 
vinc...@massol.netJan 19, 2016 8:17 am 
vinc...@massol.netJan 21, 2016 3:28 am 
Subject:Re: [xwiki-devs] [Proposal] XWiki Core
From:Eduard Moraru (
Date:Dec 3, 2014 1:35:37 pm


On Wed, Dec 3, 2014 at 5:16 PM, Thomas Mortagne <> wrote:

Sounds good. +1

On Wed, Dec 3, 2014 at 3:57 PM, <> wrote:

Hi committers (and devs in general),

I’m submitting to you this idea, to try to improve the xwiki open source

project and to give it a new dynamism. I believe the topics discussed below are made even more important since we’re soon going to develop the notion of flavors in XWiki.

Note that this proposal obsoletes the proposal (i.e. the move of some extensions in the xwiki github organization), which itself was obsoleting

Issues to solve ===============

* The scope of the code maintained by the XWiki Dev Team (== the xwiki github organization) is increasing but the team stays relatively small * The more stuff we move into the repos of the xwiki github

organization, the less easy it is for non-“XWiki Dev Team” committers to participate and we want more contributions

Proposed solution =================

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, statistics application, 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

Some consequences: * We need a new location for several modules that would go out of the xwiki github organization repos * It would be good to separate sandbox extensions from 1st class

extensions that are maintained and developed following best practices. We need some way to maintain the quality of important extensions

Detailed Implementation: * The “xwiki” github organization’s description becomes “XWiki Core” (it’s too complex to rename the org to “xwiki-core” IMO) * “XWiki Dev Team” becomes the “XWiki Core Team” (and committers in there are called “XWiki Core Committers”). * “xwiki-contrib” is split into 2 github organizations (technically we rename it to “xwiki-contrib-sandbox”): ** “xwiki-contrib-sandbox” (or “xwiki-incubator”), where newly proposed extensions or abandoned extensions are located ** “xwiki-contrib-extensions”, where maintained extensions are located. * These 2 organizations are commonly referred to as “XWiki Contrib" * Same as now, anyone requesting a repo in xwiki-contrib-sandbox would

be granted one and he/she’d be given write access to all repos in the xwiki-contrib-sandbox organization.

* We define some rules for graduating from xwiki-contrib-sandbox to xwiki-contrib-extensions. For example: ** The extension should have been in xwiki-contrib-sandbox at least 6

months (this gives time to see if the extension is maintained during that time and will survive the test of time - most extensions will die in the first months)

** The extension should have had more than 2 releases and be published on with documentation ** The extension should work with the latest LTS version of XWiki + the

latest stable version of XWiki (right now that would be 5.4.5 + 6.3). Note that if the extension has to use new API it’s ok that it doesn’t work on the latest LTS.

So no plan at this point to address and , right?

** Generally follow the practices defined at * Each extension in xwiki-extensions


has a leader/maintainer. He/she’s the one proposing to move the extension from xwiki-sandbox


to xwiki-extensions. He/she’s responsible for ensuring that the extension gets regular releases and is maintained in general. He/she defines initially the list of committers in his email proposal for moving the extension.

* We create a PMC (Project Management Committee) for XWiki Contrib,

generally in charge of both xwiki-contrib-sandbox and xwiki-contrib-extensions (voting new extensions in xwiki-contrib-extensions, vote new PMC members, etc). To bootstrap it, I would send a mail on devs@ asking who’s interested to be part of this committee. I expect some core committers + some contrib committers to stand up.

I propose that all XWiki core committers are, by default, members of this PMC. They can choose not to get involved in every decision, but they should have a voice if they need it, without needing to pass through a vote process from the current members of the PMC.

* Contrib extensions keep using the org.xwiki.contrib package name and

groupid as currently defined at

"A generic *maven groupId*: org.xwiki.contrib (or org.xwiki.contrib.<module name> if the project has several modules). That's until the project reaches a certain size and visibility, in which case it can have its own maven group id."

Projects part of xwiki-contrib-extensions seem to qualify the for the "until the project reaches a certain size and visibility" part.

Do we really want to enforce the org.xwiki.contrib group? Personally, I never did understand *why* we are enforcing it, above the simple fact that we just can.

I don't have something in particular against new projects in xwiki-contrib-sandbox, but for projects we are migrating from the xwiki organization, if they are java projects, we are forcing anybody that was using them in the past to rewrite their code (so no longer a simple dependency change in their pom.xml), since package name would change (due to our maven group id policy) and any code using those packages needs an update.

Thanks, Eduard

Note: The idea is that xwiki core is developed as a team maintaining all

code in there, xwiki contrib is developed extension by extension (each extension is an island). This allows anyone to propose extensions in XWiki Contrib without the need for everyone to support them.


Thanks -Vincent