Martin, Thanks for bringing this up for discussion. Here are my two cents.
Source distributions ---------------------------- I am quite happy with the way the current source builds work. I don't think we need to pre generate the framing code (allthough C++ does it to avoid a build dep on ruby). >I believe that if we are providing source packages then they should >provide more value than a tar of the svn tree. I believe as per apache regulations, source builds should be an exact tar/zip of the svn tree. Also other packaging formats like RPM requires a pristine copy of the source from where the binaries are built. As rafi metioned you will have trouble with applying patches, should the patch contains any modification to the templates. I don't think spilting the source distribution in anyway is worth the trouble. A source distribution should build as it is. To dp that, we might have to meddle with the make files and build files and this complication is not worth the trouble and adds no value IMO. Binary distributions ------------------------------------ +1 on having separate builds for brokers, clients and management tools when ever it makes sense. I have been advocating this for a while now. How ever as Aidan points out, for c++ its best we restrict our selves to providing binaries for windows only. For the various linux flavours it would be best to allow the respective communities to provide these binaries. A huge +1 for providing a downloadable example package with some good documentation. To make it easy these examples should be source with clear instructions on how to build them. The current set of interoperable examples across all languages are the best place to start. Regards, Rajith On Wed, Feb 18, 2009 at 11:41 AM, Martin Ritchie <[email protected]> wrote: > 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] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
