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
Re: Felix and JavaFX
Hi Chuck, No problem, I wasn't aware of the issues you were having i.e. felix not exporting the javafx packages by default. In Karaf they are exported by default but obviously not everyone wants all the functionality provided by Karaf. You've given me the idea to include some integration tests with 'stand-alone' Felix and suitable documentation. If you ever do get the chance to re-visit JavaFX in OSGi your comments would be much appreciated (as would from anyone else reading this and is interested.) Regards Kerry On 12/12/17 14:56, Chuck Davis wrote: Hi Kerry: Thanks for the note. Old indeed. I don't remember anything I learned from that project (though I did keep the modules). I did get it to work by including the module somebody mentioned. It seems so easy, looking at that module, I can't understand why Felix doesn't do the export for JavaFX so that it's not even an issue -- at least an option that can be turned on or off, installed or uninstalled or some such and stop the necessity of all the work-arounds on which developers are having to waste their time. If I revisit OSGi I'll take a look at your project if Felix hasn't fixed the issue yet at the time. Thanks. CD On 12/12/2017 05:19 AM, Kerry wrote: Hi Chuck, I realise that this is a response to an old message of yours but I have a GitHub project that may be of interest to you that brings OSGi to JavaFx. https://github.com/jtkb/osgifx It aims to be simpler than Drombler and is agnostic to the OSGi implementation. It is still a work in progress but check the examples and integration-test modules to see how to use it. I have currently tested it with Apache karaf which obviously used Apache Felix but plan to add tests for other implementations too. If you try it out any comments you have or improvements are welcome. Any issues also just ask. I'm in the process of improving the documentation at the moment. Kerry Sent from BlueMail - 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, 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
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
Re: Override Require-Capability in Maven-Bundle-Plugin
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 shoul
Re: Felix and JavaFX
Hi Chuck, I realise that this is a response to an old message of yours but I have a GitHub project that may be of interest to you that brings OSGi to JavaFx. https://github.com/jtkb/osgifx It aims to be simpler than Drombler and is agnostic to the OSGi implementation. It is still a work in progress but check the examples and integration-test modules to see how to use it. I have currently tested it with Apache karaf which obviously used Apache Felix but plan to add tests for other implementations too. If you try it out any comments you have or improvements are welcome. Any issues also just ask. I'm in the process of improving the documentation at the moment. Kerry Sent from BlueMail
