I am definitely in favor of this effort, Claus. Nice to see that someone is going to trim it down finally, this is long overdue.
Bruce On Wed, Sep 12, 2012 at 2:34 AM, Claus Ibsen <[email protected]> wrote: > Hi > > I have also been looking a bit on activemq-core, and the many JAR > dependencies it currently has. > Currently we have a mix of mandatory and optional JARs. > > I suggest we work towards reducing this and moving pieces from the > core, into separate maven modules. > > 1) > For example the MQTT client could possible fit in a new activemq-mqtt module. > > 2) > Also there is a org.apache.activemq.util.XStreamFactoryBean that is > only used for an unit test. > I dont think its acitvemq-core business to have Spring factory beans > for the XStream library. That is either Spring or XStream business, > not ActiveMQ. I suggest to remove this dependency from the core. End > users can create their own factory bean or use some other way. > > 3) > LevelDB store. This is a bit more tricky. The implementation of the > store is in a separate module at > org.fusesource.mq.leveldb.LevelDBStore. But there is an adapter in the > activemq-core source code. > > * > * @org.apache.xbean.XBean element="levelDB" > * > */ > public class LevelDBPersistenceAdapter extends LevelDBStore { > } > > As you can see it used XBean to generate it into the broker schema file. > > I wonder if we can come up with some may in the future to make this > more separated. So we can have "shallow" adapters in the > activemq-core, but that is not tied at compile time to the > implementation. This is how we do it in Camel, with for example > DataFormats (they get generated in the Camel XSD schema, but is not > runtime tied to the camel-core). > > Ah look at the JDBC store, they have some FactoryFinder to find the > impl. Maybe we can use that for LevelDB? > > This would allow us then to move the levelDB store to a > activemq-leveldb module, and therefore untie the activemq-core from > this. > > > 4) > There is also the FTP support which uses commons net. We could > consider moving that into a separate module as well. > > 5) > Somehow activemq-core has dependency to Jettison. I cannot see a > reason why. Anyone ? > > > > Sorry if I go overboard, but I want to make activemq-core a leaner > module. So its easier for people to slice and dice to use what they > need. And to make AMQ more appealing for users (eg its fewer JARs) > with plugin/optional features they can choose a la carte. > > This also makes OSGi easier as today we got a bunch of optional OSGi > imports in the MANIFEST.MF of the activemq-core; this is not ideal. > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen -- perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
