activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <de...@nighttale.net>
Subject Re: [DISCUSS] - Reduce dependency in activemq-core
Date Wed, 12 Sep 2012 09:36:46 GMT
+100

We definitely should start moving into that direction. There's to much
stuff in activemq-core at the moment and the main problem is xbean
generation as you mentioned. If we sort that for 5.8 we can remove all
spring stuff out of it and also move separate stores, plugins and
stuff to their own modules.

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

FTP is used for blob support and I think we can move that

> 5)
> Somehow activemq-core has dependency to Jettison. I cannot see a
> reason why. Anyone ?

Jettison is used for Stomp JSON support (along with XStream). That's
overdue for revisiting as well.

Regards
-- 
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Wed, Sep 12, 2012 at 10: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

Mime
View raw message