You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Seth Leger <se...@opennms.org> on 2018/01/29 17:45:09 UTC
Bug in Karaf feature resolver?
Hi everyone,
Running Karaf 4.1.2 and I think I'm running into a bug in the Karaf
feature resolver. If I make a feature with 2 bundles generated by the
same project (one with a classifier), the resolver ignores the artifact
with the classifier and only installs the main artifact. For example:
<feature name="hello" version="1.0">
<bundle>mvn:hello/world/1.0</bundle>
<bundle>mvn:hello/world/1.0/jar/special</bundle>
</feature>
karaf@root> feature:install -t -v hello
...
Bundles to install:
mvn:hello/world/1.0
...
The mvn:hello/world/1.0/jar/special JAR appears to be ignored. Maybe the
feature resolver isn't taking the classifier into account somewhere?
Does this sound like a bug that needs to be filed in JIRA? Maybe I am
missing something in my feature definition.
Seth Leger
The OpenNMS Group
Re: Bug in Karaf feature resolver?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
OK, if the two bundles provide the same capabilities, it's normal: the resolver
detects that the first bundle provides the caps, so it doesn't install the
second one.
If you really want to install both, you can flag using prerequisite feature.
Regards
JB
On 01/29/2018 08:15 PM, Seth Leger wrote:
> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>> If you try to install the bundle by hand using:
>>
>> bundle:install -s mvn:hello/world/1.0/jar/special
>>
>> does it work ?
>
> Yes. And if I put the bundle in the feature like this (without the other
> artifact with the same groupId/artifactId/version):
>
> <feature name="hello" version="1.0">
> <bundle>mvn:hello/world/1.0/jar/special</bundle>
> </feature>
>
> that works as expected as well.
>
>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>
> I don't see any other features in Karaf's standard features, Karaf's
> Spring features, or Camel's features that have two bundles with
> identical groupId/artifactId/version inside the same feature. The
> closest is the 'camel-kubernetes' which has several bundles with
> classifiers but they all have unique artifactIds:
>
> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>
> That's why I think it's a feature resolver issue and not an Aether issue.
>
> Seth Leger
> The OpenNMS Group
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bug in Karaf feature resolver?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
As said in a previous e-mail the capabilities are important too.
Regards
JB
On 01/29/2018 10:18 PM, Seth Leger wrote:
> Hi JB,
>
> Making the SymbolicName unique in the 2 bundles didn't make a
> difference. How does the resolver consider two bundles to be the same if
> the URI and SymbolicName (and several MANIFEST.MF headers) are
> different? Is there something that I can do to force the bundles to
> appear unique to the resolver, like adding a Provide-Capability header?
>
>
> It sounds like you're saying that the feature resolver does things in
> this order:
>
> 1. Read feature
> 2. Compose bundle capabilities, exports
> 3. Evaluate <conditional> conditions
> 4. Install bundles
>
> I guess it has to do things in that order since conditionals can use
> 'req:' statements. However, it leads to the case I'm in where the
> resolver decides that 2 different bundles are the "same" and they get
> de-duplicated in (2) and then skipped in (3). Is my description of how
> things work accurate so far?
>
> It seems like you could do:
>
> 1. Read feature
> 2. Evaluate <conditional><condition>feature</condition></conditional>
> conditionals
> 3. Compose bundle capabilities, exports
> 4. Evaluate <conditional><condition>req:...</condition></conditional>
> conditionals
> 5. Install bundles
>
> I don't know exactly how the feature resolver is working so this could
> be a shot in the dark.
>
>
> You said in one message that I could work around all of this by using
> prerequisite features, would that look like:
>
> <feature name="hello-aries">
> <bundle>mvn:hello/world/1.0</bundle>
> </feature>
> <feature name="hello-gemini">
> <bundle>mvn:hello/world/1.0/jar/gemini</bundle>
> </feature>
> <feature name="hello">
> <conditional>
> <condition>aries-blueprint</condition>
> <feature prerequisite="true">hello-aries</feature>
> </conditional>
> <conditional>
> <condition>gemini-blueprint</condition>
> <feature prerequisite="true">hello-gemini</feature>
> </conditional>
> </feature>
>
> That doesn't look any different to me (just another layer of
> indirection) but I don't know what the 'prerequisite' flag means in this
> case.
>
> Seth Leger
> The OpenNMS Group
>
>
> On 1/29/18 3:03 PM, Jean-Baptiste Onofré wrote:
>> Exactly, the resolver considers it's the same bundle ;)
>>
>> Regards
>> JB
>>
>> On 01/29/2018 08:49 PM, Seth Leger wrote:
>>> Hi Jean-Baptiste,
>>>
>>> The bundles are basically the same: they do have the same version,
>>> SymbolicName, etc. That might be the problem... maybe I need to make the
>>> SymbolicName unique.
>>>
>>> What I'm basically trying to do is make a conditional where:
>>>
>>> <feature ...>
>>> <conditional>
>>> <condition>aries-blueprint</condition>
>>> <bundle>mvn:hello/world/1.0</bundle>
>>> </conditional>
>>> <conditional>
>>> <condition>gemini-blueprint</condition>
>>> <bundle>mvn:hello/world/1.0/jar/gemini</bundle>
>>> </conditional>
>>> </feature>
>>>
>>> and either aries-blueprint or gemini-blueprint is installed in the
>>> container. The bundle with the 'gemini' classifier has a couple of extra
>>> Spring files to allow it to run under gemini-blueprint.
>>>
>>> However, this is not working because if aries-blueprint is not installed
>>> (making its condition false), the feature resolver seems to prevent
>>> mvn:hello/world/1.0/*/* from being installed so
>>> mvn:hello/world/1.0/jar/gemini isn't installed.
>>>
>>> Let me try updating the SymbolicName and see if that fixes it. In other
>>> words, I'll try:
>>>
>>> mvn:hello/world/1.0 -> hello.world
>>> mvn:hello/world/1.0/jar/gemini -> hello.world.gemini
>>>
>>> Seth Leger
>>> The OpenNMS Group
>>>
>>>
>>> On 1/29/18 2:27 PM, Jean-Baptiste Onofré wrote:
>>>> By the way, the bundles are different (in term of name, export, etc) ?
>>>>
>>>> On 01/29/2018 08:15 PM, Seth Leger wrote:
>>>>> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>>>>>> If you try to install the bundle by hand using:
>>>>>>
>>>>>> bundle:install -s mvn:hello/world/1.0/jar/special
>>>>>>
>>>>>> does it work ?
>>>>>
>>>>> Yes. And if I put the bundle in the feature like this (without the other
>>>>> artifact with the same groupId/artifactId/version):
>>>>>
>>>>> <feature name="hello" version="1.0">
>>>>> <bundle>mvn:hello/world/1.0/jar/special</bundle>
>>>>> </feature>
>>>>>
>>>>> that works as expected as well.
>>>>>
>>>>>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>>>>>
>>>>> I don't see any other features in Karaf's standard features, Karaf's
>>>>> Spring features, or Camel's features that have two bundles with
>>>>> identical groupId/artifactId/version inside the same feature. The
>>>>> closest is the 'camel-kubernetes' which has several bundles with
>>>>> classifiers but they all have unique artifactIds:
>>>>>
>>>>> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>>>>>
>>>>> That's why I think it's a feature resolver issue and not an Aether issue.
>>>>>
>>>>> Seth Leger
>>>>> The OpenNMS Group
>>>>>
>>>>
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bug in Karaf feature resolver?
Posted by Seth Leger <se...@opennms.org>.
Hi JB,
Making the SymbolicName unique in the 2 bundles didn't make a
difference. How does the resolver consider two bundles to be the same if
the URI and SymbolicName (and several MANIFEST.MF headers) are
different? Is there something that I can do to force the bundles to
appear unique to the resolver, like adding a Provide-Capability header?
It sounds like you're saying that the feature resolver does things in
this order:
1. Read feature
2. Compose bundle capabilities, exports
3. Evaluate <conditional> conditions
4. Install bundles
I guess it has to do things in that order since conditionals can use
'req:' statements. However, it leads to the case I'm in where the
resolver decides that 2 different bundles are the "same" and they get
de-duplicated in (2) and then skipped in (3). Is my description of how
things work accurate so far?
It seems like you could do:
1. Read feature
2. Evaluate <conditional><condition>feature</condition></conditional>
conditionals
3. Compose bundle capabilities, exports
4. Evaluate <conditional><condition>req:...</condition></conditional>
conditionals
5. Install bundles
I don't know exactly how the feature resolver is working so this could
be a shot in the dark.
You said in one message that I could work around all of this by using
prerequisite features, would that look like:
<feature name="hello-aries">
<bundle>mvn:hello/world/1.0</bundle>
</feature>
<feature name="hello-gemini">
<bundle>mvn:hello/world/1.0/jar/gemini</bundle>
</feature>
<feature name="hello">
<conditional>
<condition>aries-blueprint</condition>
<feature prerequisite="true">hello-aries</feature>
</conditional>
<conditional>
<condition>gemini-blueprint</condition>
<feature prerequisite="true">hello-gemini</feature>
</conditional>
</feature>
That doesn't look any different to me (just another layer of
indirection) but I don't know what the 'prerequisite' flag means in this
case.
Seth Leger
The OpenNMS Group
On 1/29/18 3:03 PM, Jean-Baptiste Onofré wrote:
> Exactly, the resolver considers it's the same bundle ;)
>
> Regards
> JB
>
> On 01/29/2018 08:49 PM, Seth Leger wrote:
>> Hi Jean-Baptiste,
>>
>> The bundles are basically the same: they do have the same version,
>> SymbolicName, etc. That might be the problem... maybe I need to make the
>> SymbolicName unique.
>>
>> What I'm basically trying to do is make a conditional where:
>>
>> <feature ...>
>> <conditional>
>> <condition>aries-blueprint</condition>
>> <bundle>mvn:hello/world/1.0</bundle>
>> </conditional>
>> <conditional>
>> <condition>gemini-blueprint</condition>
>> <bundle>mvn:hello/world/1.0/jar/gemini</bundle>
>> </conditional>
>> </feature>
>>
>> and either aries-blueprint or gemini-blueprint is installed in the
>> container. The bundle with the 'gemini' classifier has a couple of extra
>> Spring files to allow it to run under gemini-blueprint.
>>
>> However, this is not working because if aries-blueprint is not installed
>> (making its condition false), the feature resolver seems to prevent
>> mvn:hello/world/1.0/*/* from being installed so
>> mvn:hello/world/1.0/jar/gemini isn't installed.
>>
>> Let me try updating the SymbolicName and see if that fixes it. In other
>> words, I'll try:
>>
>> mvn:hello/world/1.0 -> hello.world
>> mvn:hello/world/1.0/jar/gemini -> hello.world.gemini
>>
>> Seth Leger
>> The OpenNMS Group
>>
>>
>> On 1/29/18 2:27 PM, Jean-Baptiste Onofré wrote:
>>> By the way, the bundles are different (in term of name, export, etc) ?
>>>
>>> On 01/29/2018 08:15 PM, Seth Leger wrote:
>>>> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>>>>> If you try to install the bundle by hand using:
>>>>>
>>>>> bundle:install -s mvn:hello/world/1.0/jar/special
>>>>>
>>>>> does it work ?
>>>>
>>>> Yes. And if I put the bundle in the feature like this (without the other
>>>> artifact with the same groupId/artifactId/version):
>>>>
>>>> <feature name="hello" version="1.0">
>>>> <bundle>mvn:hello/world/1.0/jar/special</bundle>
>>>> </feature>
>>>>
>>>> that works as expected as well.
>>>>
>>>>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>>>>
>>>> I don't see any other features in Karaf's standard features, Karaf's
>>>> Spring features, or Camel's features that have two bundles with
>>>> identical groupId/artifactId/version inside the same feature. The
>>>> closest is the 'camel-kubernetes' which has several bundles with
>>>> classifiers but they all have unique artifactIds:
>>>>
>>>> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>>>>
>>>> That's why I think it's a feature resolver issue and not an Aether issue.
>>>>
>>>> Seth Leger
>>>> The OpenNMS Group
>>>>
>>>
>>
>
Re: Bug in Karaf feature resolver?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Exactly, the resolver considers it's the same bundle ;)
Regards
JB
On 01/29/2018 08:49 PM, Seth Leger wrote:
> Hi Jean-Baptiste,
>
> The bundles are basically the same: they do have the same version,
> SymbolicName, etc. That might be the problem... maybe I need to make the
> SymbolicName unique.
>
> What I'm basically trying to do is make a conditional where:
>
> <feature ...>
> <conditional>
> <condition>aries-blueprint</condition>
> <bundle>mvn:hello/world/1.0</bundle>
> </conditional>
> <conditional>
> <condition>gemini-blueprint</condition>
> <bundle>mvn:hello/world/1.0/jar/gemini</bundle>
> </conditional>
> </feature>
>
> and either aries-blueprint or gemini-blueprint is installed in the
> container. The bundle with the 'gemini' classifier has a couple of extra
> Spring files to allow it to run under gemini-blueprint.
>
> However, this is not working because if aries-blueprint is not installed
> (making its condition false), the feature resolver seems to prevent
> mvn:hello/world/1.0/*/* from being installed so
> mvn:hello/world/1.0/jar/gemini isn't installed.
>
> Let me try updating the SymbolicName and see if that fixes it. In other
> words, I'll try:
>
> mvn:hello/world/1.0 -> hello.world
> mvn:hello/world/1.0/jar/gemini -> hello.world.gemini
>
> Seth Leger
> The OpenNMS Group
>
>
> On 1/29/18 2:27 PM, Jean-Baptiste Onofré wrote:
>> By the way, the bundles are different (in term of name, export, etc) ?
>>
>> On 01/29/2018 08:15 PM, Seth Leger wrote:
>>> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>>>> If you try to install the bundle by hand using:
>>>>
>>>> bundle:install -s mvn:hello/world/1.0/jar/special
>>>>
>>>> does it work ?
>>>
>>> Yes. And if I put the bundle in the feature like this (without the other
>>> artifact with the same groupId/artifactId/version):
>>>
>>> <feature name="hello" version="1.0">
>>> <bundle>mvn:hello/world/1.0/jar/special</bundle>
>>> </feature>
>>>
>>> that works as expected as well.
>>>
>>>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>>>
>>> I don't see any other features in Karaf's standard features, Karaf's
>>> Spring features, or Camel's features that have two bundles with
>>> identical groupId/artifactId/version inside the same feature. The
>>> closest is the 'camel-kubernetes' which has several bundles with
>>> classifiers but they all have unique artifactIds:
>>>
>>> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>>>
>>> That's why I think it's a feature resolver issue and not an Aether issue.
>>>
>>> Seth Leger
>>> The OpenNMS Group
>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bug in Karaf feature resolver?
Posted by Seth Leger <se...@opennms.org>.
Hi Jean-Baptiste,
The bundles are basically the same: they do have the same version,
SymbolicName, etc. That might be the problem... maybe I need to make the
SymbolicName unique.
What I'm basically trying to do is make a conditional where:
<feature ...>
<conditional>
<condition>aries-blueprint</condition>
<bundle>mvn:hello/world/1.0</bundle>
</conditional>
<conditional>
<condition>gemini-blueprint</condition>
<bundle>mvn:hello/world/1.0/jar/gemini</bundle>
</conditional>
</feature>
and either aries-blueprint or gemini-blueprint is installed in the
container. The bundle with the 'gemini' classifier has a couple of extra
Spring files to allow it to run under gemini-blueprint.
However, this is not working because if aries-blueprint is not installed
(making its condition false), the feature resolver seems to prevent
mvn:hello/world/1.0/*/* from being installed so
mvn:hello/world/1.0/jar/gemini isn't installed.
Let me try updating the SymbolicName and see if that fixes it. In other
words, I'll try:
mvn:hello/world/1.0 -> hello.world
mvn:hello/world/1.0/jar/gemini -> hello.world.gemini
Seth Leger
The OpenNMS Group
On 1/29/18 2:27 PM, Jean-Baptiste Onofré wrote:
> By the way, the bundles are different (in term of name, export, etc) ?
>
> On 01/29/2018 08:15 PM, Seth Leger wrote:
>> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>>> If you try to install the bundle by hand using:
>>>
>>> bundle:install -s mvn:hello/world/1.0/jar/special
>>>
>>> does it work ?
>>
>> Yes. And if I put the bundle in the feature like this (without the other
>> artifact with the same groupId/artifactId/version):
>>
>> <feature name="hello" version="1.0">
>> <bundle>mvn:hello/world/1.0/jar/special</bundle>
>> </feature>
>>
>> that works as expected as well.
>>
>>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>>
>> I don't see any other features in Karaf's standard features, Karaf's
>> Spring features, or Camel's features that have two bundles with
>> identical groupId/artifactId/version inside the same feature. The
>> closest is the 'camel-kubernetes' which has several bundles with
>> classifiers but they all have unique artifactIds:
>>
>> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>>
>> That's why I think it's a feature resolver issue and not an Aether issue.
>>
>> Seth Leger
>> The OpenNMS Group
>>
>
Re: Bug in Karaf feature resolver?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, the bundles are different (in term of name, export, etc) ?
On 01/29/2018 08:15 PM, Seth Leger wrote:
> On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
>> If you try to install the bundle by hand using:
>>
>> bundle:install -s mvn:hello/world/1.0/jar/special
>>
>> does it work ?
>
> Yes. And if I put the bundle in the feature like this (without the other
> artifact with the same groupId/artifactId/version):
>
> <feature name="hello" version="1.0">
> <bundle>mvn:hello/world/1.0/jar/special</bundle>
> </feature>
>
> that works as expected as well.
>
>> I'm surprised as we use such kind of URL in features, like in Camel for instance.
>
> I don't see any other features in Karaf's standard features, Karaf's
> Spring features, or Camel's features that have two bundles with
> identical groupId/artifactId/version inside the same feature. The
> closest is the 'camel-kubernetes' which has several bundles with
> classifiers but they all have unique artifactIds:
>
> https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
>
> That's why I think it's a feature resolver issue and not an Aether issue.
>
> Seth Leger
> The OpenNMS Group
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Bug in Karaf feature resolver?
Posted by Seth Leger <se...@opennms.org>.
On 1/29/18 12:49 PM, Jean-Baptiste Onofré wrote:
> If you try to install the bundle by hand using:
>
> bundle:install -s mvn:hello/world/1.0/jar/special
>
> does it work ?
Yes. And if I put the bundle in the feature like this (without the other
artifact with the same groupId/artifactId/version):
<feature name="hello" version="1.0">
<bundle>mvn:hello/world/1.0/jar/special</bundle>
</feature>
that works as expected as well.
> I'm surprised as we use such kind of URL in features, like in Camel for instance.
I don't see any other features in Karaf's standard features, Karaf's
Spring features, or Camel's features that have two bundles with
identical groupId/artifactId/version inside the same feature. The
closest is the 'camel-kubernetes' which has several bundles with
classifiers but they all have unique artifactIds:
https://github.com/apache/camel/blob/camel-2.20.2/platforms/karaf/features/src/main/resources/features.xml#L1306
That's why I think it's a feature resolver issue and not an Aether issue.
Seth Leger
The OpenNMS Group
Re: Bug in Karaf feature resolver?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Seth,
The resolver is not involved here for the mvn URL resolution: it's pax-url-aether.
The MVN URL should be:
mvn:groupId/artifactId/version/type/classifier
I'm surprised as we use such kind of URL in features, like in Camel for instance.
Don't you have an issue in your bundle ?
If you try to install the bundle by hand using:
bundle:install -s mvn:hello/world/1.0/jar/special
does it work ?
Regards
JB
On 01/29/2018 06:45 PM, Seth Leger wrote:
> Hi everyone,
>
> Running Karaf 4.1.2 and I think I'm running into a bug in the Karaf
> feature resolver. If I make a feature with 2 bundles generated by the
> same project (one with a classifier), the resolver ignores the artifact
> with the classifier and only installs the main artifact. For example:
>
> <feature name="hello" version="1.0">
> <bundle>mvn:hello/world/1.0</bundle>
> <bundle>mvn:hello/world/1.0/jar/special</bundle>
> </feature>
>
> karaf@root> feature:install -t -v hello
> ...
> Bundles to install:
> mvn:hello/world/1.0
> ...
>
> The mvn:hello/world/1.0/jar/special JAR appears to be ignored. Maybe the
> feature resolver isn't taking the classifier into account somewhere?
>
> Does this sound like a bug that needs to be filed in JIRA? Maybe I am
> missing something in my feature definition.
>
> Seth Leger
> The OpenNMS Group
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com