qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: Maven and artifacts....
Date Wed, 15 Nov 2006 19:53:00 GMT

On Nov 15, 2006, at 2:23 PM, Carl Trieloff wrote:

>
> Dan,
>
> I get all that.. can you provide feedback on Gordon question: "Are  
> you saying it is not possible for maven to be used to build a  
> release that includes any jar file that is not published to a  
> public maven repository? "

Carl, the better question is, "Why would you want do that?"

During debug or development, grabbing new stuff and trying it out  
isn't an issue. If maven can't download something, it will tell you,  
and will even tell you, if you have the file on hand, how to install  
it into your own local repository.

For released software, though, creating dependencies like this would  
be sheer insanity. You'd be generating artifacts that couldn't be  
reproduced.

> This is key as for most projects. everything that we use might not/ 
> will not be in a maven repository. How is this best handled with  
> maven?

That's unlikely. You're asserting a hypothetical situation that  
doesn't seem to hamper any of the existing projects that are actually  
using maven in real life. Can you provide an actual concrete example  
of a released dependency the qpid requires that isn't available in a  
maven repository?

--steve

>
> Insights appreciated.
> Carl.
>
>
>
> Daniel Kulp wrote:
>> There seems to be a little bit of confusion around one of the  
>> major benefits of using maven, namely the ability to more easily  
>> integrate into other maven based projects, and I want to clear  
>> that up a bit.
>>
>> With a traditional build system (like the current ant based build  
>> system), the only final artifacts that we care about are the final  
>> distributions that are shipped to end users.   For this, we just  
>> provide a zip/tar.gz that the user unpacks and uses based on the  
>> structure/scripts we provide.   That's perfectly fine for end users.
>> However, for other projects that would like to use it internally,  
>> it puts a large burden on them.   They need to unpack it, figure  
>> out the dependencies, import it into their svn repository, update  
>> build systems, etc...   Whenever we release a new version, that  
>> whole process repeats itself.
>>
>>
>> With maven, the set of artifacts that are released at release time  
>> expands to also include the smaller artifacts that we build.  For  
>> example: the qpid-client jar.    Those artifacts are published  
>> into the maven repository.   The associated pom.xml file describes  
>> the dependencies that that artifact has.   Thus, when another  
>> project declares a dependency on "org.apache.qpid::qpid-client",  
>> maven will automatically also handle the jms dependency, the mina  
>> dependency, the qpid-common dependency, etc...    However, that  
>> requires that all those dependencies also be available.   If they  
>> aren't, the whole process breaks down.
>>
>> That's why Steve and I are strongly requesting to only depend on  
>> released artifacts.   (for testing, you can use locally installed  
>> artifacts like fscontext.   That would be <scope>test</ 
>> scope>.)      If you don't use released artifacts, integration  
>> with projects like Tuscany and CXF will be impossible.
>>
>>
>> Anyway, the main thing I wanted to point out that with maven, a  
>> release is not just the end user distributions, but also the  
>> artifacts that other projects will depend on.
>>
>>
>


Mime
View raw message