Whaooh... What a mail :)
Ok, just to be clear :
- I think that maven, like any other tools, has advantages and drawbacks.
- we are not building a product which is used by million of perons, like linux
- when I install a Linux distro, I don't build it on the fly, grabbing all the rmps from remote repos.
So my point is that when I want a user to simply get a version, I suppose I have to package it for him. If it's a developper who want to comple the project, then he will feel that downloading hundreds of jars is a little bit painfull (unless he has a very fast internet connection, with all the remote repos up and all the jars correctly signed)
I'm sorry, but this is not something we can guarantee atm. I would prefer to depend on a simple repos I can trust (subversion repository, for instance), simply becuase if this repo is untrustable, then you don't have any way to build the product. So we at least have one trustable repo, why do we need to add some more repos ? Let's inject the jars into subversion, getting two advantages :
- only one repo to trust
- all the jars are guaranteed to be ok, becuase they will be tagged with the version.
If a user has a pb with an old version, then you just have to check out the tagged version, and that's it, all the jars are correct.
It seems to be very simple.
Ok, there is one major drawback : it takes some room on disk. But at a time where Google offers 3 Gb of disk space to each of gmail users, it should not be an issue ...
First some background.
All my computers at home and my workstations at my job have been
Debian since 2002. But the actual QA and Production servers my code
gets deployed to are RHEL3.
Java is the only language I really know. I spent 8 months trying to
write a website in PHP in 2000, but since then it's been
I've never used Maven. I've used Ant a lot, and like it a lot.
I would consider myself an "intermediate" level builder of RPM's in
terms of my ability. I've packaged about 10 java applications (some
command-line, some webapps, one EAR) for my company into RPM. I've
watched my RPM's go through upgrades, and even some downgrades over
the last two years. I wouldn't call myself an "advanced" builder
(I've never used "conflicts" or "provides"). I would just call myself
an "intermediate" builder.
I'm probably a weird breed: java-only, and rpm-only. I didn't become
this way on purpose. It just happened!
Anyway without that much RPM experience, and no Maven experience at
all, I would say my comments are definitely coming from the peanut
gallery! Please take them with a grain of salt: I'm the first to say
I don't know what I'm talking about here!
But I'll still talk. :-)
Emmanuel's linke to Stephane Bailliez is really interesting! I agree
100% with this (Stephane even bolded it!):
"Relying on uncontrolled remote repositories is evil at best."
But his next comment is only true because there are no "controlled"
remote repositories for Maven!
"Never trust the online repositories for your project."
My company's RHEL3 subscription is a reliable, controlled online repository.
"Debian-Stable" is also a reliable, controlled online repository.
"Debian-Testing" is also very solid.
"Debian-Unstable" sometimes causes some excitement, but I stick to
this one for my home computer and my workstation because I like to be
more up to date, despite the occasional small headache (maybe twice a
year?). Supposedly this is where active packaging is happening, but I
suspect that most work happens in "Debian-Experimental".
Hope you don't mind my stream-of-conciousness writing on this topic.
What is "Fedora Core 4"? How is it different from "FC 5" and "FC 6"?
To me these are 99% packaging efforts. FC4 is just a collection of
RPMS that work together. FC5 is a newer collection.
Now here's where I start to explore the thin ice. I really don't know
what I'm talking about. But it seems to me that aside from JPackage
(which is tied to linux), the Java world has yet to quite see the
whole dependency management picture. Maybe only five years ago people
used to talk about "RPM Hell". Do people still talk about "DLL Hell"?
Maybe every platform has to go through this at some point?
We're in Jar hell. We've all known this for a few years now -
probably ever since Tomcat 3 printed its first stacktrace. Various
efforts have tried and failed to deliver us from this hell. Most of
the efforts just make things worse. Sun put Xerces into the JVM.
That was fun! This whole Maven thing that's been going on for these
last few years has made everyone so hopeful, but it's so hopeless.
The problem isn't with Maven. Or with that big iBiblio repository. I
think the problem is that us Java developers expect too much from
Maven. RPM was a tool. So was DPKG. But no-one expected these tools
to also try and manage all the packages. That was up to the various
distributions: Redhat, Suse, Debian, Gentoo, etc. It's interesting to
note that both Redhat and Suse use RPM, but their distributions are
quite different in many ways.
Packaging these distributions is hard work! Extremely hard work. I
have no idea, but I imagine Fedora must have at least a dozen people
just constantly downloading the latest "upstream" versions of the
linux applications people want (less, find, tree, bash, grep, zip,
etc.....), packaging them, uploading them into their own internal-only
"experimental" repository, testing them out. Every day. Is it a fun
job? You probably find some pretty interesting bugs!
Until we have versioned collections of the maven repositories on the
web, the insanity will continue. We need companies to form and
publish their own "distributions" of this Java platform. There should
be an "Apache-Unstable" maven repository and an "Apache-Stable"
repository (only supplying apache projects). In our " pom.xml" we
would just point to whatever we were in the mood for at the time.
Redhat could then aggregate the smaller repositories like
"Apache-Unstable" and "Codehaus-Unstable" and "Sun-Unstable" into
their own bigger repository that people could subscribe to for a fee.
That's how I would do JSR 277. ;-) Ah, solving the world's
problems. One email at a time.
I'm worried the JSR 277 "experts" are going to get all obsessed with
JMX and "hot reloading". Meanwhile the "httpd.rpm" I download using
my RHEL3 subscription is just going to automatically call
"/etc/init.d/httpd restart" should I upgrade Apache2 or OpenSSL or any
other library Apache depends on. But, oh no, in Java land, we can't
actually kill the process. Gotta keep that JVM up 24x7.
As for the ApacheDS issue.... instead of using "=" to declare exact
dependencies, maybe you could publish your own "Mini-Maven-Repository"
with the exact versions you "know-to-work".
Then in "pom.xml" you can invite courageous people to try building
against iBiblio, but provide this "Mini-Maven-Repository" as the safe
default that always works.
And this way you can use ">=" since you control that repository, so
">=" ends up just being the same to "=". It only reverts to ">=" when
people edit the pom.xml to point to iBiblio.
On 12/2/06, Emmanuel Lecharny <firstname.lastname@example.org> wrote:
> To answer to David question about maven supporting >= :
> (go to "Dependency Version Range")
> Ok, it's not perfect though :
> Now, Ole has brought a very valid point on the table. Using >= seems
> attractive, but it's the very last thing we should do in a configuration
> management system. We should be able to build a version N of ADS which
> include _known_ versions of each used dependency, not allowing the build
> tool to download whatever last version available on a remote repos : the
> rationnal is that when you cut a verion, you unit-test it, integratuon-test
> it, and it should be reproductible. If at least a component change, and if
> you have a problem, then there is no easy way to help the guy who has the