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

Reply via email to