[jira] [Created] (FELIX-4517) Generate generic capabilities for services from blueprint and scr descriptors
Guillaume Nodet created FELIX-4517: -- Summary: Generate generic capabilities for services from blueprint and scr descriptors Key: FELIX-4517 URL: https://issues.apache.org/jira/browse/FELIX-4517 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-2.4.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4517) Generate generic capabilities and requirements for services from blueprint and scr descriptors
[ https://issues.apache.org/jira/browse/FELIX-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-4517: --- Summary: Generate generic capabilities and requirements for services from blueprint and scr descriptors (was: Generate generic capabilities for services from blueprint and scr descriptors) Generate generic capabilities and requirements for services from blueprint and scr descriptors -- Key: FELIX-4517 URL: https://issues.apache.org/jira/browse/FELIX-4517 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-2.4.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4517) Generate generic capabilities and requirements for services from blueprint and scr descriptors
[ https://issues.apache.org/jira/browse/FELIX-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-4517. Resolution: Fixed Committing to https://svn.apache.org/repos/asf/felix/trunk ... A bundleplugin/src/main/java/org/apache/felix/bundleplugin/ScrPlugin.java A bundleplugin/src/main/resources/org/apache/felix/bundleplugin/scr.xsl M bundleplugin/pom.xml M bundleplugin/src/main/java/org/apache/felix/bundleplugin/BlueprintPlugin.java M bundleplugin/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java M bundleplugin/src/main/resources/org/apache/felix/bundleplugin/blueprint.xsl M bundleplugin/src/test/java/org/apache/felix/bundleplugin/BlueprintComponentTest.java Committed r1595765 Generate generic capabilities and requirements for services from blueprint and scr descriptors -- Key: FELIX-4517 URL: https://issues.apache.org/jira/browse/FELIX-4517 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-2.4.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Handling of provisional OSGi API?
The change and your proposal. It seems to restrictive to not allow coding against API that are being developped when not planning to release the project before the API is. 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status=provisional`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml Export-Package org.apache.felix.service.metatype; version=0.1; mandatory=status; status=provisional /Export-Package When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? That the policy stay the same? Change? On May 16, 2014, at 7:56 PM, Richard S. Hall he...@ungoverned.org wrote: On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. I believe we did have this issue with the Config Admin RI and somehow we managed. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no matter what package it's moved to and how provisional it's marked, but it's ok to have unreleased org.osgi packages in source as long as either the spec gets released before any felix release is made or they are removed before any felix release is made. I don't think we can leave policy as a recommendation, because then it still leaves it up to whomever to decide. Again, I don't have an issue with saying it is okay in source form, but not in a released artifact. My next DS commits add the DTO stuff, so unless the policy is changed they will have to wait on github for a while. So, make a modified policy proposal and put it up for comments and ultimately a vote. - richard thanks david jencks On May 16, 2014, at 2:24 PM, Richard S. Hall he...@ungoverned.org wrote: There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should
Re: Handling of provisional OSGi API?
I did not read David’s proposal that way. I think he is saying: YES, you can code against an API that is under development, as long as you do not do any releases (before the API is finalized). So only if you want to do a release before the API is finalized do you need to package it under the Felix namespace and deprecate it (with a provisional status). The only downside I see is that, from the OSGi Alliance point of view, they are getting less “real world” use of their reference implementations while they are being developed, because this policy makes it impractical to use (in production) any API that is still under development. On the other hand, it’s not too hard for someone to write a small component that publishes such an API itself and “bridges” to the artifact that our project released. I think that’s actually a reasonable compromise. Personally, I could also live with a policy that only requires us to put the API in the Felix namespace (and not mark it deprecated or anything). Once an artifact has been released, it’s out there anyway. On the other hand, those extras are not in anybody’s way and they do serve as a warning, so I’m not going to make an argument that we must remove them. Greetings, Marcel On 19 May 2014, at 9:24 , Guillaume Nodet gno...@apache.org wrote: The change and your proposal. It seems to restrictive to not allow coding against API that are being developped when not planning to release the project before the API is. 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status=provisional`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml Export-Package org.apache.felix.service.metatype; version=0.1; mandatory=status; status=provisional /Export-Package When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? That the policy stay the same? Change? On May 16, 2014, at 7:56 PM, Richard S. Hall he...@ungoverned.org wrote: On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. I believe we did have this issue with the Config Admin RI and somehow we managed. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no
Re: Handling of provisional OSGi API?
On 5/16/14, 20:43 , David Jencks wrote: for instance, debugging the conformance test suite will be more or less impossible, Yep, if you're writing an RI in Felix and this RI needs to run as part of the OSGi CT, it will only work if it uses the official OSGi API. As an example take an OSGi CT that looks for a whiteboard service that implements the org.osgi.service.http.runtime.HttpServiceRuntime interface. The CT will not find the implementation if it's renamed to org.apache.felix...something. So at least to test the RI as part of the CT you need the real API. BTW I think it would be good if this policy could also apply to new versions of an existing API. E.g. it should also be usable when we move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? Cheers, David On 19 May 2014 10:05, Marcel Offermans marcel.offerm...@luminis.nl wrote: I did not read David’s proposal that way. I think he is saying: YES, you can code against an API that is under development, as long as you do not do any releases (before the API is finalized). So only if you want to do a release before the API is finalized do you need to package it under the Felix namespace and deprecate it (with a provisional status). The only downside I see is that, from the OSGi Alliance point of view, they are getting less “real world” use of their reference implementations while they are being developed, because this policy makes it impractical to use (in production) any API that is still under development. On the other hand, it’s not too hard for someone to write a small component that publishes such an API itself and “bridges” to the artifact that our project released. I think that’s actually a reasonable compromise. Personally, I could also live with a policy that only requires us to put the API in the Felix namespace (and not mark it deprecated or anything). Once an artifact has been released, it’s out there anyway. On the other hand, those extras are not in anybody’s way and they do serve as a warning, so I’m not going to make an argument that we must remove them. Greetings, Marcel On 19 May 2014, at 9:24 , Guillaume Nodet gno...@apache.org wrote: The change and your proposal. It seems to restrictive to not allow coding against API that are being developped when not planning to release the project before the API is. 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status=provisional`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml Export-Package org.apache.felix.service.metatype; version=0.1; mandatory=status; status=provisional /Export-Package When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep
Re: Handling of provisional OSGi API?
Hello David, On 19 May 2014, at 10:22 , David Bosschaert david.bosscha...@gmail.com wrote: On 5/16/14, 20:43 , David Jencks wrote: for instance, debugging the conformance test suite will be more or less impossible, Yep, if you're writing an RI in Felix and this RI needs to run as part of the OSGi CT, it will only work if it uses the official OSGi API. As an example take an OSGi CT that looks for a whiteboard service that implements the org.osgi.service.http.runtime.HttpServiceRuntime interface. The CT will not find the implementation if it's renamed to org.apache.felix...something. So at least to test the RI as part of the CT you need the real API. You do, but as far as I know you do not need a release (in the Apache sense of the word, meaning source code) for that as the OSGi CT only requires you to submit a binary artifact. And that can easily be produced without doing any kind of release (and should, because it’s not for public consumption usually). BTW I think it would be good if this policy could also apply to new versions of an existing API. E.g. it should also be usable when we move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? This policy already applies to new versions of an existing API, right? Greetings, Marcel Cheers, David On 19 May 2014 10:05, Marcel Offermans marcel.offerm...@luminis.nl wrote: I did not read David’s proposal that way. I think he is saying: YES, you can code against an API that is under development, as long as you do not do any releases (before the API is finalized). So only if you want to do a release before the API is finalized do you need to package it under the Felix namespace and deprecate it (with a provisional status). The only downside I see is that, from the OSGi Alliance point of view, they are getting less “real world” use of their reference implementations while they are being developed, because this policy makes it impractical to use (in production) any API that is still under development. On the other hand, it’s not too hard for someone to write a small component that publishes such an API itself and “bridges” to the artifact that our project released. I think that’s actually a reasonable compromise. Personally, I could also live with a policy that only requires us to put the API in the Felix namespace (and not mark it deprecated or anything). Once an artifact has been released, it’s out there anyway. On the other hand, those extras are not in anybody’s way and they do serve as a warning, so I’m not going to make an argument that we must remove them. Greetings, Marcel On 19 May 2014, at 9:24 , Guillaume Nodet gno...@apache.org wrote: The change and your proposal. It seems to restrictive to not allow coding against API that are being developped when not planning to release the project before the API is. 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status=provisional`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml Export-Package
Re: Handling of provisional OSGi API?
On 19 May 2014 10:54, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello David, On 19 May 2014, at 10:22 , David Bosschaert david.bosscha...@gmail.com wrote: On 5/16/14, 20:43 , David Jencks wrote: for instance, debugging the conformance test suite will be more or less impossible, Yep, if you're writing an RI in Felix and this RI needs to run as part of the OSGi CT, it will only work if it uses the official OSGi API. As an example take an OSGi CT that looks for a whiteboard service that implements the org.osgi.service.http.runtime.HttpServiceRuntime interface. The CT will not find the implementation if it's renamed to org.apache.felix...something. So at least to test the RI as part of the CT you need the real API. You do, but as far as I know you do not need a release (in the Apache sense of the word, meaning source code) for that as the OSGi CT only requires you to submit a binary artifact. And that can easily be produced without doing any kind of release (and should, because it’s not for public consumption usually). Yep, correct. When OSGi releases the RIs and CTs they do want to be able to correlate an RI binary to a commit in the source code tree (e.g. by mentioning a tag or commit ID in the manifest), but it doesn't have to be an official release. BTW I think it would be good if this policy could also apply to new versions of an existing API. E.g. it should also be usable when we move the Core API from 1.7 to 1.8 for Core R6. Thought anyone? This policy already applies to new versions of an existing API, right? Great. Cheers, David
Re: Handling of provisional OSGi API?
+1 sounds good to me 2014-05-17 9:37 GMT+02:00 David Jencks david_jen...@yahoo.com: I propose we change the provisional api policy page http://felix.apache.org/documentation/development/provisional-osgi-api-policy.htmlto this (markdown source): The OSGi Alliance exposes provisional API that may or may not become part of future OSGI specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification. ## Policy 1. No Felix release may contain or refer to provisional OSGI API. 1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGI specification before this felix source may be released. 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications: 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API. 1. All Felix provisional API must be marked as deprecated. 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status=provisional`. ## Discussion The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and eventual osgi release and bundle version inflation if the felix provisional api is removed after the OSGI API is released. As an example, to provisionally export the `org.apache.felix.service.metatype` package, the `Export-Package` statement would look something like this: :::xml Export-Package org.apache.felix.service.metatype; version=0.1; mandatory=status; status=provisional /Export-Package When working with new OSGI specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace. Comments? thanks david jencks ps. JB, Guillaume, what exactly are you +1ing? That we keep talking? That the policy stay the same? Change? On May 16, 2014, at 7:56 PM, Richard S. Hall he...@ungoverned.org wrote: On 5/16/14, 20:43 , David Jencks wrote: You have a point about specs that don't get released. And in such a circumstance having something released with org.osgi packages marked provisional would be sort of a disaster. But if a felix subproject is going to be an osgi ri, it really needs to be developed with the right package names. Otherwise, for instance, debugging the conformance test suite will be more or less impossible, as well as making running the ri against the ct implausible. I believe we did have this issue with the Config Admin RI and somehow we managed. So I think I'd like the policy to say (sub) projects are strongly discouraged from releasing anything with a non released osgi spec api no matter what package it's moved to and how provisional it's marked, but it's ok to have unreleased org.osgi packages in source as long as either the spec gets released before any felix release is made or they are removed before any felix release is made. I don't think we can leave policy as a recommendation, because then it still leaves it up to whomever to decide. Again, I don't have an issue with saying it is okay in source form, but not in a released artifact. My next DS commits add the DTO stuff, so unless the policy is changed they will have to wait on github for a while. So, make a modified policy proposal and put it up for comments and ultimately a vote. - richard thanks david jencks On May 16, 2014, at 2:24 PM, Richard S. Hall he...@ungoverned.org wrote: There was thought that went into that policy, it wasn't just pulled out of the air...further, from experience of working on that specs that didn't make the cut (original OBR and Gogo), I can say the policy does a good job of avoiding the confusion/complication created in those cases. So, working around the policy based on personal whim, doesn't seem like a good idea...that sort of makes it not a policy. However, all policies can be improved. You could argue that the policy should simply be modified, as David suggests, to say only released subprojects must not contain provisional API. I'd personally be fine with that, but such a
[jira] [Commented] (FELIX-4145) bundleall goal failure
[ https://issues.apache.org/jira/browse/FELIX-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001622#comment-14001622 ] NeMewSys commented on FELIX-4145: - Guys... Bundleall is deprecated but what else do we have left? Please can you post an answer here? http://stackoverflow.com/questions/23737169/managing-osgi-dependency-hell Thanks! bundleall goal failure -- Key: FELIX-4145 URL: https://issues.apache.org/jira/browse/FELIX-4145 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.4.0 Environment: Linux 64-bit, Oracle JDK 1.7.0_25-b15, Apache Maven 3.0.4 Reporter: Amichai Rothman When running the bundleall goaI in version 2.4.0 I get the error below. If I revert to 2.3.7 (and change nothing else) everything works ok. [ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:2.4.0:bundleall (default-cli) on project myproject: Error generating OSGi bundle for project org.apache.geronimo.specs:geronimo-jms_1.1_spec: aQute.bnd.osgi.Descriptors$PackageRef cannot be cast to java.lang.String - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.felix:maven-bundle-plugin:2.4.0:bundleall (default-cli) on project myproject: Error generating OSGi bundle for project org.apache.geronimo.specs:geronimo-jms_1.1_spec at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error generating OSGi bundle for project org.apache.geronimo.specs:geronimo-jms_1.1_spec at org.apache.felix.bundleplugin.BundleAllPlugin.bundle(BundleAllPlugin.java:399) at org.apache.felix.bundleplugin.BundleAllPlugin.bundleRoot(BundleAllPlugin.java:322) at org.apache.felix.bundleplugin.BundleAllPlugin.bundleAll(BundleAllPlugin.java:213) at org.apache.felix.bundleplugin.BundleAllPlugin.bundleAll(BundleAllPlugin.java:289) at org.apache.felix.bundleplugin.BundleAllPlugin.bundleAll(BundleAllPlugin.java:289) at org.apache.felix.bundleplugin.BundleAllPlugin.bundleAll(BundleAllPlugin.java:170) at org.apache.felix.bundleplugin.BundleAllPlugin.execute(BundleAllPlugin.java:157) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: java.lang.ClassCastException: aQute.bnd.osgi.Descriptors$PackageRef cannot be cast to java.lang.String at org.apache.felix.bundleplugin.BundleAllPlugin.addExportedPackages(BundleAllPlugin.java:420) at org.apache.felix.bundleplugin.BundleAllPlugin.bundle(BundleAllPlugin.java:388) ... 27 more -- This message was sent by Atlassian JIRA (v6.2#6252)
[VOTE] SCR Tooling Release
Hi, This vote is about adding java 8 support to our SCR tool chain. https://issues.apache.org/jira/browse/FELIX-4461 It consists of the following releases: SCR Generator 1.10.0 Maven SCR Plugin 1.17.0 SCR Ant Task 1.11.0 Bnd SCR Plugin 1.1.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1018/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1018 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] SCR Tooling Release
+1 Carsten 2014-05-19 14:15 GMT+02:00 Carsten Ziegeler cziege...@apache.org: Hi, This vote is about adding java 8 support to our SCR tool chain. https://issues.apache.org/jira/browse/FELIX-4461 It consists of the following releases: SCR Generator 1.10.0 Maven SCR Plugin 1.17.0 SCR Ant Task 1.11.0 Bnd SCR Plugin 1.1.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1018/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1018 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open for 72 hours. Regards Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool
[
https://issues.apache.org/jira/browse/FELIX-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001695#comment-14001695
]
Carsten Ziegeler commented on FELIX-4512:
-
It seems that the update of bnd is causing new headers to be created
automatically:
Provide-Capability and Require-Capability and in one project I get now the error
osgi.service osgi.service must have the objectClass attribute set
Add a new Mojo to invoke the BND Baseline tool
--
Key: FELIX-4512
URL: https://issues.apache.org/jira/browse/FELIX-4512
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
Assignee: Carsten Ziegeler
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-4512.1.patch, FELIX-4512.2.patch,
FELIX-4512.patch, Screen Shot 2014-05-13 at 11.49.44 PM.pdf
The BND 2.2.0 library contains an extraordinary tool called
[Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph)
that compares the public API of a bundle with the public API of another
bundle.
It would be really useful to have this tool in the {{maven-bundle-plugin}} in
order to keep track of APIs modifications during development time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool
[
https://issues.apache.org/jira/browse/FELIX-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001704#comment-14001704
]
Simone Tripodi commented on FELIX-4512:
---
Is it related to the {{bundle}} plugin, or the {{baseline}} one? The first, I
guess... :(
Add a new Mojo to invoke the BND Baseline tool
--
Key: FELIX-4512
URL: https://issues.apache.org/jira/browse/FELIX-4512
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
Assignee: Carsten Ziegeler
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-4512.1.patch, FELIX-4512.2.patch,
FELIX-4512.patch, Screen Shot 2014-05-13 at 11.49.44 PM.pdf
The BND 2.2.0 library contains an extraordinary tool called
[Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph)
that compares the public API of a bundle with the public API of another
bundle.
It would be really useful to have this tool in the {{maven-bundle-plugin}} in
order to keep track of APIs modifications during development time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool
[
https://issues.apache.org/jira/browse/FELIX-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001733#comment-14001733
]
Carsten Ziegeler commented on FELIX-4512:
-
Yes, right - it's related to the bundle plugin
Add a new Mojo to invoke the BND Baseline tool
--
Key: FELIX-4512
URL: https://issues.apache.org/jira/browse/FELIX-4512
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
Assignee: Carsten Ziegeler
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-4512.1.patch, FELIX-4512.2.patch,
FELIX-4512.patch, Screen Shot 2014-05-13 at 11.49.44 PM.pdf
The BND 2.2.0 library contains an extraordinary tool called
[Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph)
that compares the public API of a bundle with the public API of another
bundle.
It would be really useful to have this tool in the {{maven-bundle-plugin}} in
order to keep track of APIs modifications during development time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool
[
https://issues.apache.org/jira/browse/FELIX-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001750#comment-14001750
]
Simone Tripodi commented on FELIX-4512:
---
I stumbled in a Bnd [issue|https://github.com/bndtools/bnd/issues/413] where it
is stated that {{Require-Capability}} should be automatically generated only
for _osgi.ee_... WDYT?
Add a new Mojo to invoke the BND Baseline tool
--
Key: FELIX-4512
URL: https://issues.apache.org/jira/browse/FELIX-4512
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
Assignee: Carsten Ziegeler
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-4512.1.patch, FELIX-4512.2.patch,
FELIX-4512.patch, Screen Shot 2014-05-13 at 11.49.44 PM.pdf
The BND 2.2.0 library contains an extraordinary tool called
[Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph)
that compares the public API of a bundle with the public API of another
bundle.
It would be really useful to have this tool in the {{maven-bundle-plugin}} in
order to keep track of APIs modifications during development time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[DS] Various factory component issues, and progress on RFC 190
Hi, I've been working on implementing the proposed rfc 190 changes to DS in felix scr. I've committed some work and have most of the DTO and multiple pid support implemented locally. The major bits I haven't started on yet are configuration through annotations and scope support (for exposed services and for references). I don't expect either of these to be particularly difficult, but then I haven't started. There are some difficulties with factory components and DTO/mutliple pid support. In terms of the spec, DTO and factory components don't work well together, see bug 2683 (I'm not sure how visible this is to non-osgi-members). In Felix, 1. I think we should not support the obsolete factory configuration newInstance-like behavior on namespace 1.3+ components. We shouldn't have supported it after namespace 1.0, but we should stop now for sure. Trying to support this with multiple pids is just too weird. 2. Because of how I implemented multiple pid support for normal components, I think it would be easy to Implement factory config multiple instances of the ComponentFactory service. I believe this behavior was requested by Pierre de Rop. There's an additional problem if you do this that you can't distinguish the ComponentFactory services registered from the multiple factory configurations. To solve this I propose that configuration properties prefixed with org.apache.felix.scr.factory. (exact string up for discussion) be added to the ComponentFactory service properties. Of course all this would have to be enabled by an flag in the xml such as felix:factoryComponentFactoryPID=true (no good ideas on this one yet). As a reminder, a few days ago I said I was about to remove the legacy configuration system entirely in favor of the spec one based on DTOs since they are conceptually incompatible and the existing one is fundamentally confused. So far no response so it's going soon…. Comments? thanks david jencks
Re: [DS] Various factory component issues, and progress on RFC 190
Hi, 2014-05-19 22:57 GMT+02:00 David Jencks david_jen...@yahoo.com: There are some difficulties with factory components and DTO/mutliple pid support. In terms of the spec, DTO and factory components don't work well together, see bug 2683 (I'm not sure how visible this is to non-osgi-members). In Felix, 1. I think we should not support the obsolete factory configuration newInstance-like behavior on namespace 1.3+ components. We shouldn't have supported it after namespace 1.0, but we should stop now for sure. Trying to support this with multiple pids is just too weird. +1, yes we should have dropped that support with earlier namespaces :( 2. Because of how I implemented multiple pid support for normal components, I think it would be easy to Implement factory config multiple instances of the ComponentFactory service. I believe this behavior was requested by Pierre de Rop. There's an additional problem if you do this that you can't distinguish the ComponentFactory services registered from the multiple factory configurations. To solve this I propose that configuration properties prefixed with org.apache.felix.scr.factory. (exact string up for discussion) be added to the ComponentFactory service properties. Of course all this would have to be enabled by an flag in the xml such as felix:factoryComponentFactoryPID=true (no good ideas on this one yet). Sounds fine to me. Would it make sense to get this into RFC190? As a reminder, a few days ago I said I was about to remove the legacy configuration system entirely in favor of the spec one based on DTOs since they are conceptually incompatible and the existing one is fundamentally confused. So far no response so it's going soon…. I agree, let's just go forward with the DTOs Carsten Comments? thanks david jencks -- Carsten Ziegeler cziege...@apache.org
[jira] [Reopened] (FELIX-4517) Generate generic capabilities and requirements for services from blueprint and scr descriptors
[ https://issues.apache.org/jira/browse/FELIX-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reopened FELIX-4517: - Generate generic capabilities and requirements for services from blueprint and scr descriptors -- Key: FELIX-4517 URL: https://issues.apache.org/jira/browse/FELIX-4517 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-2.4.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4517) Generate generic capabilities and requirements for services from blueprint and scr descriptors
[ https://issues.apache.org/jira/browse/FELIX-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002820#comment-14002820 ] Carsten Ziegeler commented on FELIX-4517: - With this enabled, I now get errors in projects like osgi.service osgi.service must have the objectClass attribute set These projects were working/building fine before. Is there any switch to enable/disable this feature? Generate generic capabilities and requirements for services from blueprint and scr descriptors -- Key: FELIX-4517 URL: https://issues.apache.org/jira/browse/FELIX-4517 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-2.4.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool
[
https://issues.apache.org/jira/browse/FELIX-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002821#comment-14002821
]
Carsten Ziegeler commented on FELIX-4512:
-
This is actually not caused by this issue but by FELIX-4517
Add a new Mojo to invoke the BND Baseline tool
--
Key: FELIX-4512
URL: https://issues.apache.org/jira/browse/FELIX-4512
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
Assignee: Carsten Ziegeler
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-4512.1.patch, FELIX-4512.2.patch,
FELIX-4512.patch, Screen Shot 2014-05-13 at 11.49.44 PM.pdf
The BND 2.2.0 library contains an extraordinary tool called
[Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph)
that compares the public API of a bundle with the public API of another
bundle.
It would be really useful to have this tool in the {{maven-bundle-plugin}} in
order to keep track of APIs modifications during development time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
