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é [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
