You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2013/05/10 09:24:51 UTC
Discuss: How to handle incompatibility in Karaf 3 shell
There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
It is described in the two issues below:
https://issues.apache.org/jira/browse/KARAF-2307
https://issues.apache.org/jira/browse/AMQ-4492
In fact it is two issues:
1. The package org.apache.felix.gogo.commands.basic was moved to
org.apache.karaf.shell.commands.basic.
2. The package org.apache.karaf.shell.console is now at version 3.0.0
which is incompatible to the range of [2,3) ActiveMQ imports.
So for the issue 1 we have two options:
a. Create the new package in upcoming 2.x versions.
+ We a clean state in Karaf 3 with the old package removed. The
problem is that as soon as
- ActiveMQ switches it will not work with older 2.x versions anymore.
b. Create the old package in Karaf 3
+ All present versions of ActiveMQ will still work
- As soon as ActiveMQ switches it will not be compatible with Karaf
2.x anymore
- Karaf 3 contains old packages while it should clean up these things
in a major release
There is also the option to create old and new packages in Karaf 2.x and
3 so ActiveMQ will work in both versions.
We then later have too remove to old package for karaf 3 at some point.
The issue 2 is less dramatic as it can be fixed by a wider import of the
package version in ActiveMQ. Still I wonder if we could do better here.
For API packages we could version each package separately so as long as
a package is incompatible it could still report the old version which would
make it more compatible. This can be handled with a package info file in
the package like in the OSGi specs.
So in any case I think this shows we should have a good concept for
package versioning for API packages.
What do you think?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Discuss: How to handle incompatibility in Karaf 3 shell
Posted by Christian Schneider <ch...@die-schneider.net>.
The problem with the ActiveMQ commands is that they do a kind of generic
translation from the ActiveMQ console commands to karaf commands.
So they make extensive use of classes in
org.apache.felix.gogo.commands.basic.
In camel and cxf we were able to simply not use the commands.basic
package. So it was easier there.
This of course brings up another problem with the current karaf command
API. It exposes impl classes which you have to use and so couples the
user quite closely to our implementation. In the long run I would like
to replace that with an API with less coupling. This may be a good
feature for later Karaf 3 versions. For now though we can not change
that part.
Christian
Am 10.05.2013 10:34, schrieb Ioannis Canellos:
> I've raised the same concerns a couple of months ago.
>
> The answer I got back then is that there is a way to make commands be
> compatible with both 2.x and 3.x.
> I think that camel commands already are and they do so by declaring the
> gogo package as private (not 100% sure, I'll have to check)
>
> On Fri, May 10, 2013 at 10:24 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
>> It is described in the two issues below:
>> https://issues.apache.org/**jira/browse/KARAF-2307<https://issues.apache.org/jira/browse/KARAF-2307>
>> https://issues.apache.org/**jira/browse/AMQ-4492<https://issues.apache.org/jira/browse/AMQ-4492>
>>
>> In fact it is two issues:
>> 1. The package org.apache.felix.gogo.**commands.basic was moved to
>> org.apache.karaf.shell.**commands.basic.
>> 2. The package org.apache.karaf.shell.console is now at version 3.0.0
>> which is incompatible to the range of [2,3) ActiveMQ imports.
>>
>> So for the issue 1 we have two options:
>> a. Create the new package in upcoming 2.x versions.
>> + We a clean state in Karaf 3 with the old package removed. The problem
>> is that as soon as
>> - ActiveMQ switches it will not work with older 2.x versions anymore.
>> b. Create the old package in Karaf 3
>> + All present versions of ActiveMQ will still work
>> - As soon as ActiveMQ switches it will not be compatible with Karaf 2.x
>> anymore
>> - Karaf 3 contains old packages while it should clean up these things in
>> a major release
>>
>> There is also the option to create old and new packages in Karaf 2.x and 3
>> so ActiveMQ will work in both versions.
>> We then later have too remove to old package for karaf 3 at some point.
>>
>> The issue 2 is less dramatic as it can be fixed by a wider import of the
>> package version in ActiveMQ. Still I wonder if we could do better here.
>> For API packages we could version each package separately so as long as a
>> package is incompatible it could still report the old version which would
>> make it more compatible. This can be handled with a package info file in
>> the package like in the OSGi specs.
>>
>> So in any case I think this shows we should have a good concept for
>> package versioning for API packages.
>>
>> What do you think?
>>
>> Christian
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Discuss: How to handle incompatibility in Karaf 3 shell
Posted by Ioannis Canellos <io...@gmail.com>.
I've raised the same concerns a couple of months ago.
The answer I got back then is that there is a way to make commands be
compatible with both 2.x and 3.x.
I think that camel commands already are and they do so by declaring the
gogo package as private (not 100% sure, I'll have to check)
On Fri, May 10, 2013 at 10:24 AM, Christian Schneider <
chris@die-schneider.net> wrote:
> There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
> It is described in the two issues below:
> https://issues.apache.org/**jira/browse/KARAF-2307<https://issues.apache.org/jira/browse/KARAF-2307>
> https://issues.apache.org/**jira/browse/AMQ-4492<https://issues.apache.org/jira/browse/AMQ-4492>
>
> In fact it is two issues:
> 1. The package org.apache.felix.gogo.**commands.basic was moved to
> org.apache.karaf.shell.**commands.basic.
> 2. The package org.apache.karaf.shell.console is now at version 3.0.0
> which is incompatible to the range of [2,3) ActiveMQ imports.
>
> So for the issue 1 we have two options:
> a. Create the new package in upcoming 2.x versions.
> + We a clean state in Karaf 3 with the old package removed. The problem
> is that as soon as
> - ActiveMQ switches it will not work with older 2.x versions anymore.
> b. Create the old package in Karaf 3
> + All present versions of ActiveMQ will still work
> - As soon as ActiveMQ switches it will not be compatible with Karaf 2.x
> anymore
> - Karaf 3 contains old packages while it should clean up these things in
> a major release
>
> There is also the option to create old and new packages in Karaf 2.x and 3
> so ActiveMQ will work in both versions.
> We then later have too remove to old package for karaf 3 at some point.
>
> The issue 2 is less dramatic as it can be fixed by a wider import of the
> package version in ActiveMQ. Still I wonder if we could do better here.
> For API packages we could version each package separately so as long as a
> package is incompatible it could still report the old version which would
> make it more compatible. This can be handled with a package info file in
> the package like in the OSGi specs.
>
> So in any case I think this shows we should have a good concept for
> package versioning for API packages.
>
> What do you think?
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: Discuss: How to handle incompatibility in Karaf 3 shell
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yup, I saw that.
I will take a look tonight or tomorrow morning in it's possible to avoid
to depend to gogo.commands.basic in ActiveMQ (I don't understand why it
would be required).
It's the impact is important, I will add gogo.commands.basic in the
karaf.shell.console for transition purpose.
Thanks !
Regards
JB
On 05/16/2013 12:28 PM, Christian Schneider wrote:
> Hi JB,
>
> ActiveMQ also needs the package org.apache.felix.gogo.commands.basic
> which is currently
> not available in karaf 3. So we either need to make ActiveMQ independent
> of this package or
> we need to provide it in some way.
>
> Christian
>
> Am 16.05.2013 10:39, schrieb Jean-Baptiste Onofré:
>> Christian,
>>
>> I started to check the ActiveMQ commands and I don't get your point ;)
>>
>> FYI, on Karaf trunk (so 3.0.x), for backward compatibility, the felix
>> package is there in shell/console:
>>
>> http://svn.apache.org/repos/asf/karaf/trunk/shell/console/src/main/java/org/apache/
>>
>>
>> So, I think that we should just update the import package correctly
>> and check the POM on the ActiveMQ side.
>>
>> Regards
>> JB
>>
>> On 05/10/2013 09:24 AM, Christian Schneider wrote:
>>> There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
>>> It is described in the two issues below:
>>> https://issues.apache.org/jira/browse/KARAF-2307
>>> https://issues.apache.org/jira/browse/AMQ-4492
>>>
>>> In fact it is two issues:
>>> 1. The package org.apache.felix.gogo.commands.basic was moved to
>>> org.apache.karaf.shell.commands.basic.
>>> 2. The package org.apache.karaf.shell.console is now at version 3.0.0
>>> which is incompatible to the range of [2,3) ActiveMQ imports.
>>>
>>> So for the issue 1 we have two options:
>>> a. Create the new package in upcoming 2.x versions.
>>> + We a clean state in Karaf 3 with the old package removed. The
>>> problem is that as soon as
>>> - ActiveMQ switches it will not work with older 2.x versions anymore.
>>> b. Create the old package in Karaf 3
>>> + All present versions of ActiveMQ will still work
>>> - As soon as ActiveMQ switches it will not be compatible with Karaf
>>> 2.x anymore
>>> - Karaf 3 contains old packages while it should clean up these things
>>> in a major release
>>>
>>> There is also the option to create old and new packages in Karaf 2.x and
>>> 3 so ActiveMQ will work in both versions.
>>> We then later have too remove to old package for karaf 3 at some point.
>>>
>>> The issue 2 is less dramatic as it can be fixed by a wider import of the
>>> package version in ActiveMQ. Still I wonder if we could do better here.
>>> For API packages we could version each package separately so as long as
>>> a package is incompatible it could still report the old version which
>>> would
>>> make it more compatible. This can be handled with a package info file in
>>> the package like in the OSGi specs.
>>>
>>> So in any case I think this shows we should have a good concept for
>>> package versioning for API packages.
>>>
>>> What do you think?
>>>
>>> Christian
>>>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Discuss: How to handle incompatibility in Karaf 3 shell
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi JB,
ActiveMQ also needs the package org.apache.felix.gogo.commands.basic
which is currently
not available in karaf 3. So we either need to make ActiveMQ independent
of this package or
we need to provide it in some way.
Christian
Am 16.05.2013 10:39, schrieb Jean-Baptiste Onofré:
> Christian,
>
> I started to check the ActiveMQ commands and I don't get your point ;)
>
> FYI, on Karaf trunk (so 3.0.x), for backward compatibility, the felix
> package is there in shell/console:
>
> http://svn.apache.org/repos/asf/karaf/trunk/shell/console/src/main/java/org/apache/
>
>
> So, I think that we should just update the import package correctly
> and check the POM on the ActiveMQ side.
>
> Regards
> JB
>
> On 05/10/2013 09:24 AM, Christian Schneider wrote:
>> There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
>> It is described in the two issues below:
>> https://issues.apache.org/jira/browse/KARAF-2307
>> https://issues.apache.org/jira/browse/AMQ-4492
>>
>> In fact it is two issues:
>> 1. The package org.apache.felix.gogo.commands.basic was moved to
>> org.apache.karaf.shell.commands.basic.
>> 2. The package org.apache.karaf.shell.console is now at version 3.0.0
>> which is incompatible to the range of [2,3) ActiveMQ imports.
>>
>> So for the issue 1 we have two options:
>> a. Create the new package in upcoming 2.x versions.
>> + We a clean state in Karaf 3 with the old package removed. The
>> problem is that as soon as
>> - ActiveMQ switches it will not work with older 2.x versions anymore.
>> b. Create the old package in Karaf 3
>> + All present versions of ActiveMQ will still work
>> - As soon as ActiveMQ switches it will not be compatible with Karaf
>> 2.x anymore
>> - Karaf 3 contains old packages while it should clean up these things
>> in a major release
>>
>> There is also the option to create old and new packages in Karaf 2.x and
>> 3 so ActiveMQ will work in both versions.
>> We then later have too remove to old package for karaf 3 at some point.
>>
>> The issue 2 is less dramatic as it can be fixed by a wider import of the
>> package version in ActiveMQ. Still I wonder if we could do better here.
>> For API packages we could version each package separately so as long as
>> a package is incompatible it could still report the old version which
>> would
>> make it more compatible. This can be handled with a package info file in
>> the package like in the OSGi specs.
>>
>> So in any case I think this shows we should have a good concept for
>> package versioning for API packages.
>>
>> What do you think?
>>
>> Christian
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Discuss: How to handle incompatibility in Karaf 3 shell
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Christian,
I started to check the ActiveMQ commands and I don't get your point ;)
FYI, on Karaf trunk (so 3.0.x), for backward compatibility, the felix
package is there in shell/console:
http://svn.apache.org/repos/asf/karaf/trunk/shell/console/src/main/java/org/apache/
So, I think that we should just update the import package correctly and
check the POM on the ActiveMQ side.
Regards
JB
On 05/10/2013 09:24 AM, Christian Schneider wrote:
> There is still a compatibility issuue in Karaf 3 with at least ActiveMQ.
> It is described in the two issues below:
> https://issues.apache.org/jira/browse/KARAF-2307
> https://issues.apache.org/jira/browse/AMQ-4492
>
> In fact it is two issues:
> 1. The package org.apache.felix.gogo.commands.basic was moved to
> org.apache.karaf.shell.commands.basic.
> 2. The package org.apache.karaf.shell.console is now at version 3.0.0
> which is incompatible to the range of [2,3) ActiveMQ imports.
>
> So for the issue 1 we have two options:
> a. Create the new package in upcoming 2.x versions.
> + We a clean state in Karaf 3 with the old package removed. The
> problem is that as soon as
> - ActiveMQ switches it will not work with older 2.x versions anymore.
> b. Create the old package in Karaf 3
> + All present versions of ActiveMQ will still work
> - As soon as ActiveMQ switches it will not be compatible with Karaf
> 2.x anymore
> - Karaf 3 contains old packages while it should clean up these things
> in a major release
>
> There is also the option to create old and new packages in Karaf 2.x and
> 3 so ActiveMQ will work in both versions.
> We then later have too remove to old package for karaf 3 at some point.
>
> The issue 2 is less dramatic as it can be fixed by a wider import of the
> package version in ActiveMQ. Still I wonder if we could do better here.
> For API packages we could version each package separately so as long as
> a package is incompatible it could still report the old version which would
> make it more compatible. This can be handled with a package info file in
> the package like in the OSGi specs.
>
> So in any case I think this shows we should have a good concept for
> package versioning for API packages.
>
> What do you think?
>
> Christian
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com