> On Feb 16, 2018, at 12:17 PM, Rob Tompkins <chtom...@gmail.com> wrote: > > > >> On Feb 16, 2018, at 11:50 AM, Rob Tompkins <chtom...@gmail.com >> <mailto:chtom...@gmail.com>> wrote: >> >> >> >>> On Feb 16, 2018, at 11:16 AM, Gilles <gil...@harfang.homelinux.org >>> <mailto:gil...@harfang.homelinux.org>> wrote: >>> >>> On Fri, 16 Feb 2018 10:05:15 -0500, Rob Tompkins wrote: >>>>> On Feb 16, 2018, at 2:47 AM, Gilles <gil...@harfang.homelinux.org >>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>>>>> <mailto: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 >>>>>>>>>>>> <mailto: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 >>>>>>>>>>>>>> <mailto: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. >>> >>> For "site" and "release notes" I agree that there is one. [Which >>> is the same as saying that this is not multi-module related.] >>> >>> The "assembly" is an problem with the release of a multi-module >>> project (see issue RNG-31). >>> >>> I see that Maven is working "hierarchically" (cf. "effective POM"). >>> But from the above, I have the (perhaps wrong) impression, that you >>> are working against that feature... >>> >>> I have the perhaps naïve view that whenever a module is >>> mentioned in a <modules> directive, it should just be >>> aggregated to the "assembly". >>> >>>> 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. >>> >>> Again, this is the other way around (IMHO): let maven tell you which >>> module is "on" (and the plugin will aggregate); nothing to do for >>> a "removed" <module> directive. >> >> I’m actually not all that concerned with which modules are or aren’t >> included because I’m focusing on what gets staged in subversion for website >> download in the end. I’m not familiar with lots of different types of >> tars/zips other than src and bin ending up there in svn. >> >> >> For the main maven process I’m trying to stay away from doing any subtle >> build manipulation that could effect what gets deployed to nexus, aside from >> keeping the tars/zips from landing up there. >> >>> >>>> If we do a release removing sub modules, how do we accomplish that? >>>> Do we remove them from the Pom? >>> >>> It's a possibility (to be done only in the release branch then). >>> Another, which I mentioned in a previous post (see somewhere >>> above), would be to have a profile that would list the modules >>> to be released. >>> Please look at the POMs, "top-level" and modules, for [RNG]. >>> >>> There is a default list of modules and there is a profile that >>> duplicates that list and add "commons-rng-examples" to allow >>> a more recent language level. > > And, I forgot to mention that I’m working with jcs and vfs as the sample > modules. I think having that src directory at the top level for the > distributions makes sense.
Working with [rng] now as the other’s were a bit cumbersome to work with. > >>> >>> 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 >>>>>>>> >>>>>>>> <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 >>> <mailto:dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org>
