I should clarify my statement, I can totally see why you would take it that way from what I said.
It wouldn't bother me at all to ship a bundle; I just meant not the one we ship now :) A tar of self-contained modules for example would be great for those that want to get a package of bits that work together. Then for anyone who just wants e.g. the Java client to use with their C++ broker or vice versa we simply tar the modules individually. I'm just not a fan of having the bundle tar end up with one lib folder containing something like 50 jars in it and adding the whole lot to the class path. That just leads to issues such as log4j wondering off and picking up configuration from the wrong jars (the broker for example used to pick up other log4j configurations from the client/qman/test/whatever jars as well as the etc/log4j.xml file until I stopped it doing so) or new versions of Xalan unexpectedly interacting with the old ones Sun ship in the JVM as has happened on a few occasions. It also doesn't help when it gets you a bunch of stuff you can't even use together (e.g. in 0.6, QMan and the Java broker which are totally incompatible but ship in the same bundle; that's not exactly helpful to our users). We discussed changing these things 3+ months ago, id suggest we all chime in now and see if we can agree on something better that so we can start getting round to it before we end up on the doorstep of the next release and have to put it off again :) Robbie > -----Original Message----- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 08 March 2010 20:16 > To: dev@qpid.apache.org > Subject: Re: Java Client Logging (yet again !) > > Robbie Gemmell wrote: > >> 3. From the next release we need to ship separate binaries for the > >> broker, client and management bits. > > > > We already do release separate bundles for pretty much everything > (Client, > > Broker, QMan[management-client], and JMX Management Consoles). From > the next > > release I would suggest that we stop shipping the 'java bundle' > binary which > > mashes most of those contents together. > > I'm not really a big fan of not shipping the bundle. > > I think users who OEM the client want to clearly understand what it's > dependencies are and obviously want them as minimal as possible, and I > certainly think this is an important usage scenario to accommodate, > however I think a large part of that can be achieved without having a > client-only download, and I think it's important to recognize that it's > not our only usage scenario. > > Now I'm not really against having a client only download, but I do > think > the bundle should be kept, and in fact should really be thought of as > the primary download for the simple reason that a client-only download > is actually quite useless to most of our prospective users because you > can't actually do anything useful with the client unless you have a > broker somewhere, and even then I doubt you'll get very far without > some > management tools for simple diagnostics. > > Contrast this to a download that includes the broker, the client, some > basic diagnostic/management tools, and some working examples, and I > think our potential users will have a much nicer out-of-the-box > experience with a bundle. > > Granted our current bundle needs some work to live up to this, but > I don't think that's a reason to throw the baby out with the bathwater. > > --Rafael > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
