OK - One more Dab Gum! I'm smacking up this document, when I thought...Didn't I see something that sort of looks like this on the Maven site.
Dada: http://maven.apache.org/archiva/ Anyways - I think that is this...which I'm going to post anyways now that I wrote it. Could you guys give me your thoughts on it please? Is it tight? Meanwhile, I'll read up on Archiva a little more and see what the deal is. OK - Here's the Cookbook item along with a Proposal section built in: Challenge Ensuring that versioning happens on maven repository artifacts, along with signature checking on repository provided dependencies. Solution See discussion Discussion Developers need to be assured that the versions they have in their local repository are not updated WITHOUT a corresponding version revision. For example suppose someone wants to try out ApacheDS, and they also want to build it themselves. Suppose that ApacheDS has the following dependency: <dependency> <artifactId>SuperImportantArtifact</artifactId> <version>SuperImportantArtifact</version> <scope>compile</scope> </dependency> Suppose the provider of SuperImportantArtifact makes a few changes and uploads the changes to ibiblio, however the provider forgets to change the version correspondingly. Next someone checks out the ApacheDS build and builds it. Maven downloads the dependencies it needs from Ibiblio, including SuperImportantArtifact. However the developer is getting build errors. We know why in this case. How do we insure that this case does not happen. Proposal * Artifact Download Concern Have the repository deployer calculate a checksum for artifacts and write the checksum to repository meta data. When maven deploys and artifact, have it write the checksums into the pom artifact for all the dependencies, and rewrite it's own pom with these checksums built in. So now if someone checks out the build from subversion..say.. the pom is checksum aware, and can validate the corresponding checksum using repository meta data for dependencies that it downloads. * Artifact Upload Concern Create a Maven Repository Server that performs revision checking. If someone tries to upload an artifact without changing the version (overwriting and existing artifact), the server complains and sends the complaint back to maven. Maven then just logs it to the console. This ensures that an artifact does not get overwritten without changing the version. * Summary I think with the above two concerns address the process should be fairly tight. We have a unique signature on dependencies, so we match this up with the signature on the repository before the dependency is downloaded. If the signatures don't match, we cancel the build. We also check the upload to make sure that version revision happens. --- Emmanuel Lecharny <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 > === message truncated === ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
