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 >>>> >>> >> >
