directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <juliusdav...@gmail.com>
Subject Re: Version numbers on Dependencies
Date Sat, 02 Dec 2006 16:39:18 GMT
Hi,

Yeah I don't really mean to be a complainer.  And also, use of "=" is
fine in the "upstream".  A packager like Redhat or JPackage or Debian
can always rewrite your pom.xml (using patch files they store in their
.src.rpm) to build against different versions of the dependencies if
they want to.

I'm really excited by Ole's work on the maven2rpm problem.  I could
really use something like that.  But I'm too busy right now to
contribute except for these obnoxious emails.


yours,

Julius



On 12/2/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> 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 ...
>
> Emmanuel 2cts
>
>
> On 12/2/06, Julius Davies <juliusdavies@gmail.com> wrote:
> > Hi,
> >
> > 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
> > all-java-all-the-time.
> >
> > 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.
> >
> >
> > yours,
> >
> > Julius
> >
> >
> >
> >
> > On 12/2/06, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> > > To answer to David question about maven supporting >= :
> > >
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
> > > (go to "Dependency Version Range")
> > >
> > >  Ok, it's not perfect though :
> > >  http://www.bearaway.org/wp/?p=509
> > >
> > > 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
> > > problem.
> > >
> > > 2cts.
> > >
> > >
> >
> > --
> > yours,
> >
> > Julius Davies
> > 416-652-0183
> > http://juliusdavies.ca/
> >
>
>
>
> --
> Cordialement,
> Emmanuel L├ęcharny


-- 
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

Mime
View raw message