qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Maven and artifacts....
Date Wed, 15 Nov 2006 20:37:11 GMT
Steve Vinoski wrote:
> 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.
yes but I asked an additional question.  -- Dan provided me the answer. 
thanks.
>
> 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, 
What are the legal reasons? if Apache or BSD licensed you can use part 
or the full work, source or binary form.

> and there are release engineering reasons for this.
agree.
> One of the benefits of maven is that it greatly helps enforce those 
> rules.
>
> --steve


Mime
View raw message