Hi Claus,
I think there is a deeper problem to this. Camel does not have a small
and stable API. So anything that integrates deeply with camel like the
activemq camel component or the camel plugin are kind of coupled to a
certain camel release. If anything bigger is changed in camel it will
break. So I think it is more logical to move such things to camel.
Of course the activemq camel plugin is also coupled to activemq which
makes it especially problematic. This is why I am in favour of retiring
it. I think almost all of its functionality can be also implemented
using camel outside of the broker (Either in the same process or
outside). If we keep it we must make sure the coupling is minimal. I do
not know much of the inner workings of it but I can imagine it is very
difficult to decouple the camel plugin from changes in camel.
In long term keeping the projects as separate as possible will make sure
they can evolve at their own pace.
Christian
On 08.02.2017 09:59, Claus Ibsen wrote:
On Tue, Feb 7, 2017 at 11:38 AM, Christian Schneider
<[email protected]> wrote:
There are some issues supporting the new camel version 2.18.x in activemq.
See
https://issues.apache.org/jira/browse/AMQ-6585
I think this ticket surfaces a problem in ActiveMQ about its OSGi
code/stuff being problematic. That its xbean stuff is causing more
pain than good. I wonder if ActiveMQ should consider a different
approach for those xml file configurations to work without xbean or
make it work for OSGi.
Moving activemq-camel to Apache Camel moves the dependency problem to
Camel. However as Camel uses ActiveMQ for testing camel-jms we already
use AMQ, so it may be less of a problem there.
Also it allows activme-camel to be released together with Camel and
benefit from new functionality from Camel being released together.
And we could potentially make activemq-camel (to be renamed to
camel-activemq) just reuse all the unit tests from camel-jms so we
dont have to write any tests and just let it be an optimized camel-jms
component which it really is.
In the issue we discussed that it would be better to have the activemq camel
component in the camel project. There is also the question about the camel
plugin for the broker. I do not know any users who use camel inside the
activemq broker. So the proposal here is to deprecate and remove the plugin
at some point.
There are some community users that uses the Camel broker component.
I dont yet think it should be deprecated. It allows functionality that
there is not in ActiveMQ.
And ActiveMQ ships with Camel and Camel and AMQ together is a great combination.
If both are removed from activemq source then managing the dependencies is a
lot easier.
I frankly think its the OSGi pain that is causing this. If AMQ just
works on OSGi then this wouldn't be a problem in the first place.
-0 to broker (need more feedback from community and others)
+1 to activemq-camel (however need to see how bad/good this is and
allow to revert the decision if it causes to much pain)
What do you think?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
