Re: Override Require-Capability in Maven-Bundle-Plugin

2017-12-12 Thread David Jencks 
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  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  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

2017-12-12 Thread Kerry 

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  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

2017-12-12 Thread Kerry 

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

2017-12-12 Thread Kerry 

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: Felix and JavaFX

2017-12-12 Thread Chuck Davis 

Karl, thanks for that information.


On 12/12/2017 08:31 AM, Karl Pauls wrote:

Additionally, the JavaFX exports should now be available on java9 ootb
  (assuming the modules are on the module path). As Neil correctly
points out, the reason they are not on older version is exactly that -
we don't know if they are there or not. With java9, we can detect that
(and we do starting with Felix Framework 5.6.10).

regards,

Karl





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix and JavaFX

2017-12-12 Thread Karl Pauls 
Additionally, the JavaFX exports should now be available on java9 ootb
 (assuming the modules are on the module path). As Neil correctly
points out, the reason they are not on older version is exactly that -
we don't know if they are there or not. With java9, we can detect that
(and we do starting with Felix Framework 5.6.10).

regards,

Karl

On Tue, Dec 12, 2017 at 4:03 PM, Neil Bartlett  wrote:
> That's pretty easy to answer.
>
> Felix by default exports all standard Java SE packages. JavaFX is not part
> of Java SE, it is an extension that is only available on a subset of Java
> implementations.
>
> Neil
>
> On 12 Dec 2017 2:56 pm, "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
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix and JavaFX

2017-12-12 Thread Neil Bartlett 
That's pretty easy to answer.

Felix by default exports all standard Java SE packages. JavaFX is not part
of Java SE, it is an extension that is only available on a subset of Java
implementations.

Neil

On 12 Dec 2017 2:56 pm, "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
>
>

Re: Felix and JavaFX

2017-12-12 Thread Chuck Davis 

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

Re: Felix and JavaFX

2017-12-12 Thread Kerry 
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 ​