On Wednesday 03 October 2007, Robert Greig wrote:
> > Since you haven't done a release, the artifacts aren't there.
> > Once you do the release (providing it's done properly) and actually
> > start getting users that want to integrate Qpid into their builds,
> > this starts becoming increasingly important.
>
> Are you saying there is no way to use a jar in a maven build that
> isn't available on a maven repo? If so that sounds like a pretty
> damning indictment of maven.

Well, there ARE ways to do it, but it's very hard to do and it's very 
fragile so for all intents and purposes, the answer is no.

But that's not a bad thing.   It's a good thing and was specifically 
designed to be that way.

Couple of reasons:
1) Ease for developers - when I need to update a dependency version, I 
just change the version number in my pom and run "mvn install" and mvn 
does the rest to test to see if it will work.   The old way of going off 
to download their distribution, unpacking it, replacing the jars in my 
lib dir, checking the other jars in the distribution (maybe the new 
version includes/depends on newer versions of other things), possibly 
updating the build scripts, etc... really sucks.   

For example: you are currently using mina version 1.0.0.   I see 1.0.6 
was released yesterday.   To see if qpid works, just update your top 
level pom to 1.0.6 and run.   There's also a 1.1.3 released yesterday.  
Again, update and try it.  (I assume 1.1.x might have more API changes 
that may require more work).     If I want to try the 1.0.7-SNAPSHOT 
builds, that's easy too.


2) Ease for your users - related to (1).   If you do a "mvn deploy", all 
your artifacts should then be in the repo.   I could depend on 
qpid-client only and I'd get everything that qpid-client needs 
automatically.   If you have a pom pointing at a local file not in a 
repo, I would then also have to go off to figure out where the hell that 
file is and also do all the "magic" to get mvn to use it.   

It cycles down from there.   Lets say I then deploy new artifacts.   My 
users would then also have to find the jar, etc...   They may not know 
that I even use qpid.   They would just complain and bitch at me for 
something you started.

If the poms accurately describe all the dependencies and the dependencies 
are all available, mvn make it easier for you as well as projects that 
depend on you. (if they also use mvn or the mvn extensions to ant or 
Ivy, which all would use the repositories)


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to