Here are some thoughts on what could be externalized:
* core (used by both the broker and client)
* broker
* client
* pool
* camel
* stores
* transports ..
I suppose we could keep backward compatibility by recreating an activemq-core
that would include all these modules.
On Thu, Feb 21, 2008 at 5:24 PM, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 8, 2008 at 4:28 AM, Tuomas Kiviaho <[EMAIL PROTECTED]> wrote:
> >
> > Has there been any plans to fine grain activemq-core based on optional
> > dependencies.
> >
> > -Separate library dedicated for a third party dependency would make it
> > possible to have activemq-core in parent classloader relative to for
> > instance activemq-spring.
> > -Removal of now obsolete dependencies from activemq-core pom.xml would
> > remove the need for explicit exclusions.
> > -No more NoClassDefFoundErrors caused by missing optional dependencies
> >
> > This would ease out especially embedding which I found out to be quite a
> > trial-and-error iteration process on already existing system which uses
> same
> > dependencies as activemq-core. On the other hand overall complexity would
> be
> > increased.
>
> +1 I'd like to see the core slimmed down to only required items and
> push all the optional items out to the optional module.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
> PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
>
> Blog: http://bruceblog.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/