From your StackOverflow post it seems that the unsatisfied requirement is this
one:
[caused by: Unable to resolve
com.javatechnics.jpa.simple/1.0.0.SNAPSHOT: missing requirement
[com.javatechnics.jpa.simple/1.0.0.SNAPSHOT] osgi.service;
objectClass=javax.persistence.spi.PersistenceProvider;
javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;
effective:=active]]
If you *know* that a bundle, let’s call it xyz, provides the
PersistenceProvider service then you can write one additional bundle that
simply does this:
Require-Bundle: xyz
Provide-Capability: osgi.service;
objectClass=javax.persistence.spi.PersistenceProvider;
javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;
effective:=active
This effectively augments the the provider bundle with the capability that is
needed. It’s still a hack but it’s IMHO a little cleaner than removing a
requirement from a bundle that actually still has that requirement.
Regards,
Neil
> On 13 Dec 2017, at 12:19, Kerry <[email protected]> wrote:
>
> David,
>
> Thanks for taking a look. As you and Neil Bartlett have said, my work around
> isn't the correct solution and I perhaps have to accept that I cannot achieve
> my desired result.
>
> I think this is because in part persistence units don't have OSGi in mind so
> don't place nice with it? I'm possibly trying to shoe-horn the proverbial
> round peg into a square hole. Wherever those headers are being generated they
> are required but the feature resolver is not quite clever enough to work out
> that I am truly providing everything in my feature? I might be too hard on
> the resolver here as it is likely that resolving dependencies is not as easy
> as I am imagining.
>
> I'll dig around a bit further but one solution is to provide separate
> features and have to install them in a specific order. ( Not good either)
>
> Kerry
>
> Sent from BlueMail
>
> On 12 Dec 2017, 23:22, at 23:22, David Jencks <[email protected]>
> wrote:
>> Kerry,
>>
>> I looked at your project and since you are not using any DS components
>> what I suggested does not apply. I have no idea where the generated
>> capabilities/requirement headers are coming from.
>>
>> In general I think it is worth expending considerable effort to
>> straighten out the capabilities/requirements wiring so it works
>> properly rather than trying to provide non-standard workarounds that
>> disable it and may have further unwanted side effects.
>>
>> The obvious question is whether the openjpa feature includes a bundle
>> with a Provide-Capability header matching the unsatisfied
>> Require-Capability. Frankly, I’d expect that what would be needed was
>> a Require-Capability header for a jpa extender, but I’m not that
>> familiar with jpa in osgi. AFAICT your bundle doesn’t import the
>> java.persistence.provider package so it couldn’t do anything with the
>> service whether or not it was present. This makes me wonder even more
>> where the generated headers are coming from any why.
>>
>> david jencks
>>
>>
>>> On Dec 12, 2017, at 2:23 PM, Kerry <[email protected]>
>> wrote:
>>>
>>> David,
>>>
>>> I quickly tried your suggested POM modification and still generates
>> the headers for me, though I remember the underscore technique to pass
>> instructions direct to bnd so will investigate further.
>>>
>>> The headers that are generated are:
>>>
>>> Export-Service =
>>>
>> com.javatechnics.jpa.dao.BookServiceDao;ServiceManager=Blueprint;name=BookServiceDao;osgi.service.blueprint.compname=bookServiceDao
>>> Provide-Capability =
>>>
>> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name=test,
>>>
>> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name=test,
>>>
>> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name=test,
>>>
>> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name=test
>>> Require-Capability =
>>>
>> osgi.service;effective:=active;javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl;objectClass=javax.persistence.spi.PersistenceProvider,
>>> osgi.extender;osgi.extender=aries.jpa,
>>>
>> osgi.service;effective:=active;filter:=(osgi.jndi.service.name=jdbc/test);objectClass=javax.sql.DataSource,
>>> osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.5))
>>>
>>> I've also added further information on my stackoverflow question.
>>>
>>> thanks
>>>
>>> Kerry
>>>
>>>
>>> On 12/12/17 20:29, David Jencks wrote:
>>>> I’d be interested to know the exact capabilities/requirements you
>> supply and that are generated.
>>>>
>>>> If these capabilities/requirements are from DS components you should
>> be able to turn off generation in a bnd.bnd file with
>>>>
>>>> -dsannotations-options:nocapabilities,norequirements
>>>>
>>>> I haven’t used the maven-bundle-plugin in some time, but if you are
>> using it with in-pom xml configuration I think you say something like
>>>>
>> <_dsannotations-options>nocapabilities,norequirements</_dsannotations-options>
>>>>
>>>> Hope this helps
>>>> david jencks
>>>>
>>>>
>>>>> On Dec 12, 2017, at 9:58 AM, Kerry
>> <[email protected]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> First of all I have asked this question already on StackOverflow so
>> apologies for 'duplicating' :
>>>>>
>>>>>
>> https://stackoverflow.com/questions/47738402/override-require-capability-in-maven-bundle-plugin
>>>>>
>>>>> I short, the Maven bundle plugin is duplicating my
>> 'Require-Capability' headers I manually set in the plugin
>> configuration. This is because the plugin is auto-generating the same
>> headers as well as including my own manually set ones. I need to
>> override the 'resolution' attribute to become optional (this is
>> probably not ideal but it's the only way I can create a single Apache
>> Karaf feature to install all my own bundles and other features and not
>> fail on deploy).
>>>>>
>>>>> Is there a way I can get the plugin to merge or use my manually
>> specified 'Require-Capability' headers?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Kerry
>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
