Hello, I thought it best if we discuss what we are looking to release as artefacts for the upcoming release.
Let me start with what I think we should be releasing with my reasons and we can see what the general view is. Starting with the source packages that we should be providing: - C++ - C# - Java (broker, client, common & testing) - Java Management (all management components) - Ruby - Python 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. I am also suggesting that we split the Java AMQP implementation, broker, client, common & tests from the Java management code as the groups are distinct packages. Splitting the source down further to a broker, client & common packages is not necessary. 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) - Java (zip) The brokers should be provided on their own without any other package as that makes a useful package size for the following reasons: 1) Use of a Qpid broker with a client library that is not of the same language or even a Qpid client 2) Upgrade of an existing Qpid broker, where clients are also not migrating. 3) Evaluation of Qpid brokers compared to other AMQP offerings. 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 I'd advocate the separation of library and examples as each package is a useful package in its own right. I am more open here to persuasion that this is unnecessary but thinking wider that just Qpid our clients could be useful to all AMQP implementations. In these cases shipping examples as a separate package makes sense to me. Finally we have the management tools, apologies if I have missed a tool from the list. Each of the tools should get their own package so an end user can grab the tool they are interested in. Taking the steps to make each of these tools a separate package opens the option for them to release bug fixes in their own right without being tied to a full release. Management - Eclipse JMX Console + Win + Linux + OS X - JMX Command LIne Tool - QMan - WsDmAdapter I'd like to get views from everyone in the project as it affects all of the work we do and the way it is provided to the world. While it may require a bit of effort to get the packages easily built for release I think it is a worthwhile goal. Cheers Martin -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
