12 Nov
2018
12 Nov
'18
2:02 p.m.
-0 in an era where everybody is talking about microservices and small
independent units, we want to merge in a mono-repository? What about out
contrib bundled extensions? After this, we will want to merge those too?
Yes, it's harder for the releases, but there are also advantages of being
separate.
Thanks,
Caty
On Mon, Nov 12, 2018 at 11:16 AM Vincent Massol <vincent(a)massol.net> wrote:
On 12 Nov 2018, at 10:13, Adel Atallah
<adel.atallah(a)xwiki.com> wrote:
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?
Yes that would be the idea and it would be named “xwiki”.
Thanks
-Vincent
Thanks,
Adel
On Sat, Nov 10, 2018 at 11:58 AM Vincent Massol <vincent(a)massol.net>
wrote:
>
> Some additional notes below.
>
>> On 10 Nov 2018, at 11:52, 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).
>> * 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
>