-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian,
>> As I already said, I talked about release-plugin and my view of the world >> and it seems NOT to fit together. My POM-tree follows strict logical >> aspects that is motivated by the architecture of the project and NOT by >> the philosophy of some plugin. >> > > I'm trying to understand your structure and motivations behind it, so if you > would care to elaborate, we can be sure to consider these aspects down the > road. > Sorry, maybe my words were a little rude (thanks christian btw). I am also NOT a native speaker... Thanks for your friendly response though :) My idea of release-plugin was that if a module in the tree (reactor) has no snapshot version, it should NOT be released then. This allows me to open individual snapshots of single modules without versioning the entire tree (including modules that have NOT changed at all). But how would I tell release-plugin to open one module for development as snapshot and update all other snapshot modules that depend on it so they point on the proper version. I started thinking about a swing GUI opened by the plugin that shows the module tree and allows to change versions including dependencies on that and shows modules that point to an older version of a reactor module. Whenever I thought about it, I came to the point that the problem is just that you have to change versions redundant in various POMs. So if you could just omit the version in case you want to express that you mean the version from the reactor that is in latest state on your disc and in your IDE, all problems were solved. But as pointed out, when the POM is installed/deployed, you have to insert the version valid at this time. It is already possible if you define the versions all in toplevel pom, set all versions of modules with packaging "pom" to 1.0 and never change them semantically in dependency and build sections and finally add some XSLT MOJO bound to install phase that transforms the installed pom replacing the version. A hack so far, but my hope is that it will work smooth one day with plain native maven standard. Thanks again Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ9oAACgkQmPuec2Dcv/8c5gCgmYPuA1K7Wg32nvFpFLlemoWr oAIAnRmVKP801i71yysAVDen9b+BlK0P =UIdK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org