Hi JB,
ActiveMQ also needs the package org.apache.felix.gogo.commands.basic
which is currently
not available in karaf 3. So we either need to make ActiveMQ independent
of this package or
we need to provide it in some way.
Christian
Am 16.05.2013 10:39, schrieb Jean-Baptiste Onofré:
Christian,
I started to check the ActiveMQ commands and I don't get your point ;)
FYI, on Karaf trunk (so 3.0.x), for backward compatibility, the felix
package is there in shell/console:
http://svn.apache.org/repos/asf/karaf/trunk/shell/console/src/main/java/org/apache/
So, I think that we should just update the import package correctly
and check the POM on the ActiveMQ side.
Regards
JB
On 05/10/2013 09:24 AM, Christian Schneider 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/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
