Hello, +1 to have a mono repository. Maybe the simplest thing to do would be to create a new repository where the other three are merged, WDYT?
Thanks, Adel On Sat, Nov 10, 2018 at 11:58 AM Vincent Massol <[email protected]> wrote: > > Some additional notes below. > > > On 10 Nov 2018, at 11:52, Vincent Massol <[email protected]> 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). > > * Maybe could cause memory issues when running the whole build in a single > > maven reactor? > > * 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. > > TBH nobody uses XWiki commons and rendering in standalone modes, after over > 10+ years of it, so I’m not even sure it makes sense to publish to central > but we can continue to do that module per module, even with the flat > structure, and even publish more and more modules one by one if we believe > it’s a good thing. > > > * 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) > > Or shorter paths if we go with the flat structure… > > Thanks > -Vincent > > > > > 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 >
