karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KARAF-1497) Capability to alter versions in features and bundles
Date Thu, 24 May 2012 04:08:41 GMT

    [ https://issues.apache.org/jira/browse/KARAF-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282170#comment-13282170
] 

Claus Ibsen commented on KARAF-1497:
------------------------------------

Yeah it also seems like the activemq-camel feature file, should be [2.9,3) in the version
range. 
http://search.maven.org/remotecontent?filepath=org/apache/activemq/activemq-karaf/5.6.0/activemq-karaf-5.6.0-features.xml


                
> 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

        

Mime
View raw message