Before talking about merging the 3 repositories we should start by moving rendering into xwiki-commons. It's already very nice to remove to get rid of one repository and it does not add any complexity to keep pushing those to Maven central.
On Mon, Nov 12, 2018 at 9:28 AM Simon Urli <[email protected]> wrote: > > +1 with moving on a single repo. > However I'm not sure about the structures you proposed: it might be a > long term view, but on the short term it really looks safer to keep the > 3 modules separated, especially for the contrib extension which seems to > depends a lot from commons: > > https://github.com/search?p=1&q=%3CartifactId%3Exwiki-commons%3C%2FartifactId%3E&type=Code > > so I'd say +1 for the first structure and -0 for the other ones. > > On 10/11/2018 11:58, Vincent Massol 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 > > > > -- > Simon Urli > Software Engineer at XWiki SAS > [email protected] > More about us at http://www.xwiki.com -- Thomas Mortagne
