You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@camel.apache.org by "Chris Dolan (JIRA)" <ji...@apache.org> on 2011/09/23 05:25:26 UTC

[jira] [Resolved] (CAMEL-4479) Camel-Karaf feature.xml has version numbers specified too tightly

     [ https://issues.apache.org/jira/browse/CAMEL-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Dolan resolved CAMEL-4479.
--------------------------------

    Resolution: Not A Problem

Wow, thanks for the detailed explanation. That's far from intuitive, but it makes sense as a compromise. Closing as "Not A Problem".

> Camel-Karaf feature.xml has version numbers specified too tightly
> -----------------------------------------------------------------
>
>                 Key: CAMEL-4479
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4479
>             Project: Camel
>          Issue Type: Bug
>          Components: karaf
>    Affects Versions: 2.7.0
>         Environment: Karaf 2.2.2
>            Reporter: Chris Dolan
>
> I'm trying to load activemq-web 5.5.0 into Karaf 2.2.2 via the activemq feature.xml. ActiveMQ 5.5.0 depends on Camel 2.7.0's "camel-jms" feature. The Camel feature.xml has two things that make it incompatible with Karaf 2.2.2:
>   <repository>mvn:org.apache.karaf.assemblies.features/standard/2.2.0/xml/features</repository>
> which doesn't match my 2.2.2 version and
>     <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-pool/1.5.4_1</bundle>
> which does not match the 1.5.4_2 version that is specified by Karaf 2.2.2. Both of these cause runtime exceptions that prevent loading the feature. In each case, it should be possible (in theory) to make the Camel feature.xml more flexible my specifying ranges, like "[2.2,3)" or "[1.5,2)" which would cause pax-url-mvn to look for a match via the Maven metadata.xml. I haven't actually tested that such a change would work. In my own environment I simply hacked the XML to put the updated versions, but that's not a sustainable approach.
> Part of the problem is http://team.ops4j.org/browse/PAXURL-141 "mvn: urls resolve versions differently from Maven". That defect complains that unadorned versions in mvn: URLs do not act like usual Maven soft version numbers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira