felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kerry <karaf-u...@AvionicEngineers.com>
Subject Re: Override Require-Capability in Maven-Bundle-Plugin
Date Wed, 13 Dec 2017 12:19:16 GMT
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.jencks@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-user@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-user@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>> 
>>> 
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>> 
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message