> 2: Ensure that projects can build against a single version of a
> dependency, rather than multiple.
This bothers me the most. If my project's pom.xml says I depend on "foo
version 1.1.3", it better be built and installed with "foo version 1.1.3",
not "foo version 1.2" or "foo version 1.1.5" of "foo version 2.0". If I
wanted to say "any 1.x version", I would have used a version range in my
pom.
If redhat or rpm or whatever cannot install multiple versions of a
resource,
that seems like a deficiency in those and I don't think maven should go
out
of it's way to work around that. Maven's dependency management is
definitely one of it's strong point. That type of change bypasses all of
that.
This is a sticking point for me, too, actually. It might be okay to drop the
versions off of a build during the distro-building process, because you've
got other systems managing compatibility of versions in the larger
context...but if a user gets to do that sort of thing, it's going to be a
major support problem for us, and it's counter to a lot of what we're trying
to do with Maven in the first place. In the first case, it's more like an
alternative version-conflict resolution step...in the second, it's hijacking
Maven's notion of artifact identity and build reproducibility.
-john
