qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Maven and artifacts....
Date Thu, 16 Nov 2006 16:26:05 GMT
On 15/11/06, Steve Vinoski <vinoski@iona.com> wrote:
>
> 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.


With Apache licensed software, we can use any checked in code that bears the
license.

>From what I see Apache is a pragmatic organisation.  Rob  used MINA in Qpid
becuase it saved re-inventing that wheel.  But the wheel didn't quite fit so
he made a modification. That does not mean MINA ever has to take that
modification; we either live with this, or back our and invent our own
network layer- like ActiveMQ has.  Obviously, we would love MINA to take the
mods and we'll lobby -- but it does not mean we will win (we might even
break someone elses system if we were to win).

This is pragmatic; it works - it leads to better Qpid and happier users, a
possibility of 'better' MINA, and happy MINA committers because there work
is being re-used on a network-instensive project.  Good all round.

> I don't understand this. If you include an archive of the source
> > surely it is reproducible? Information indicating the svn revision on
> > which it is based is surely sufficient to make it clear from where the
> > source for that dependency is derived?
>
> 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.


Including an entire source tree is sometimes desireable.  SubVersion had
this issue when it included a patched version of APR for a long time.  No
issue -- the SVN team got working code, SVN users got an easy-to-live-with
package and the APR team got proposed changed tested in the wild.  Happiness
again.

>From a stability point; #including entire source trees has certain appeals.

> In an ideal world we would be able to take released versions of all

> > our dependencies but for some dependencies I don't think this is
> > feasible. Some dependencies such as MINA have a huge impact on our
> > software.
>
> That's why infrastructure software often has as few dependencies as
> possible. Qpid could certainly be considered to be infrastructure.


Fully agree.  We have a tension between isolation/stability and re-use.

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.


Disagree - you can cut'n'paste -- which is taking an unreleased version; or
you can have a containment relationship to another system.  When you have a
containment relationship, that other system had better be very stable, very
reliable and have a solid contract on its interface.
MINA is nearly there but not yet.

I expect Qpid to fall into the same class of "needs to be stable" software
as OS software.  This relates to Steve's point about having few
dependencies; that's code for "any dependencies you have had better be
absolutely stable".

To summarise - we should do what ever is necessary and legal to accelerate
our development whilst maintaining good performance and application
stability.

Maven is also good for that.  I look forward to it in M2 :-)

"Release early. Release often. And listen to your customers." -- Eric
Raymond.

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