[jira] [Created] (FELIX-5068) Issues with consecutive call to ServicePermission with different permissions for the same class

[Akila Sivakumar (JIRA)]

Akila Sivakumar created FELIX-5068:
--

 Summary: Issues with consecutive call to ServicePermission with 
different permissions for the same class
 Key: FELIX-5068
 URL: https://issues.apache.org/jira/browse/FELIX-5068
 Project: Felix
  Issue Type: Bug
  Components: Conditional Permission Admin
Affects Versions: framework-4.4.1
Reporter: Akila Sivakumar


If the same service permission is repeated in the file for the same class, e.g. 
ServicePermission("com.xxx.test.apps.inject.autoactivate.test01.InjectableBean","get")
ServicePermission("com.xxx.test.apps.inject.autoactivate.test01.InjectableBean","register")
 

the only latest permission is used as resulting. So in the mentioned case the 
only "register" permission will be requested for the service class and bundle 
cannot be started with the exception that "get" permission required for bundle 
to start.

A comma-separated list of permissions should be added for service:
ServicePermission("com.xxx.test.apps.inject.autoactivate.test01.InjectableBean","register,get")



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Future of maven-scr-plugin

[Konrad Windszus]

Hi Carsten, 
thanks for your answer. One other thing to mention here is that custom plugins 
exist for the maven-scr-plugin 
(http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/extending-scr-annotations.html
 
).
Could those be easily migrated to bnd plugins? Do you have any hints on how to 
accomplish that for @SlingServlet, @SlingFilter (currently part of 
maven-scr-plugin, but should be moved to a Sling module then) and for 
@SlingHealthCheck 
(https://github.com/apache/sling/blob/trunk/bundles/extensions/healthcheck/annotations/src/main/java/org/apache/sling/hc/annotations/SlingHealthCheckProcessor.java
 
)?
Thanks
Konrad

