You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/09/12 10:34:21 UTC
[DISCUSS] - Reduce dependency in activemq-core
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
Re: [DISCUSS] - Reduce dependency in activemq-core
Posted by Bruce Snyder <br...@gmail.com>.
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 <cl...@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
Re: [DISCUSS] - Reduce dependency in activemq-core
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have logged a ticket so we wont forget about this. And scheduled it
for AMQ 5.8 release.
https://issues.apache.org/jira/browse/AMQ-4055
On Wed, Sep 12, 2012 at 11:48 AM, Dejan Bosanac <de...@nighttale.net> wrote:
> Yup. When this was written, Jettison was the only choice.
>
>
> 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 11:43 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> On Wed, Sep 12, 2012 at 11:36 AM, Dejan Bosanac <de...@nighttale.net> wrote:
>>> +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.
>>>
>>
>> Maybe we should stick with one JSON library like Jackson. That is a
>> very popular library and fast.
>>
>> There is also gson
>> https://code.google.com/p/google-gson/
>>
>>
>>> 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 <cl...@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
>>
>>
>>
>> --
>> 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
--
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
Re: [DISCUSS] - Reduce dependency in activemq-core
Posted by Dejan Bosanac <de...@nighttale.net>.
Yup. When this was written, Jettison was the only choice.
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 11:43 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 11:36 AM, Dejan Bosanac <de...@nighttale.net> wrote:
>> +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.
>>
>
> Maybe we should stick with one JSON library like Jackson. That is a
> very popular library and fast.
>
> There is also gson
> https://code.google.com/p/google-gson/
>
>
>> 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 <cl...@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
>
>
>
> --
> 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
Re: [DISCUSS] - Reduce dependency in activemq-core
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Sep 12, 2012 at 11:36 AM, Dejan Bosanac <de...@nighttale.net> wrote:
> +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.
>
Maybe we should stick with one JSON library like Jackson. That is a
very popular library and fast.
There is also gson
https://code.google.com/p/google-gson/
> 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 <cl...@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
--
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
Re: [DISCUSS] - Reduce dependency in activemq-core
Posted by Dejan Bosanac <de...@nighttale.net>.
+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 <cl...@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