Re: Override Require-Capability in Maven-Bundle-Plugin

[Kerry]

Neil,

Thanks, implementing as you suggest works. I think of it more as a 'graceful 
work around'! If you care to outline your solution on my SO post I'll mark as 
accepted.

David,

Once again thanks for your suggestions, much appreciated.

Regards

Kerry


On 13/12/17 20:57, Neil Bartlett wrote:

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

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 

Re: Override Require-Capability in Maven-Bundle-Plugin

[Neil Bartlett]

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

Re: Override Require-Capability in Maven-Bundle-Plugin

[David Jencks]

The effective:=active clause means the requirements/capabilities are not used 
at runtime when wiring bundles, they are information for figuring out which 
bundles will work together and are used by things such as (spec) subsystems and 
the karaf feature installer.
Aries implements the osgi jpa spec so it ought to work fine. Perhaps asking on 
the Aries list would get better results.

David Jencks 

Sent from my iPhone

> On Dec 13, 2017, at 4:19 AM, Kerry  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  
>> 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 
>> 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
 
 Hope this helps
 david jencks
 
 
> On Dec 12, 2017, at 9:58 AM, Kerry
>>  wrote:
> 
> Hi,
> 
> First of all I have asked this question already on StackOverflow so
>> apologies for 'duplicating' :
> 
> 
>> 

Re: Override Require-Capability in Maven-Bundle-Plugin

[Kerry]

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  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 
>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
>>>
>>> Hope this helps
>>> david jencks
>>>
>>>
 On Dec 12, 2017, at 9:58 AM, Kerry
> 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