directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: Version numbers on Dependencies
Date Sat, 02 Dec 2006 17:58:11 GMT
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 <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
> 
=== message truncated ===



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Mime
View raw message