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:10:24 GMT
I completely agree with Robert's statements here.


On 15/11/06, Robert Greig <robert.j.greig@gmail.com> 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.
> 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.
> 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"?
> > 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?
> 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.
> 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.
> RG

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