maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <>
Subject Re: Progress on support for large projects
Date Fri, 15 May 2009 19:40:22 GMT
On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller <>wrote:

> Hash: SHA1
> Hi,
> > By inheriting the version, groupId, etc. from the parent - yes. The
> > release plugin still handles the pom transformations and the tagging
> > (SCM URLs, snapshot to release version, release to next snapshot
> > version, etc.)
> But there is nothing to change in the POM if the version is a variable.
> Maven will (as suggested in this thread - or also in my usecase via
> xslt-plugin) replace the variable when installing. All I need to change
> is one variable (e.g. in settings.xml). I do not need a releas-plugin
> for that but others may want to.
> >
> >  I am also doing this in some other project that way and
> >> it works fine. But in my personal open-source project I have some
> >> core-libs that are used throughout the project and many modules that
> >> are piled up with lots of dependencies. I have some modules that
> >> are quite steady and do not change so I dont want to release a new
> >> version just because something else changed.
> >
> > I would try splitting those steady modules from the rest of the
> > structure since they seem to not share a common development/release
> > cycle. I would even consider moving these to another svn repository.
> > Without a real example to analyze, hard to tell.
> Once again: the release-plugin guys think in a specific way and there
> are others that have a different oppinion. For me the architecture
> of the system is the main criteria for structuring my pom-tree.
> Imagine that everybody makes it the way you describe because of
> release-plugin. The other day another cool plugin arises that forces
> you to structure your poms and scm by some other criteria.
> What if you want both plugins?

I wouldn't say it's the release plugin that dictates the layout, its what
makes sense in the scm. Generally you take a tree of things and tag it and
release it.

> I think it is a bad idea that a plugin gives a philosophy about
> how users should structure their project.
> Regards
>  Jörg
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6
> pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F
> =HnyW
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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