Re: Override Require-Capability in Maven-Bundle-Plugin
d 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 <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
Re: Override Require-Capability in Maven-Bundle-Plugin
ataSource, >>>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 >> <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
Re: Override Require-Capability in Maven-Bundle-Plugin
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 <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 >>>> >>>> -d
Re: Override Require-Capability in Maven-Bundle-Plugin
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 >>> >>> 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-Capabilit
Re: Override Require-Capability in Maven-Bundle-Plugin
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 >> >> 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
Re: Override Require-Capability in Maven-Bundle-Plugin
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 <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
Override Require-Capability in Maven-Bundle-Plugin
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
