activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: [DISCUSS] - Reduce dependency in activemq-core
Date Tue, 18 Sep 2012 17:39:53 GMT
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.


On Wed, Sep 12, 2012 at 2:34 AM, Claus Ibsen <> 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
> 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:
> Web:
> Twitter: davsclaus, fusenews
> Blog:
> Author of Camel in Action:

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:

View raw message