Another goal (for me at least) is to put the plugin in commons-parent such each Commons Component does not need to define it, only refer to it.
Gary On Thu, Feb 15, 2018 at 1:01 PM, Rob Tompkins <chtom...@gmail.com> wrote: > > > > 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 > >
