> On Feb 16, 2018, at 11:50 AM, Rob Tompkins <chtom...@gmail.com> wrote: > > > >> On Feb 16, 2018, at 11:16 AM, Gilles <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> 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. >> >> 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. >> >> 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
