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
>
>

Reply via email to