activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
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.

Bruce

On Wed, Sep 12, 2012 at 2:34 AM, Claus Ibsen <claus.ibsen@gmail.com> 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: cibsen@fusesource.com
> 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

Mime
View raw message