qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <ai...@apache.org>
Subject Re: [Discussion] Release Artefacts
Date Thu, 19 Feb 2009 10:36:54 GMT
On Wed, Feb 18, 2009 at 4:41 PM, Martin Ritchie <ritchiem@apache.org> wrote:

> Starting with the source packages that we should be providing:
>
>  - C++
>  - C#
>  - Java (broker, client, common & testing)
>  - Java Management (all management components)

I don't think it makes sense to split the Java components by source.

> I believe that if we are providing source packages then they should
> provide more value than a tar of the svn tree. Such is the case for
> the C++ source that has had the framing already generated. I think the
> frame generation should be performed for all of the source builds that
> we provide this would mean that we do not need to bundle the various
> generators and end users would have all the source they need. If a
> user wanted to have control over the generated files then they can
> download the tagged source version. I don't think mirroring a straight
> svn export offers anything to an end user over the svn tag for the
> release.

Generating the C++ framing is rather onerous, since it adds a dep
(ruby?). Generating the java framing doesn't really add any pain.

> In addition to the source packages we should also be providing binary
> builds or at least access to builds of the components that we believe
> are ready for use. I would also advocate that the packages we provide
> should be of a useful unit to an end user. As such I would suggest the
> following packages:
> The current brokers should be shipped in the following packages:
>  - C++ with a link by supported platform (32/64bit)
>  + Linux, (binary/rpm/link)
>  + Windows (zip/link)

I think it only makes sense for us to provide C++ binaries for
windows. Freenixen are better served by providing binaries in
downstream (eg. Fedora, OpenSUSE has ruby client packages). Java
binaries make sense becuase of WORA[1], and packaging Java is still a
PITA in a lot of places.

> Shipping the brokers on their own means that we can have discrete
> client packages per language which allows them to be more readily used
> with any AMQP broker.
> Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
> two packages:
>  + Client Libraries
>  + Examples

Are we going to try shipping the client via maven again? I know it
would be useful for some users and it is, whatever your opinion, one
of the standard ways of distributing Java libs. I had a quick look at
using Ivy to manage our depedencies but got a bit ADD. It did look
like it would be able to do this pretty easily and without generating
network traffic.

- Aidan

[1] or WOTE, if you're feeling snarky
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message