You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Raul Kripalani (JIRA)" <ji...@apache.org> on 2012/05/23 13:26:41 UTC
[jira] [Updated] (KARAF-1497) Capability to alter versions in
features and bundles
[ https://issues.apache.org/jira/browse/KARAF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Raul Kripalani updated KARAF-1497:
----------------------------------
Description:
OSGi offers a solid solution to the legendary problem of {{dependency hell}} in Java, through the use of explicit version numbers and version ranges in MANIFESTs.
Unfortunately, it requires a lot of developer re-education to understand how to use version ranges their library bundles. It's common to find bundles with too narrow version ranges or fixed version numbers. In the real world of Open Source, not everyone is fully conscious of OSGi concepts and the impact of version numbers.
The maven-bundle-plugin expresses imports with version ranges by default, which takes much of the problem away.
In practice, we may know that a bundle X even though importing package A with fixed version 1.2, it will work reliably with version 1.3 of package A. Right now, I think that our only way out is to repackage the bundle altering the MANIFEST.
It'd be neat if Karaf provides functionality to *alter/re-adjust/correct* version definitions for package imports in bundles.
Moreover, we should be able to alter versions in bundle and feature references from within Karaf features.
The latter helps tremendously in the inter-connected world of Open Source, where, for example, Camel and AMQ are using one another, are grouped in ServiceMix and CXF also uses them!
Imagine the following scenario, testing Camel 2.10-SNAPSHOT on Karaf (provided that the correct feature repos are registered):
{code}
> feature:install camel/2.10-SNAPSHOT
> feature:install activemq/5.6.0
> feature:install activemq-camel/5.6.0
{code}
The last instruction complains that camel-jms/2.9.2 is not found. Wouldn't it be awesome if the user could alter the feature definition from within the shell to reference camel-jms/2.10-SNAPSHOT, instead of tampering with the local features descriptor and refreshing it?
In my head, the command would look like:
{code}
> feature:edit activemq-camel/5.6.0
> feature:version-alter --feature camel-jms [2.9.2,2.10]
> feature:update
{code}
(resembling the config shell constructs)
was:
OSGi offers a solid solution to the legendary problem of {{dependency hell}} in Java, through the use of explicit version numbers and version ranges in MANIFESTs.
Unfortunately, it requires a lot of developer re-education to understand how to use version ranges their library bundles. It's common to find bundles with too narrow version ranges or fixed version numbers. In the real world of Open Source, not everyone is fully conscious of OSGi concepts and the impact of version numbers.
The maven-bundle-plugin expresses imports with version ranges by default, which takes much of the problem away.
In practice, we may know that a bundle X even though importing package A with fixed version 1.2, it will work reliably with version 1.3 of package A. Right now, I think that our only way out is to repackage the bundle altering the MANIFEST.
It'd be neat if Karaf provides functionality to *alter/re-adjust/correct* version definitions for package imports in bundles.
Moreover, we should be able to alter versions in bundle and feature references from within Karaf features.
The latter helps tremendously in the inter-connected world of Open Source, where, for example, Camel and AMQ are using one another, are grouped in ServiceMix and CXF also uses them!
Imagine the following scenario, testing Camel 2.10-SNAPSHOT on Karaf (provided that the correct feature repos are registered):
{code}
> feature:install camel/2.10-SNAPSHOT
> feature:install activemq/5.6.0
> feature:install activemq-camel/5.6.0
{code}
The last instruction complains that camel-jms/2.9.2 is not found. Wouldn't it be awesome if the user could alter the feature definition from within the shell to reference camel-jms/2.10-SNAPSHOT, instead of tampering with the local features descriptor and refreshing it?
In my head, the command would look like:
{code}
> feature:edit activemq-camel/5.6.0
> feature:version-alter --feature camel-jms [2.9.2,2.10]
{code}
> Capability to alter versions in features and bundles
> ----------------------------------------------------
>
> Key: KARAF-1497
> URL: https://issues.apache.org/jira/browse/KARAF-1497
> Project: Karaf
> Issue Type: New Feature
> Affects Versions: 2.2.7
> Reporter: Raul Kripalani
>
> OSGi offers a solid solution to the legendary problem of {{dependency hell}} in Java, through the use of explicit version numbers and version ranges in MANIFESTs.
> Unfortunately, it requires a lot of developer re-education to understand how to use version ranges their library bundles. It's common to find bundles with too narrow version ranges or fixed version numbers. In the real world of Open Source, not everyone is fully conscious of OSGi concepts and the impact of version numbers.
> The maven-bundle-plugin expresses imports with version ranges by default, which takes much of the problem away.
> In practice, we may know that a bundle X even though importing package A with fixed version 1.2, it will work reliably with version 1.3 of package A. Right now, I think that our only way out is to repackage the bundle altering the MANIFEST.
> It'd be neat if Karaf provides functionality to *alter/re-adjust/correct* version definitions for package imports in bundles.
> Moreover, we should be able to alter versions in bundle and feature references from within Karaf features.
> The latter helps tremendously in the inter-connected world of Open Source, where, for example, Camel and AMQ are using one another, are grouped in ServiceMix and CXF also uses them!
> Imagine the following scenario, testing Camel 2.10-SNAPSHOT on Karaf (provided that the correct feature repos are registered):
> {code}
> > feature:install camel/2.10-SNAPSHOT
> > feature:install activemq/5.6.0
> > feature:install activemq-camel/5.6.0
> {code}
> The last instruction complains that camel-jms/2.9.2 is not found. Wouldn't it be awesome if the user could alter the feature definition from within the shell to reference camel-jms/2.10-SNAPSHOT, instead of tampering with the local features descriptor and refreshing it?
> In my head, the command would look like:
> {code}
> > feature:edit activemq-camel/5.6.0
> > feature:version-alter --feature camel-jms [2.9.2,2.10]
> > feature:update
> {code}
> (resembling the config shell constructs)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira