Hi Martin, Great to see this discussion kicking off.
I pretty much agree with your suggestions, with my main focus being the Java packages. Our last rel shipped a truly vast one size fits all - I think what you've proposed is far better for user experience. Regards, Marnie On Wed, Feb 18, 2009 at 4:41 PM, 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] > >
