karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Versioning of command apis
Date Thu, 14 Nov 2013 13:17:21 GMT
For the API externalisation: +1; BUT really externalized. Which means only
in a different project. Otherwise it could get quite interesting if e.g. we
need to release something differently in the 2.x branches.

For the second point I'm completely with JB (-1)

Kind regards,
Andreas


On Thu, Nov 14, 2013 at 2:12 PM, Jean-Baptiste Onofré <jb@nanthrax.net>wrote:

> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message