I've raised the same concerns a couple of months ago. The answer I got back then is that there is a way to make commands be compatible with both 2.x and 3.x. I think that camel commands already are and they do so by declaring the gogo package as private (not 100% sure, I'll have to check)
On Fri, May 10, 2013 at 10:24 AM, Christian Schneider < [email protected]> wrote: > There is still a compatibility issuue in Karaf 3 with at least ActiveMQ. > It is described in the two issues below: > https://issues.apache.org/**jira/browse/KARAF-2307<https://issues.apache.org/jira/browse/KARAF-2307> > https://issues.apache.org/**jira/browse/AMQ-4492<https://issues.apache.org/jira/browse/AMQ-4492> > > In fact it is two issues: > 1. The package org.apache.felix.gogo.**commands.basic was moved to > org.apache.karaf.shell.**commands.basic. > 2. The package org.apache.karaf.shell.console is now at version 3.0.0 > which is incompatible to the range of [2,3) ActiveMQ imports. > > So for the issue 1 we have two options: > a. Create the new package in upcoming 2.x versions. > + We a clean state in Karaf 3 with the old package removed. The problem > is that as soon as > - ActiveMQ switches it will not work with older 2.x versions anymore. > b. Create the old package in Karaf 3 > + All present versions of ActiveMQ will still work > - As soon as ActiveMQ switches it will not be compatible with Karaf 2.x > anymore > - Karaf 3 contains old packages while it should clean up these things in > a major release > > There is also the option to create old and new packages in Karaf 2.x and 3 > so ActiveMQ will work in both versions. > We then later have too remove to old package for karaf 3 at some point. > > The issue 2 is less dramatic as it can be fixed by a wider import of the > package version in ActiveMQ. Still I wonder if we could do better here. > For API packages we could version each package separately so as long as a > package is incompatible it could still report the old version which would > make it more compatible. This can be handled with a package info file in > the package like in the OSGi specs. > > So in any case I think this shows we should have a good concept for > package versioning for API packages. > > What do you think? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
