> On Feb 16, 2018, at 2:47 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > On Thu, 15 Feb 2018 15:01:23 -0500, Rob Tompkins 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. > > Which project is serving as playground? > >> More debugging there will likely tease out >> the issue. The goal is to have the mojos only operate on the top level >> pom.xml. > > Why? [It is conceivable that some project may want to release > some sub-module(s).]
For the most part the plugin centers on the assembly files, the site, and the release notes for which a release only has one of. So my focus is to get that working, then we can jump into the how to think about a release where individual sub modules are removed. If we do a release removing sub modules, how do we accomplish that? Do we remove them from the Pom? > > Gilles > >> >> -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
