On Fri, 16 Feb 2018 14:33:19 -0500, Rob Tompkins wrote:
On Feb 16, 2018, at 2:23 PM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Fri, 16 Feb 2018 12:17:29 -0500, Rob Tompkins wrote:
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.
Sorry I don't follow.
I've detailed what went wrong with the distribution files when
doing the release candidate for RNG v1.0.
The web site is/was not a problem for me, and is not part of
the official artefacts.
Sure I understand that.
The goal was to avoid having to SFTP the site up to your personal
location by checking it in as a .zip to the dev dist location
automatically.
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.
That bit (having to remove unwanted artefacts from Nexus) was/is
annoying. But IIRC some people argued that the removal is not
necessary (?).
This may indeed be the case, but the current documentation says to
not do this, so the plugin facilitates that. I’m personally
indifferent, so I’m just sticking with the docs for the time being.
I’m going to play with [rng] from now forward to see how the
-Ptest-deploy works. I’ve seen you in there (in the last day or so),
and don’t want to step on any toes. I’ll try to follow along with
what
we have in place and form the plugin to work with what you have.
Note,
only minimal changes may be necessary to accomplish this, but it’s a
matter of my playing with things to get there.
OK. As I've noted in another post, I think that everything is
in place for an attempt to release v1.1 of "Commons RNG".
Let me know when you are finished "playing with things". ;-)
What would be great is that you create a new document
besides the one documenting the current recipe:
doc/release/release.howto.txt
with the alternative steps (i.e. using you new plugin).
Thanks,
Gilles
-Rob
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.
How is [RNG] different?
https://git1-us-west.apache.org/repos/asf?p=commons-rng.git;a=tree;f=src;h=647b5d7b8fa117237fa068ba458736c5f996abc7;hb=HEAD
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
