activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject [DISCUSS] - Reduce dependency in activemq-core
Date Wed, 12 Sep 2012 08:34:21 GMT

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.

For example the MQTT client could possible fit in a new activemq-mqtt module.

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.

LevelDB store. This is a bit more tricky. The implementation of the
store is in a separate module at 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

There is also the FTP support which uses commons net. We could
consider moving that into a separate module as well.

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
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message