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
