qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: Maven and artifacts....
Date Wed, 15 Nov 2006 23:04:52 GMT

On Nov 15, 2006, at 5:44 PM, Robert Greig wrote:

> On 15/11/06, Steve Vinoski <vinoski@iona.com> wrote:
>> Carl, the better question is, "Why would you want do that?"
> As an example: Martin and I have been working on enhancements to MINA.
> We have submitted the changes to the MINA project (who I should add
> are very responsive and open to improvements and suggestions), and
> they are currently looking at those changes. One user, who is part of
> the AsyncWeb project has tested it and found that throughput doubled
> for some of their tests, so it clearly has at least some merit.
> 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.

> If we have developed something that we as a group agree improves our
> project, should we have to wait for the release cycle of other
> projects? What if it is a straightforward but for us critical bug fix?
> As some people have mentioned, the Apache release process can be quite
> long.

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.

> Does Apache have any kind of policy or guidelines for releasing
> patches? Does Maven have any support for patches? e.g. can you say
> take "M24 plus patches 6432 and 6433"?

In a pom, you specify a version. For development work, you can pick  
up snapshot versions from the snapshot repository. For releases, my  
understanding is that you can pick up only released dependencies.

>> For released software, though, creating dependencies like this would
>> be sheer insanity. You'd be generating artifacts that couldn't be
>> reproduced.
> 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.

> 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.

> 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.


View raw message