+1 and -1
+1 for have a clean API and externalized, with a cleaner versioning for
Karaf 4.
-1 to revert the move that we did in Karaf 3. We did this move 1 year
before, it gives time to test and move for the other projects. I'm not
OK to move now, at 1 week for Karaf 3.0.0. We released Karaf 3.0.0.RC1
like this. I'm fully OK to add a backward compatible module, to easily
migrate, but not to revert.
Regards
JB
On 11/14/2013 10:21 AM, Christian Schneider wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
