As mentioned there are two issues here, nested vs flat structure and the reactor poms.
One can easily go without the other. I personally like the flat hierarchy. Simply using the artifact id to create a hierarchy or a reactor pom is only working in same cases. I fear we have some "wrong" artifact ids to be useful for this. Now, for the use case at hand, why can't we simply add profiles to the reactor pom. By default all projects are in the reactor, but if you specify a profile like "htl" only htl related modules are triggered. Nice, easy, extensible and requires zero changes Carsten Radu Cotescu wrote > Hi Robert, > > Well, how easy would it be to create folders from those group names and > then clone all modules belonging to a group into that folder? Any other > module could very well be cloned in the root folder (current working > directory). So I guess I'm more of a nested structure fan. :) > > Thanks, > Radu > > On Mon, 6 Nov 2017 at 10:53 Robert Munteanu <[email protected]> wrote: > >> Hi Radu, >> >> On Mon, 2017-11-06 at 08:22 +0000, Radu Cotescu wrote: >>> Hello, >>> >>> After using the Sling Aggregator [0] to clone all modules I was >>> wondering >>> if somebody else missed the previous "functional" structure of the >>> modules >>> or not. While I fully support the 1 module / SCM repository code >>> organisation, I think that sometimes it's beneficial to have a >>> reactor that >>> would build all related modules with one command. >> >> There are two issues in your email: >> >> - generating reactor poms >> - nested vs flat structure >> >> I think both are fine to have, if we agree on the structure. >> >> I have already added some basic support for grouping repositories, see >> >> https://github.com/apache/sling-aggregator/blob/81b3367168e97cb2702d960 >> ff883bc1ca7425693/default.xml#L193-L214 >> <https://github.com/apache/sling-aggregator/blob/81b3367168e97cb2702d960ff883bc1ca7425693/default.xml#L193-L214> >> >> The logic is 'look for the first segment in the repo name after org- >> apache-sling and create a group if two or more repos have it'. >> >> We can of course enhance it, but let's first lay down some grouping >> rules and decide where to place repositories outside of any groups. >> >> Thanks, >> >> Robert >> > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
