qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack" <marnie.mccorm...@googlemail.com>
Subject Re: Re : Dependencies and how it's going to affect the release
Date Tue, 07 Nov 2006 08:39:14 GMT
Hi All,

I just wanted to highlight a couple of points about M1, and my view of why
we're doing it now.

The key motivator for M1 is that we have users out there who have deployed
onto Qpid (Java). For that reason alone, we need to get an M1 of the java
broker/client out to support them going forward - before the major M2
changes planned.

In terms of dependencies - we should not be releasing the tests are part of
a release distribution imho. Seems like omeone has erroneously committed a
build script with tests included so we can switch this off and make things

I don't think we can wait for maven - I know Steve has been working hard on
it, but unless it is realistically going to be complete by code freeze (i.e.
tonight) we'll have to get by without it until M2. We've also got a lot of
coding to complete (see the list of M2 JIRAs) and need to focus our
collective effort carefully so that the project moves forward as well as

Rajith - have you managed to pull a list of tasks together yet please ? We
could add the liencese item to the list and get it resolved for the release.
I don't think we have any major obstacles to M1, though I can see we might
have items to create JIRAs for and progress separately to make future
releases easier.

I'm happy to help out with all release tasks to help us get M1 out, annoying
or otherwise. I think it's really important that we get it released as soon
as we can.


On 11/6/06, Rajith Attapattu <rajith77@gmail.com> wrote:
> Hi All,
> AFAIK when we release we will have to package some of the dependcies with
> our binary distribution.
> When we do this we need to make sure we supply the license.txt's for those
> dependencies.
> Currently we have static dependencies in our lib files scattered over the
> project.
> So we need to think about them.
> For example the jms.jar. Now where did this come from?? where is the
> license
> associated with this?
> Usually in apache we use the geronimo spec project to get the API's, so we
> can use that for JMS.
> If I dependencies keeps growing then that will make things even more
> diffficult to manage, especially at distribtuion/release time.
> Maybe it's time to get things a bit more organized and move to a maven
> structure where some of these headache are taken care of.
> Regards,
> Rajith

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