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
