-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Brian,
> First question, wouldn't ${project.version} solve the use case of
> updating same versioned dependencies?
Nope. It would help in some of my business projects where
all artifacts get the same version when released, but
I already have a simple workaround to solve this.
In my major open-source-project I have a lot of modules
with various inter-project dependencies. Here I have
individual release cycles per module and have a
real maintenance hell with maven. I tried release-plugin
multiple times but gave up. I also talked with the
release-plugin evangelists but they want me to believe
in their religion and organize my project in the way
that they think what does not fit for me at all.
>
> Also: "A <version> that was omitted in a <dependency> section can only
> be resolved if the referenced modules are resolved. So if it is NOT
> part of the sub-tree where the build was invoked we have a problem to
> solve. However this can be done by adding a list of projects named
> "closure" similar to the reactor but that is build from the
> toplevel-pom recursively following the <modules>."
>
> This doesn't work unless you have a whole project checked out on disk.
> You couldn't resolve from a repository because the module entry refers
> to a subfolder of where to pom is, but in a repository it's
> meaningless...ie it has no complete coordinates.
Exactly. You got it and this is what I want and what my
proposal is all about.
Therefore I wrote about the "two views on a pom" in my proposal.
I also thought I clearly explained that an omitted version will
never get deployed to a repository and this only applies to
development view when a POM is read as pom.xml from local disc.
You maybe never had these problems when you work with single
or few modules at a time. Or these modules/artifacts are not that
dependent. But if you have a project with 50, 100 or more
modules with a large dependency tree and you want to release
some common-modules and then want to ensure that further releases
of modules that depend on that will be tested and released
based on the current releases of the common-modules you will
get a little crazy. Especially when there are some few modules
that by intention use an older version of some common-module.
Maybe you should think of what if apache.org was maintained
in one single module tree by one developer that rolls a dice
every day to decide in which module to work today.
Besides wasting all his time to get into that code before
being productive he might get lost in maintaining the
versions of commons-* or whatever in all other projects
after doing releases.
This is a very crazy scenario but comes close to my problem.
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkp3SJwACgkQmPuec2Dcv/8pBwCffyhyVCZ9GaT+B1HkGw4dOsoM
d9gAn25Xi4B+/WRu1rppTIphR7GcsMr2
=1dA1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
