On Fri, 23 Feb 2018 07:29:54 -0500, Rob Tompkins wrote:
On Feb 23, 2018, at 7:23 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Fri, 23 Feb 2018 07:07:27 -0500, Rob Tompkins wrote:
I’m wondering how multi-module projects will do with the plugin in
the parent pom. I say this because when I’ve declared the release
plugin in the top-level pom.xml of a project, I’ve had issues, but
after moving it down into the “dist” project of the multi-module
build
it worked. Basically, we don’t want the plugin to make its way down
into the other sub-projects.
I suppose before publishing 1.1, I should get it working with the
parent in a multi-module project. I’ll work on that next.
If there will remain a "dist" module, I don't see the need to
"use" the plugin at the top-level; it can be declared in "dist"
only.
However, having "dist" is today's situation; I thought that one
of the aims was to be able to do without.
Preventing recursing into sub-modules sounds an "anti-maven"
way (IIUC).
Why can't an approach with a profile be used (similar to the
aggregation of, e.g., Jacoco outputs)?
I think these are good points, but the problem becomes that we only
want the plugin to run in the location where the dists reside,
regardless of location, still implying a one time run. So when we
declare it in the parent pom, it descends into all of the projects
and
isn’t run in a single location only. I suppose, though, I could make
it only actionable when there are dist files in the “attached”
artifacts or in the staging directory. That could get me around the
problem. But, that feels hacky.
Hacky as it looks, using profile-triggering files seems the
de-facto accepted way to selectively enable some functionality.
We could have a "profile.dist.artefact" file that indicates to
the plugin to look for the JAR file.
Gilles
-Rob
Regards,
Gilles
-Rob
On Feb 22, 2018, at 4:39 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
On Thu, Feb 22, 2018 at 2:25 PM, Rob Tompkins <chtom...@gmail.com>
wrote:
On Feb 22, 2018, at 3:24 PM, Gary Gregory
<garydgreg...@gmail.com>
wrote:
Hi Rob and All:
What do we think about adding [commons-release-plugin] to
[parent] and
releasing?
Should the sequence be:
- Release commons-release-plugin 1.1
- Add commons-release-plugin to parent and release parent.
- Try a Commons component release using the new parent?
Rob: As the creator of commons-release-plugin, would you be
willing to
perform the above and update our release documentation?
Yes. I’ll work towards that. I’m close to getting 1.1 up and out
as is.
I’ll lazy vote it i think.
That sounds good to me.
Gary
-Rob
Thank you,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
