karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: Versioning of command apis
Date Thu, 14 Nov 2013 12:36:40 GMT
+1 on getting a clean API separated out from implementation and helper
classes. Once that API is there we can nicely apply semantic
versioning on it, which should make life a lot easier for people
implementing commands.

Just FYI - the bndtools.org project has recently made a lot of
progress in providing tools that tell you when you need to update your
versions to comply with OSGi semantic versioning. Although it's not
been used in anger in under Maven yet, Maven support has been in the
works for a while and I think it would be good if we could start using

Just my 2c,


On 14 November 2013 09:21, Christian Schneider <chris@die-schneider.net> 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
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> http://www.talend.com

View raw message