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.
