Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 31160 invoked from network); 2 Dec 2006 15:36:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Dec 2006 15:36:29 -0000 Received: (qmail 12976 invoked by uid 500); 2 Dec 2006 15:36:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 12931 invoked by uid 500); 2 Dec 2006 15:36:37 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 12914 invoked by uid 99); 2 Dec 2006 15:36:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Dec 2006 07:36:37 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of juliusdavies@gmail.com designates 64.233.162.229 as permitted sender) Received: from [64.233.162.229] (HELO nz-out-0102.google.com) (64.233.162.229) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Dec 2006 07:36:26 -0800 Received: by nz-out-0102.google.com with SMTP id i28so1530465nzi for ; Sat, 02 Dec 2006 07:36:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c/K/8yxM4G4HtDrgJbU1uJ4UwGkCfYlOujpPDoko7ne7jpk4sTUxDOn2ZfTp9uxx3R6Cg3SlM6bGtivltgBq9EWPpbPx2nU/wDI71DjfVDrIEWvcpBc3UTMmH5yjygpMrUSnY1znGlLB+2aMloBD2Rwe0k/pWknKc3odbNB0qgc= Received: by 10.65.251.1 with SMTP id d1mr9592081qbs.1165073764990; Sat, 02 Dec 2006 07:36:04 -0800 (PST) Received: by 10.65.155.4 with HTTP; Sat, 2 Dec 2006 07:36:04 -0800 (PST) Message-ID: <598ad5b50612020736u5c8b73f0tde7fc2bcb8e8a367@mail.gmail.com> Date: Sat, 2 Dec 2006 10:36:04 -0500 From: "Julius Davies" To: "Apache Directory Developers List" Subject: Re: Version numbers on Dependencies In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <598ad5b50612011708t7d3be33cnb26978e25d012ca1@mail.gmail.com> <915165.15627.qm@web60713.mail.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org 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 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/