On 15/11/06, Steve Vinoski <[EMAIL PROTECTED]> 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.
