Since the plan would be to deprecate the plugin first (like we did with leveldb) then I guess that means it would still stick around for 5.15.0 so we still need an upgrade path for Camel 2.18.x and we need to fix the OSGi integration. I think the first step will be to embed the xbean library (maybe the activemq-spring project) and look for a better approach in the future.
On Wed, Feb 8, 2017 at 5:07 AM, Claus Ibsen <[email protected]> wrote: > On Wed, Feb 8, 2017 at 9:59 AM, Claus Ibsen <[email protected]> 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) > > For the broker component you can likely just use a Camel XML file and > use Camel routes to do the same as the broker component can do. > > And there hasn't been too many users of it so far, but a few have been > doing so. And if they can migrate to using plain Camel routes then it > makes sense to deprecate it too. > > So let me change to +1 > > > > +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 > >> > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 >
