> On Feb 15, 2018, at 2:37 PM, Gilles <gil...@harfang.homelinux.org> wrote: > >> On Wed, 07 Feb 2018 15:22:59 +0100, Gilles wrote: >> On Wed, 7 Feb 2018 08:31:45 -0500, Rob Tompkins wrote: >>>> On Feb 6, 2018, at 6:28 PM, Gilles <gil...@harfang.homelinux.org> wrote: >>>> >>>> On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: >>>>>> On Feb 5, 2018, at 3:05 PM, Gilles <gil...@harfang.homelinux.org> wrote: >>>>>> >>>>>> On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: >>>>>>>> On Feb 5, 2018, at 2:22 PM, Gilles <gil...@harfang.homelinux.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Mon, 5 Feb 2018 14:17:18 -0500, Rob Tompkins wrote: >>>>>>>>> Which should be the template multi-module project? They all have >>>>>>>>> subtle differences that lead to different nuances to the build. >>>>>>>> >>>>>>>> Which differences did you spot? >>>>>>> >>>>>>> Nothing of any particular consequence, just where the main assemblies >>>>>>> end up. Or which Pom they’re in. >>>>>> >>>>>> What do you mean by "main assemblies"? If it's the "full" >>>>>> distribution, then is it a matter of naming the output directory? >>>>>> It could be configurable. >>>>>> >>>>>> For the config, the main POM looks the appropriate place if it can >>>>>> be done without side-effects. [For RNG I created a separate directory >>>>>> because I was not sure how to do it.] >>>>> >>>>> Right….that’s why I was asking which project would be the best >>>>> standard to work from, and then I could go through and take all of the >>>>> other multi-module builds and mildly refactor the pom/directory >>>>> structure to align with which ever we decided was standard. >>>>> >>>>> Is [jcs] the right choice as the standard? >>>> >>>> Why this one rather than another? >>>> It's not clear what you are looking for. >>> >>> It really doesn’t matter too much to me, I just wanted to get a >>> community consensus on what we think a standard directory structure >>> should be, or the exemplar >>> multimodule commons project. >> >> Quite possibly none of them is *the* example to follow. >> >>> It’s just easier to work from a specific project as opposed to trying >>> to generalize immediately. >> >> Perhaps (?) the other way around: by implementing some release >> procedure of a multi-module project, you can suggest a matching >> layout. >> >> See also my "wish" below. If it could work that way, the layout >> does not matter since the module info is taken from the top POM. >> >> Perhaps there could be a profile >> ---CUT--- >> <profile> >> <id>distribution-bundle</id> >> <modules> >> <module>commons-compX-mod1</module> >> <module>commons-compX-mod2</module> >> </modules> >> </profile> >> ---CUT--- >> And the plugin would go down the named directories and collect >> the artefacts. This would allow a project to contain modules >> not yet ready for release. >> >>> So my thought right now is either [rng] or [jcs]. >>> >>> I suppose another thought could be: is anyone planning a release on a >>> commons multi-module project anytime soon? >> >> Yes. >> >>> If so which? >> >> "Commons RNG", as soon as the pending issues[1] are resolved: >> * RNG-40 >> * RNG-31 >> * RNG-48 >> * RNG-44 >> >> The latter three are related to the multi-module handling by >> the "parent" project (i.e. the problem(s) which you intend to >> solve IIUC). > > Where do we stand wrt the functionalities needed to > release a modular project?
My first attempt (which I’ve gotten to work with other maven plugins) didn’t immediately work. More debugging there will likely tease out the issue. The goal is to have the mojos only operate on the top level pom.xml. -Rob > > Regards, > Gilles > >> [1] >> https://issues.apache.org/jira/browse/RNG-40?filter=-5&jql=project%20%3D%20RNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1%20order%20by%20priority%20DESC%2Cupdated%20DESC >> >>> >>> -Rob >>> >>>> From what I see wrt the creation of "full dist" artefacts, the >>>> difference with e.g. [RNG] is that in [jcs], there is a maven >>>> module, with no code, while for [RNG], there is a directory >>>> (not a maven module), but both contain a POM whose only purpose >>>> is to provide an "assembly" config. >>>> >>>> Having no idea on how to achieve it, I'd wish that creating >>>> the "full dist" only requires a custom "goal" like (?) >>>> $ mvn package:dist >>>> with no ad-hoc directory/module: all modules specified in the >>>> top POM would have their artefacts (recursively) bundled into >>>> <component>-dist-<version>.tar.gz >>>> >>>> Regards, >>>> Gilles >>>> >>>>> Cheers, >>>>> -Rob >>>>> >>>>>> >>>>>> Gilles >>>>>> >>>>>>>>> I >>>>>>>>> figure we pick one and make that the standard multi-module build >>>>>>>>> paradigm and fit the others into it. >>>>>>>>> >>>>>>>>> -Rob > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
