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
