[
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
