What if a feature was added to the maven-release-plugin to release a subset of submodules? I wonder how feasible that would be.
On 28 November 2016 at 19:00, Jörg Schaible <joerg.schai...@gmx.de> wrote: > Gilles wrote: > > > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote: > >> Gilles, > >> > >> 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 versions > >> are > >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very > >> little sense to have them be out of sync. If you don’t use the > >> release > >> plugin then you will have to come up with some custom release > >> mechanism that somehow can only release a portion of your project. > >> This is going to get rather messy as you will constantly be updating > >> the parent pom to increment versions and require that to be released > >> along with the modules you are releasing - which means your other > >> modules really need to be updated to reflect the new parent version. > >> > >> To be honest, I did what you are suggesting at a former employer. We > >> eventually stopped and synchronized the versions of all the modules. > >> It simply wasn’t worth the effort to have all the versions be > >> different and the only real cost was releasing components with new > >> 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 conventions). > However, the release process described in rng does not use the release > 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. > > Cheers, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>