Yeah, that could be the better way, with a branched off commit for the "shrunk" project with a smaller <modules> list in the parent, then no particular flags are needed to build from the resulting tag or source repo.
I initially planned to do so within the Taverna project (before we moved to ASF), as it could mean smaller releases and avoiding updating OSGi coordinates for no-change. It turned out to alienate the rest of the team as then releasing become even more special, particularly if more than one submodule needed updating. After moving to ASF we had to do release artifacts (not just tags and Maven repo) and we abandoned this idea and had to bite the bullet to release all modules every time. As an example of projects doing the partial, look at the Clerezza project which practices this using alternative release parents and dists; as an outsider I find it a bit difficult to understand what of the project has been released where (or at all), and which versions go together. Commons components are luckily small, so I think it could be done - but only IF NEEDED, rather than as general practice. There is also the consideration of operation system distributions like Debian who prefer a single source archive or tag for the whole project (and no dual versions) - varying this per release means they are going to not update correctly. Several commons component (including math3) are already in Debian. On 30 Nov 2016 9:04 am, "Gilles" <gil...@harfang.homelinux.org> wrote: > 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 >> subset >> 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.] > > Gilles > > 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 > >
