maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Berry <>
Subject Re: partial multiproject release
Date Wed, 19 Oct 2005 21:21:49 GMT
Hi Orjan,
I guess the moral of the story is that you should not put dependencies on
SNAPSHOTs. Or put another way, if you depend upon SNAPSHOTs then you are
coupling yourself to the release cycle of the SNAPSHOT project. Separating
generic,a,b, and c into separate projects, you are saying that each of these
packages has independent life cycles, and thus, you need to cut real
The Release Plugin should not cut releases of projects outside it's current
My two cents.
-- Chris

On 10/19/05, Orjan Nygaard Austvold <> wrote:
> We have several multiproject structures holding multiple "generic"
> artifacts. Released versions of these artifacts gets used by yet other
> projects ("customizing" them in a product installation).
> The multiproject structures looks somewhat like this (version in
> parenthesis):
> generic (1.1-SNAPSHOT)
> artifact a (1.1-SNAPSHOT)
> artifact_b (1.2-SNAPSHOT)
> artifact_c (1.0-SNAPSHOT)
> In this scenario b and c depends on a (a,b and c have generic as their
> parent).
> The generic pom have a dependencyManagement section list artifact a,b
> and with their versions (makes inter-module dependencies easier to
> handle).
> Upon having made some changes on the module b we would like to have it
> released (new version is 1.2,). This forces us to release both a and
> the generic pom since we do not want a released version of b to depend
> on snapshots. As a side-effect the pom of artifact c must also be
> updated with a new parent version (since the new snapshot versions of a
> and the parent have changed).
> I don't see how the release plugin could help here. An attempt to do
> mvn release:prepare
> in the b artifact directory only tells me that the parent haven't been
> released. I really, really hope I'm wrong and that the release plugin
> could help :-)
> I know that I could do a complete release on the generic pom thus
> upgrading all sub-modules. The downside of this is that the artifact c
> would get a new version number without having any changes.
> Since a release on the parent pom would force all modules to step up to
> the next version, I really don't see any reason to why the modules need
> separate versions anymore...
> Kind of stuck here.
> Thanks,
> Ørjan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message