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