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