On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller <jo...@j-hohwiller.de>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6 > pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F > =HnyW > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
