On Sat, Nov 10, 2018 at 11:52 AM Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I’d like to start/revisit a brainstorming on the idea of merging the 3 xwiki repos:
commons, rendering & platform.
Pros:
* Nicer to have XWiki Standard be contained in a single repo
* More logical since we release the 3 at the same time with the same versions
* Simpler to commit. Right now if you make changes that affect more than 1 repo we get
failures in the CI + we need several jira issues ideally + developers need to rebuild
locally the changes from the other repo or wait for the CI to finish building the changes
(takes long).
* Simpler for users to report issues. One jira project is simpler to know where to
report.
* Less CI jobs
* Simpler for running tools like jacoco, clover, etc since they can run in a singe maven
reactor.
* Simpler for releases (e.g. to find the list of committers for the RN, you need to run
the command only once instead of 3 times, etc)
* Simpler to understand the xwiki code base and for onboarding
Cons:
* We need to find a solution for Maven plugins that need to be build before they’re used
(XAR plugin, Package plugin, etc). One solution for those is to have them in a separate
repo and using the last released version for their XWiki dependencies. Unless it now works
with Maven to build plugins in the same reactor as where they’re used (need to try it).
It's not really related to plugins but to lifecycle handlers (xar,
webjar and xip artifact types right now). There is no problem with the
package plugin, it would not be located in platform if there was. Also
what you propose would not really work IMO: you introduce a new
extension when you need it but here you would have to introduce it and
wait for next release.
* Maybe could cause memory issues when running the
whole build in a single maven reactor?
We don't build the whole platform in a single maven reactor already
because of memory issues (mostly Jenkins issues).
* Note that I don’t think this would impact the
release of commons and rendering modules to Maven Central since we can still configure
that in the poms for those modules.
I don't think it's as simple as you think actually, the Nexus Maven
plugin which is taking care of doing the automatic release on Maven
central really does not expect to have different deploy repositories
in the same reactor.
* We might need to refactor some of our build checking
tools such as the one verifying that commons doesn’t use rendering or platform modules but
that’s not a big deal.
* Possibly slightly longer paths for building on windows (see below)
If we were to agree on the merge, we could keep the separation between the 3 repos with
directories and have an addition level such as:
xwiki (repo)
|_ xwiki-commons
|_ xwiki-rendering
|_ xwiki-platform
Now we could also forge this organization and flatten it with:
xwiki (repo)
|_ xwiki-(feature)
|_ xwiki-(feature)-(subname1)
For example:
xwiki
|_ xwiki-core
|_ xwiki-component
|_ xwiki-component-api (from commons)
|_ xwiki-component-multi (from platform)
|_ xwiki-rendering
|_ …
|_ xwiki-tools
We could even try to go with an even flatter structure:
xwiki
|_ xwiki-component
|_ xwiki-component-api (from commons)
|_ xwiki-component-multi (from platform)
|_ xwiki-rendering
|_ …
|_ xwiki-tools
|_ ...
(it would mean that in xwiki-tools, we apply similar rules that for runtime code or
override the maven configs)
WDYT?
Thanks
-Vincent
So again big +1 for moving rendering into commons since it's easy but
I see more cons than pros for platform right now.
--
Thomas Mortagne