qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Maven and artifacts....
Date Wed, 15 Nov 2006 20:00:46 GMT

Carl,

On Wednesday November 15 2006 2:23 pm, Carl Trieloff wrote:
> 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? "

Yes, it is possible, but it's not easy and usually would require every 
developer to do extra steps prior to building.   As I mentioned before, 
it will also make it very hard to work with other projects like Tuscany 
and CXF as you then start requiring all of their developers to do the 
same and then all the projects that rely on them also require it, etc...    
It's pretty much viral in nature.

I would VERY strongly recommend against it.


> 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?

Get the artifacts into the repository.     From an apache standpoint, all 
the licenses for stuff we're allowed to use allow for the artifacts to be 
published to the maven repository.   Follow the instructions at:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html

There are problems with certain things not being in central, but those are 
under licenses we aren't allow to use anyway.   Example: jms.jar.   It's 
not in central due to the BCL license, but because of that license, we 
cannot use it anyway.


The other option is to repackage the artifact into the qpid groupId and 
publish it as a relase with qpid.   Kind of like 
org.apache.qpid::qpid-mina or similar.     However, that has a couple of 
problems:

1) From an apache incubator standpoint, that would look bad.   You are 
basically providing a "fork" of the mina code.   From a "goal to 
graduate" standpoint, not good.

2) I have to question whether an apache project is even allow to release a 
snapshot/version of another apache project.    Part of releasing at 
apache is digitally signing the artifacts to certify that they were built 
by that project and all the legal ducks are in a row for that artifact, 
etc...    The ONLY people that can do that are the PMC's for that 
project.  No one (that I know of) on qpid has the authority to certify a 
mina artifact from an Apache standpoint.      Thus, you wouldn't be able 
certify the qpid build if it has an un-certifiable artifact from another 
apache project.    Maybe if a notice is put in place.  Not really sure 
though.    Snapshots of a non-apache project are probably a bit more 
palletable since the NOTICE files and stuff cover those, but still not a 
good idea.

Then again, IANAL.

Dan


> As a side note - in Red Hat some of these types of issues are HELL for
> us, and we have created a bunch of extra stuff to work around problems
> in building distributions in a manageable way with 1000's of packages
> when maven is involved.
>
> 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.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Mime
View raw message