On Wed, Feb 18, 2009 at 4:41 PM, Martin Ritchie <[email protected]> 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:[email protected]
