John Casey wrote:
All of this makes sense, until you consider that the user might start using
the Fedora-provided version of Maven for his own software builds. Then you
have a possibility of letting him produce a very messy build that doesn't
use artifact versions. If the possibility is there, it will be [ab]used.
Isn't this just a matter of choosing the right defaults? If by default
you use artifact versions then people won't get a messy build unless
they specifically ask for it, and at that point they should expect the
possibility of some surprises. Distros certainly expect to take on the
burden of integration testing as soon as the depart from upstream build
procedures.
--Rafael
-john
On 12/6/06, Rafael Schloming <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
