-----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 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
