Aidan Skinner wrote:
On Thu, Jun 25, 2009 at 2:53 PM, Rajith Attapattu <[email protected]> wrote:
On Thu, Jun 25, 2009 at 8:27 AM, Bryan Kearney<[email protected]> wrote:
Ok.. I get it it now. As I understand Aiden's idea in ivy is to pull the
dependenr libraries from maven repos, but not to use maven as the build.
Aidan, So don't we still get into the same problem if the maven repos
no longer carry the version we require?
Ivy could produce repeatable builds assuming the maven repos still
carry the version we need.
Perhaps I am missing something here??
Well, my idea was to use ivy to pull from somewhere other than the
maven repos. All the build systems I'm familar with have some varient
of the rule that the same source built on the same system should
result in equivalent bits, which this would help with.
It would also help with letting us use system versions of the
libraries, rather than shipping our own. This is more in keeping with
what users expect and generally play nicer.
Giving ivy enough information to let it populate our lib/ from the
maven repos on demand and shipping those as we do today is probably
Good Enough and quicker than writing our own resovler.
There is definitely value in publishing the client bits in maven repos
as a few projects that use maven wants to use Qpid.
I'd rather do this generically for all modules, obviously more people
are interested in the client bits...
I'm not sure how solvable this problem really is. The fundamental issue
seems to be that maven users want the canonical qpid dependencies
specified in terms of maven repos, whereas we need the canonical qpid
dependencies to be whatever is checked into svn.
It seems like one way or another we'll need to maintain an extra non
canonical set of dependency metadata in order to produce meaningful poms.
Obviously there are better and worse ways to go about it, but
unfortunately no matter how we do this, it still means we either do
twice the testing come release time, or we ship jars that contain
untested poms, neither of which seem acceptable to me. Already there are
enough different profiles and environments to test against that releases
drag on for months.
I think a better way to address this issue is to simply produce plain
old jars from the main build and then provide a contrib area for maven
users to donate poms for the qpid artifacts they use.
IMHO this approach has some substantial benefits. It's quite lightweight
and won't have any impact on our release process. The poms aren't part
of the officially signed release artifacts, so if the maven repos
change/break or if the poms have an error they can be updated
retroactively for any given release without invalidating the official
artifacts. And ultimately, the poms will probably be better tested and
maintained than something we can get ant to spew out automatically
because they're coming from people who actually use maven and would
notice when the poms are broken.
What do people think? Could some scheme like this be made streamlined
and workable for all involved?
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
