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 <karaf-u...@avionicengineers.com> 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 <david.a.jen...@gmail.com> 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 <karaf-u...@avionicengineers.com>
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
<karaf-u...@avionicengineers.com> 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: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to