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 20:30:48 GMT
On Nov 15, 2006, at 3:01 PM, Carl Trieloff wrote:

> Steve Vinoski wrote:
>>
>> 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.
>
> You missed the question. the question is what is the best way to  
> include dependencies that are not built with maven. and don't tell  
> me I don't need that.

No, Gordon's question was about including any jar file not  
*published* to a public maven repository, and that was the question I  
answered. Your question is different -- you're asking about things  
*built* or *not built* with maven.

One example of what you're talking about is Mozilla Rhino that  
Tuscany and CXF each depend on. It's under the NPL license, I  
believe, so those projects can't ship it, so instead they just tell  
users where they can get it for themselves. But guess what -- Rhino  
is still available from a maven repository, and that's how Tuscany  
and CXF manage that dependency.

Ultimately, though, the answer to your question for Qpid is that it  
the mvn branch already shows that we have no dependencies that aren't  
already properly available. If you know of some actual upcoming  
dependency to be added that's not yet available in a maven  
repository, please let the group know. Again, I'd rather not argue  
the hypothetical -- I want to keep the discussion grounded in  
reality. We don't have any actual plans to go wild with adding tons  
of dependencies, do we? Or are you trying to imply that Qpid is  
somehow so different from all the other projects out there  
successfully using maven that maven's dependency management scheme  
just isn't going to work for Qpid?

This all comes down to discipline. As Dan explains, we can't just  
grab any old code we want and cram it into our release, regardless of  
whether we're using maven or not. There are legal reasons for this,  
and there are release engineering reasons for this. One of the  
benefits of maven is that it greatly helps enforce those rules.

--steve

Mime
View raw message