On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
What if a feature was added to the maven-release-plugin to release a
of submodules? I wonder how feasible that would be.
When I thought of independent module releases, I assumed that
it would just be a matter of excluding some of the "<module>"
sections in the (parent) POM. [That seemed to work for making
the Jenkins build pass on Java 6 while the "commons-rng-examples"
requires Java 7.]
On 28 November 2016 at 19:00, Jörg Schaible <joerg.schai...@gmx.de>
> On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>> If you try to do this you are going to get very frustrated with
>> Maven. You cannot use the Maven Release plugin if all the
>> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes
>> little sense to have them be out of sync. If you don’t use the
>> plugin then you will have to come up with some custom release
>> mechanism that somehow can only release a portion of your
>> This is going to get rather messy as you will constantly be
>> the parent pom to increment versions and require that to be
>> along with the modules you are releasing - which means your other
>> modules really need to be updated to reflect the new parent
>> To be honest, I did what you are suggesting at a former employer.
>> eventually stopped and synchronized the versions of all the
>> It simply wasn’t worth the effort to have all the versions be
>> different and the only real cost was releasing components with
>> versions that hadn’t changed.
> Thanks for the testimony.
> Even if I have no clue how the version string causes a problem,
> I can readily concede that we can be constrained in how to manage
> a project because of the shortcomings of some tool.
There is no no short coming, you can do otherwise, but if you follow
conventions Maven makes your life easy (Maven is all about
However, the release process described in rng does not use the
plugin, so the point is moot.
> Out of curiosity, is there an alternative (to maven?) that would
> not suffer from this limitation?
It's not the tool we're discussing.
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org