qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: Maven and artifacts....
Date Thu, 16 Nov 2006 09:14:02 GMT
On 15/11/06, Steve Vinoski <vinoski@iona.com> wrote:
> > However, we don't know for sure when MINA will decide to adopt the
> > patch. They may have competing priorities for their release.
> Right. So one avenue open to you is to lobby them to prepare a
> release, just as you lobby them to accept design changes and patches.

The point I was trying to make was that in general even with projects
where we have a very good relationship and where there is clear
agreement that changes we need are widely beneficial they may not be
able to do a release to fit with our timescales. In an ideal world we
would lobby them and get agreement on a release but in general we
should be prepared for this not to be the case.

> Yes, it can be long. But those are the rules by which we must abide
> under Apache. As Rajith points out in a separate email, it's not even
> clear that M1 as it stands can get out the door given its dependency
> on an unreleased version of mina.
> I don't make the rules. I just want to live by them, as I'm sure we
> all do, and I know that maven will help greatly in that regard.

I think Brian McCallister cleared this up, indicating it was not a
rule: http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200611.mbox/%3c15F925F7-6DDC-4F52-AD7E-45F7FFB734A6@apache.org%3e

> That much is true, assuming that you can also grab the entire build
> system and its dependencies, as well as all build dependencies and
> their dependencies, etc., and that it's all under version control,
> and that the upstream project hasn't done what you're doing and just
> grabbed a particular svn revision number to build against for their
> upstream projects. The transitive dependency issues involved end up
> biting you, and hard.

Yes this could be a problem in general but for each case I believe
looking at specifics is worthwhile. In the case of MINA for example
the number of dependencies is extremely small (and will shrink further
very very soon when they remove the backport dependency).

> That's why infrastructure software often has as few dependencies as
> possible. Qpid could certainly be considered to be infrastructure.


> > I do not believe this is unique to open source projects; I often work
> > with vendor software where we get special patched versions to use
> > until the vendor has released an "official" service pack or point
> > release.
> Right, but I bet that 1) you don't actually reach into their source
> code control systems and build your own patches, and 2) they manage
> their patches such that they can be completely recreated at any point
> in the future if necessary. You don't *take* the versions -- instead,
> *they* release the versions to you. Similarly, for Qpid dependencies,
> we'll want to only use artifacts that projects have released for us
> to use.

For most vendors they don't let us do (1) and we are usually paying
them to do (2). It's a different kind of relationship we have with
other open source projects.


View raw message