karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Versioning of command apis
Date Thu, 14 Nov 2013 09:21:11 GMT
As you all know we had and still some compatibility problems with 
bundles that implement commands externally from karaf. CXF and Camel 
work now but ActiveMQ still does not work with karaf 3.

There are two kinds of problems that appear with the switch to karaf 3.

1. We moved the classes from org.apache.felix.gogo.commands and 
org.apache.felix.gogo.commands.basic to org.apache.karaf.shell.commands 
and org.apache.karaf.shell.commands.basic.
2. The org.apache.karaf.shell.console package and subpackages are 
exported as version 3.0.0 now which is by default incompatible with auto 
generated import ranges.

For problem 1 we created deprecated old classes at the old place which 
allows people to migrate.
For problem 2 all external command bundles need to increase their import 
range to include 3.x. The problem will reappear with version 4.

I just discussed with Achim on irc what to do and we agreed that for 
problem 2 a much better solution would be to introduce a versioning on 
package level. This requires a lot more care and effort than what we now 
do though.

So my question is. Should we start versioning at least this api on 
package level and what rules should be in place to make sure it works?

When I look into the packages from shell.console I think that these are 
not real api packages as of now. They contain some classes that rather 
qualify as implementation like AbstractAction and 
DefaultActionPreparator as they contain much code. At the moment these 
packages can not be split easily from the minimal api we need to 
provide. So I am not sure if we are already at a stage were we can do 
good api versioning. So I wonder if we perhaps keep the api mostly 
unchanged for karaf 3 and do a bigger redesign of the command apis for 
karaf 4.

If we decide to go this way it would be more consistent to revert the 
move of the classes described in problem 1. This would then make sure 
that users of karaf commands only need to do the change once. For 
problem 2 we might simply define one fixed export version for command 
apis in karaf 3.x like (2.3.0). This version would be compatible to old 
external commands and we could use the same version for karaf 2.x 
starting with 2.4. So we would stay very compatible for now and spare 
the real changes for karaf 4. We could start these changes in a kind of 
preview api in karaf 3.x and formalize it at some point which would then 
become the karaf 4 command api.

What do you think?


Christian Schneider

Open Source Architect

View raw message