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é <[email protected]>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é > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
