> On Feb 15, 2018, at 3:06 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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. >
+1 > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