> On 07 Oct 2015, at 18:18, Carsten Ziegeler  wrote:
> 
> Hi
> 
> Am 07.10.15 um 21:07 schrieb Konrad Windszus:
>> Hi,
>> I am wondering about the future of the maven-scr-plugin. I think it should 
>> be deprecated and instead the documentation should point to the 
>> maven-bundle-plugin to be used now even for generating descriptors for 
>> metatype and declarative services.
>> 
>> That can nowadays take care of generating the component descriptor [0] with 
>> the OSGi standard annotations [1]. For the metatype generation bnd came up 
>> with its own annotations[3], which should be a replacement for all 
>> maven-scr-plugin annotations.
> Actually there are standard metatype annotations as well which work
> nicely with the new R6 DS annotations. So no need to use proprietary
> annotations anymore
> 
>> Also it seems that maven-scr-plugin is not compatible with Declarative 
>> Services 1.3 (meaning I cannot use "Configuration Property Types”) [3].
> It only supports DS upto 1.2
> 
>> 
>> The only thing which is not covered in the maven-bundle-plugin is component 
>> inheritance (but that is deprecated anyways [4]).
> That's why we deprecated it :)
> 
>> Are there any other feature of the maven-scr-plugin which are not covered by 
>> bnd/maven-bundle-plugin?
> Nearly none - we have default properties in the scr plugin, so you can
> configure something like the vendor once in your parent pom and it gets
> applied to every component.
> 
> The plan is to indeed phase out the maven scr plugin. It still has some
> usage, as the bundle plugin is not a dropin replacement. You would need
> to rewrite your components - and switching to the official annotations
> has some subtle differences in the defaults.
> On the other hand, we have a bnd plugin that is able to process the
> proprietary Felix annotations.
> 
> Therefore, I totally agree that we should update the documentation. But
> of course we have to support our user base for some time.
> 
> Carsten
> 
>> 
>> My request originates from the discussion at 
>> https://github.com/bndtools/bnd/issues/999.
>> 
>> WDYT?
>> Thanks for any input,
>> Konrad
>> 
>> 
>> [0] - http://www.aqute.biz/Bnd/Components
>> [1] - 
>> https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/package-summary.html
>> [2] - http://www.aqute.biz/Bnd/MetaType
>> [3] - http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
>> [4] - https://issues.apache.org/jira/browse/FELIX-4170
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: Future of maven-scr-plugin

[David Jencks]

can’t you add the -dsannotations-inherit: true flag to the maven-bundle-plugin 
instructions and get DS inheritance?

david jencks

> On Oct 7, 2015, at 12:18 PM, Carsten Ziegeler  wrote:
> 
> Hi
> 
> Am 07.10.15 um 21:07 schrieb Konrad Windszus:
>> Hi,
>> I am wondering about the future of the maven-scr-plugin. I think it should 
>> be deprecated and instead the documentation should point to the 
>> maven-bundle-plugin to be used now even for generating descriptors for 
>> metatype and declarative services.
>> 
>> That can nowadays take care of generating the component descriptor [0] with 
>> the OSGi standard annotations [1]. For the metatype generation bnd came up 
>> with its own annotations[3], which should be a replacement for all 
>> maven-scr-plugin annotations.
> Actually there are standard metatype annotations as well which work
> nicely with the new R6 DS annotations. So no need to use proprietary
> annotations anymore
> 
>> Also it seems that maven-scr-plugin is not compatible with Declarative 
>> Services 1.3 (meaning I cannot use "Configuration Property Types”) [3].
> It only supports DS upto 1.2
> 
>> 
>> The only thing which is not covered in the maven-bundle-plugin is component 
>> inheritance (but that is deprecated anyways [4]).
> That's why we deprecated it :)
> 
>> Are there any other feature of the maven-scr-plugin which are not covered by 
>> bnd/maven-bundle-plugin?
> Nearly none - we have default properties in the scr plugin, so you can
> configure something like the vendor once in your parent pom and it gets
> applied to every component.
> 
> The plan is to indeed phase out the maven scr plugin. It still has some
> usage, as the bundle plugin is not a dropin replacement. You would need
> to rewrite your components - and switching to the official annotations
> has some subtle differences in the defaults.
> On the other hand, we have a bnd plugin that is able to process the
> proprietary Felix annotations.
> 
> Therefore, I totally agree that we should update the documentation. But
> of course we have to support our user base for some time.
> 
> Carsten
> 
>> 
>> My request originates from the discussion at 
>> https://github.com/bndtools/bnd/issues/999.
>> 
>> WDYT?
>> Thanks for any input,
>> Konrad
>> 
>> 
>> [0] - http://www.aqute.biz/Bnd/Components
>> [1] - 
>> https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/package-summary.html
>> [2] - http://www.aqute.biz/Bnd/MetaType
>> [3] - http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
>> [4] - https://issues.apache.org/jira/browse/FELIX-4170
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org 

Re: Future of maven-scr-plugin

[Carsten Ziegeler]

Hi

Am 07.10.15 um 21:07 schrieb Konrad Windszus:
> Hi,
> I am wondering about the future of the maven-scr-plugin. I think it should be 
> deprecated and instead the documentation should point to the 
> maven-bundle-plugin to be used now even for generating descriptors for 
> metatype and declarative services.
> 
> That can nowadays take care of generating the component descriptor [0] with 
> the OSGi standard annotations [1]. For the metatype generation bnd came up 
> with its own annotations[3], which should be a replacement for all 
> maven-scr-plugin annotations.
Actually there are standard metatype annotations as well which work
nicely with the new R6 DS annotations. So no need to use proprietary
annotations anymore

> Also it seems that maven-scr-plugin is not compatible with Declarative 
> Services 1.3 (meaning I cannot use "Configuration Property Types”) [3].
It only supports DS upto 1.2

> 
> The only thing which is not covered in the maven-bundle-plugin is component 
> inheritance (but that is deprecated anyways [4]).
That's why we deprecated it :)

> Are there any other feature of the maven-scr-plugin which are not covered by 
> bnd/maven-bundle-plugin?
Nearly none - we have default properties in the scr plugin, so you can
configure something like the vendor once in your parent pom and it gets
applied to every component.

The plan is to indeed phase out the maven scr plugin. It still has some
usage, as the bundle plugin is not a dropin replacement. You would need
to rewrite your components - and switching to the official annotations
has some subtle differences in the defaults.
On the other hand, we have a bnd plugin that is able to process the
proprietary Felix annotations.

Therefore, I totally agree that we should update the documentation. But
of course we have to support our user base for some time.

Carsten

> 
> My request originates from the discussion at 
> https://github.com/bndtools/bnd/issues/999.
> 
> WDYT?
> Thanks for any input,
> Konrad
> 
> 
> [0] - http://www.aqute.biz/Bnd/Components
> [1] - 
> https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/package-summary.html
> [2] - http://www.aqute.biz/Bnd/MetaType
> [3] - http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
> [4] - https://issues.apache.org/jira/browse/FELIX-4170
> 
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Future of maven-scr-plugin

[Konrad Windszus]

Hi,
I am wondering about the future of the maven-scr-plugin. I think it should be 
deprecated and instead the documentation should point to the 
maven-bundle-plugin to be used now even for generating descriptors for metatype 
and declarative services.

That can nowadays take care of generating the component descriptor [0] with the 
OSGi standard annotations [1]. For the metatype generation bnd came up with its 
own annotations[3], which should be a replacement for all maven-scr-plugin 
annotations.
Also it seems that maven-scr-plugin is not compatible with Declarative Services 
1.3 (meaning I cannot use "Configuration Property Types”) [3].

The only thing which is not covered in the maven-bundle-plugin is component 
inheritance (but that is deprecated anyways [4]).
Are there any other feature of the maven-scr-plugin which are not covered by 
bnd/maven-bundle-plugin?

My request originates from the discussion at 
https://github.com/bndtools/bnd/issues/999.

WDYT?
Thanks for any input,
Konrad


[0] - http://www.aqute.biz/Bnd/Components
[1] - 
https://osgi.org/javadoc/r6/enterprise/org/osgi/service/component/annotations/package-summary.html
[2] - http://www.aqute.biz/Bnd/MetaType
[3] - http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
[4] - https://issues.apache.org/jira/browse/FELIX-4170

[jira] [Created] (FELIX-5067) Implement the OSGi Repository 1.1 specification

[David Bosschaert (JIRA)]

David Bosschaert created FELIX-5067:
---

 Summary: Implement the OSGi Repository 1.1 specification
 Key: FELIX-5067
 URL: https://issues.apache.org/jira/browse/FELIX-5067
 Project: Felix
  Issue Type: Improvement
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-2.0.6
Reporter: David Bosschaert


The OSGi Enterprise R6 Repository spec has been updated to version 1.1. The 
Felix Implementation should be updated to support the enhancements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5066) BundleRepository should provide osgi.service and osgi.implementation capabilities

[David Bosschaert (JIRA)]

David Bosschaert created FELIX-5066:
---

 Summary: BundleRepository should provide osgi.service and 
osgi.implementation capabilities
 Key: FELIX-5066
 URL: https://issues.apache.org/jira/browse/FELIX-5066
 Project: Felix
  Issue Type: Bug
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-2.0.6
Reporter: David Bosschaert
 Fix For: bundlerepository-2.0.8


The OSGi repository spec defines capabilities that a bundlerepository 
implementation should provide. They are:

{code}Provide-Capability: osgi.implementation;
  osgi.implementation="osgi.repository";
  uses:="org.osgi.service.repository";
  version:Version="1.1"
{code} and 
{code}Provide-Capability: osgi.service;
  objectClass:List="org.osgi.service.repository.Repository";
  uses:="org.osgi.service.repository"{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5065) Coordinator should provide osgi.service capability

[David Bosschaert (JIRA)]

David Bosschaert created FELIX-5065:
---

 Summary: Coordinator should provide osgi.service capability
 Key: FELIX-5065
 URL: https://issues.apache.org/jira/browse/FELIX-5065
 Project: Felix
  Issue Type: Bug
  Components: Coordinator Service
Affects Versions: coordinator-1.0.0
Reporter: David Bosschaert
 Fix For: coordinator-1.0.2


The OSGi specs define an osgi.service capability that should be defined by 
bundles that provide a service. The coordinator service should provide this 
capability. It should be like this:

{code}Provide-Capability: osgi.service; 
objectClass:List=org.osgi.service.coordinator.Coordinator; 
uses:=org.osgi.service.coordinator{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Felix Framework release sometime soon?

[Karl Pauls]

sure. Ill have a look at it on the weekend if nothing pops up until then.

regards,

Karl

On Wednesday, October 7, 2015, David Bosschaert 
wrote:

> Hi all,
>
> A number of important improvements have been made to the Felix
> Framework code base [1]. I think it would be good to do a 5.4.0
> release some time soon. Do others agree?
>
> Karl, would you be available to cut a release again?
>
> Many thanks and best regards,
>
> David
>
> [1]
> https://issues.apache.org/jira/browse/FELIX-5034?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20framework-5.4.0%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Re: Felix Framework release sometime soon?

[Jean-Baptiste Onofré]

Agree !

Regards
JB

On 10/07/2015 11:58 AM, David Bosschaert wrote:

Hi all,

A number of important improvements have been made to the Felix
Framework code base [1]. I think it would be good to do a 5.4.0
release some time soon. Do others agree?

Karl, would you be available to cut a release again?

Many thanks and best regards,

David

[1] 
https://issues.apache.org/jira/browse/FELIX-5034?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20framework-5.4.0%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Felix Framework release sometime soon?

[David Bosschaert]

Hi all,

A number of important improvements have been made to the Felix
Framework code base [1]. I think it would be good to do a 5.4.0
release some time soon. Do others agree?

Karl, would you be available to cut a release again?

Many thanks and best regards,

David

[1] 
https://issues.apache.org/jira/browse/FELIX-5034?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20framework-5.4.0%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

[jira] [Resolved] (FELIX-5049) Resolver does not choose the revision with the lowest bundle ID

[David Bosschaert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert resolved FELIX-5049.
-
Resolution: Invalid

Given the above discussion I'm closing this bug as invalid.

> Resolver does not choose the revision with the lowest bundle ID
> ---
>
> Key: FELIX-5049
> URL: https://issues.apache.org/jira/browse/FELIX-5049
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: framework-5.2.0
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: felix-5049.diff
>
>
> The Felix Resolver does not pick the exporting bundle with the lowest bundle 
> ID when multiple bundles export the same package. This causes 
> [ARIES-1398|https://issues.apache.org/jira/browse/ARIES-1398]. For steps on 
> how to reproduce see that issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)