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:11:28 GMT

Thanks Dan,

Here is my concern, what if we use a BSD or CDL licensed dependency 
(apache approved license), we may for one of the features we build and 
that project is not in maven repo and has no desire to be.

Well it is most likely no worse than ant, but pain that we will need to 
live with.


Daniel Kulp wrote:
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message