karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Versioning of command apis
Date Thu, 14 Nov 2013 13:12:17 GMT
+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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message