John Casey wrote:
> 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.
I think you touch on a key point here. Building in the context of
putting together a distribution is very different from an end user
downloading and building something for themselves.
A distribution is trying to provide a consistent set of well integrated
packages. In this context you want to avoid multiple versions of a
package if you can because 99% of users don't care and in fact will be
confused if they have to choose between two versions of the same thing.
Not to mention security patches become nearly impossible if you need to
keep around any old version of a package. There are cases where
installing multiple versions makes sense and RPM can do that if you
want, but for these reasons most distros try to avoid it and it's not
uncommon for them to build against a slightly different version of
dependencies than upstream developers use in order to eliminate multiple
package versions.
Of course all this is in stark contrast with an end user downloading a
source tarball directly and building it himself. In this scenario the
user may want to duplicate as closely as possible the build conditions
that the upstream developers use themselves and so he would want
precisely the same version that upstream is using.
So I see two distinct use cases for building software:
1. Precisely reproducing upstream builds. Maven is already an excellent
tool for this.
2. Building software to integrate with a pre-existing environment. This
is what fedora or any other distro needs, and right now it's not so easy
with maven.
--Rafael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
