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
