[ANN] Pierre De Rop added to the PMC
Hi all, Due to his sustained interest in the Apache Felix project and his continued contributions to various sub projects, the Apache Felix PMC decided to invite Pierre De Rop to become a member of the Apache Felix PMC. An invitation Pierre accepted. Congratulations, Pierre, and thank you very much for your support. Keep up the good work ! Regards Felix
[jira] [Resolved] (FELIX-3772) maven-bundle-plugin does not scan blueprint in workspace outside default location
[
https://issues.apache.org/jira/browse/FELIX-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-3772.
-
Resolution: Fixed
Fixed in r1412405 please test latest 2.4.0-SNAPSHOT from
https://repository.apache.org/content/groups/snapshots/ or build plugin locally
> maven-bundle-plugin does not scan blueprint in workspace outside default
> location
> -
>
> Key: FELIX-3772
> URL: https://issues.apache.org/jira/browse/FELIX-3772
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
> Environment: Windows 7, Maven 3.0.4
>Reporter: Rigas Grigoropoulos
>Priority: Minor
>
> maven-bundle-plugin will not scan blueprint xml files in the workspace during
> a Maven build, unless the blueprint file is located at OSGI-INF/blueprint/
> and an instruction "Bundle-Blueprint: OSGI-INF/blueprint" is provided.
> The bug is in org.apache.felix.bundleplugin.BlueprintPlugin and in method
> analyzeJar.
> Original code:
> String bpHeader = analyzer.getProperty( "Bundle-Blueprint",
> "OSGI-INF/blueprint" );
> Map> map = Processor.parseHeader(
> bpHeader, null );
> for ( String root : map.keySet() )
> {
> Jar jar = analyzer.getJar();
> Map dir = jar.getDirectories().get( root );
> if ( dir == null || dir.isEmpty() )
> {
> Resource resource = jar.getResource( root );
> if ( resource != null )
> process( analyzer, root, resource, headers );
> return false;
> }
> This code reads a custom location from the Bundle-Blueprint instruction,
> locates the resource in the classpath and does the processing, but then just
> returns false.
> Changing as follows fixes the problem:
>if ( resource != null )
> process( analyzer, root, resource, headers );
> continue;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3772) maven-bundle-plugin does not scan blueprint in workspace outside default location
[
https://issues.apache.org/jira/browse/FELIX-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502507#comment-13502507
]
Stuart McCulloch commented on FELIX-3772:
-
May also be related to FELIX-3602 (fixed in trunk and deployed in latest
2.4.0-SNAPSHOT)
> maven-bundle-plugin does not scan blueprint in workspace outside default
> location
> -
>
> Key: FELIX-3772
> URL: https://issues.apache.org/jira/browse/FELIX-3772
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
> Environment: Windows 7, Maven 3.0.4
>Reporter: Rigas Grigoropoulos
>Priority: Minor
>
> maven-bundle-plugin will not scan blueprint xml files in the workspace during
> a Maven build, unless the blueprint file is located at OSGI-INF/blueprint/
> and an instruction "Bundle-Blueprint: OSGI-INF/blueprint" is provided.
> The bug is in org.apache.felix.bundleplugin.BlueprintPlugin and in method
> analyzeJar.
> Original code:
> String bpHeader = analyzer.getProperty( "Bundle-Blueprint",
> "OSGI-INF/blueprint" );
> Map> map = Processor.parseHeader(
> bpHeader, null );
> for ( String root : map.keySet() )
> {
> Jar jar = analyzer.getJar();
> Map dir = jar.getDirectories().get( root );
> if ( dir == null || dir.isEmpty() )
> {
> Resource resource = jar.getResource( root );
> if ( resource != null )
> process( analyzer, root, resource, headers );
> return false;
> }
> This code reads a custom location from the Bundle-Blueprint instruction,
> locates the resource in the classpath and does the processing, but then just
> returns false.
> Changing as follows fixes the problem:
>if ( resource != null )
> process( analyzer, root, resource, headers );
> continue;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502487#comment-13502487
]
Stuart McCulloch commented on FELIX-3407:
-
Specifically:
https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-bundle-plugin/2.4.0-SNAPSHOT/
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> Import-Package:
> example.a.one;version="[1.0,2)",org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> Import-Service:
> example.c.ExampleExtendedInterfaceA;multiple:=true;availability:=optional
> Tool: Bnd-1.50.0
> The "example.a.two" package import is missing since type-erasure removes the
> generic part of ExampleInterfaceA in the bundle-c interface.
> This results in a NoClassDefFondError of example.a.two.ExampleInterfaceB from
> bundle-c when trying to deploy bundle-d.
> "Error tracking new service reference java.lang.NoClassDefFoundError:
> example.a.two.ExampleInterfaceB not found by example.bundle-c [159]"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502485#comment-13502485
]
Stuart McCulloch commented on FELIX-3407:
-
The latest 2.4.0-SNAPSHOT is available from
https://repository.apache.org/content/groups/snapshots/ - I regularly deploy
snapshots based on the latest bnd code. Once the current development version of
bnd is released and available on Maven central I can prepare a release of the
maven-bundle-plugin. In the meantime please test the deployed snapshot (or
build it locally) and feedback any issues.
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> Import-Package:
> example.a.one;version="[1.0,2)",org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> Import-Service:
> example.c.ExampleExtendedInterfaceA;multiple:=true;availability:=optional
> Tool: Bnd-1.50.0
> The "example.a.two" package import is missing since type-erasure removes the
> generic part of ExampleInterfaceA in the bundle-c interface.
> This results in a NoClassDefFondError of example.a.two.ExampleInterfaceB from
> bundle-c when trying to deploy bundle-d.
> "Error tracking new service reference java.lang.NoClassDefFoundError:
> example.a.two.ExampleInterfaceB not found by example.bundle-c [159]"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3773) WebConsole uses library with ASL-incompatible licence
[ https://issues.apache.org/jira/browse/FELIX-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502290#comment-13502290 ] Gert Vanthienen commented on FELIX-3773: According to http://www.apache.org/legal/resolved.html#json, it looks like the use of this library has been approved by the legal@ team > WebConsole uses library with ASL-incompatible licence > - > > Key: FELIX-3773 > URL: https://issues.apache.org/jira/browse/FELIX-3773 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Neil Bartlett >Priority: Critical > > WebConsole uses the JSON library from json.org that contains the following > term in its licence (http://www.json.org/license.html): > "The Software shall be used for Good, not Evil." > I believe that this restriction is incompatible with the ASL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (FELIX-3773) WebConsole uses library with ASL-incompatible licence
It is my understanding that this is not an issue as long as none of the licenses is viral (that nor this license nor ASL is) -lucas On Wed, Nov 21, 2012 at 5:07 PM, Neil Bartlett (JIRA) wrote: > Neil Bartlett created FELIX-3773: > > > Summary: WebConsole uses library with ASL-incompatible licence > Key: FELIX-3773 > URL: https://issues.apache.org/jira/browse/FELIX-3773 > Project: Felix > Issue Type: Bug > Components: Web Console > Reporter: Neil Bartlett > Priority: Critical > > > WebConsole uses the JSON library from json.org that contains the > following term in its licence (http://www.json.org/license.html): > > "The Software shall be used for Good, not Evil." > > I believe that this restriction is incompatible with the ASL. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
[jira] [Created] (FELIX-3773) WebConsole uses library with ASL-incompatible licence
Neil Bartlett created FELIX-3773: Summary: WebConsole uses library with ASL-incompatible licence Key: FELIX-3773 URL: https://issues.apache.org/jira/browse/FELIX-3773 Project: Felix Issue Type: Bug Components: Web Console Reporter: Neil Bartlett Priority: Critical WebConsole uses the JSON library from json.org that contains the following term in its licence (http://www.json.org/license.html): "The Software shall be used for Good, not Evil." I believe that this restriction is incompatible with the ASL. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULT] [VOTE] Release Apache Felix Web Console 4.0.0 and plugins
Sorry so late to this thread, recently realized I could search my mail for "httplite". I will look into addressing this bug shortly. Thanks ken On Sun, Jun 10, 2012 at 8:18 PM, Felix Meschberger wrote: > And with the correct subject: > > Am 10.06.2012 um 20:13 schrieb Felix Meschberger: > > > Hi > > > > Time to tally the vote: > > > > +1 Felix Meschberger*, Richard Hall*, Jamie Goodyear, > > Carsten Ziegeler*, Karl Pauls*, Alex Karasulu*, > > Clement Escoffier*, Pierre de Rop > > 0 - > > -1 - > > > > Thus this release passes with 8 +1 votes (6 of which binding). No other > votes have been cast. > > > > I will now publish the artifacts and add them to down load page. > > > > Re "No changelog in OBR plugin": This has been added to SVN in the > meantime and will be in the next release. > > > > Re "Failure on httplite": I tend to think that this really comes from > httplite. Nevertheless, if this is really a problem of the Web Console, it > will be fixed in the next release. > > > > Regards > > Felix > > > > Am 01.06.2012 um 11:45 schrieb Felix Meschberger: > > > >> Hi, > >> > >> This is a large vote on the Web Console and a number of plugins > extracted from the web console or updated since the last release. > >> > >> I bumped the Web Console to version 4 because it now only comes in the > "bare" variant. That is the JSON and Commons FileUpload dependencies are > not part of the Web Console bundle any longer and must be installed > separately. For JSON, the Geronimo JSON bundle may be used while the > Commons FileUpload library already comes as a bundle. > >> > >> In addition a number of plugins have been ripped out of the Web Console > into separate bundles: DS and OBR. The Memory Usage plugin has been > updated. The Package Admin and UPnP plugins are new plugins. > >> > >> Here are the links to the JIRA fixed versions: > >> > >> Web Console 4.0.0 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316160 > >> > >> DS Plugin 1.0 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317872 > >> > >> Memory Usage Plugin 1.0.4 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12314875 > >> > >> OBR Plugin 1.0 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12317956 > >> > >> PackageAdmin Plugin 1.0.0 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12316672 > >> > >> UPnP Plugin 1.0.2 > >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12314879 > >> > >> > >> Staging repository: > >> https://repository.apache.org/content/repositories/orgapachefelix-174/ > >> > >> 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 174 /tmp/felix-staging > >> > >> Please vote to approve this release: > >> > >> [ ] +1 Approve the release > >> [ ] -1 Veto the release (please provide specific comments) > >> > >> This vote will be open for at least 72 hours (due to weekend and large > number of artifacts). > >> > >> Regards > >> Felix > > > >
[jira] [Commented] (FELIX-3739) scr-plugin: "Annotated method {0} not found"
[
https://issues.apache.org/jira/browse/FELIX-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502037#comment-13502037
]
Johannes Schneider commented on FELIX-3739:
---
The same problem occurs when there is a constructor that is annotated:
@Inject
public DefaultSerializationService(@Nonnull EntryDescriptorProviderService
entryDescriptorProviderService) {
results in: "Annoated method not found."
--> 1.8.1-SNAPSHOT does *not* fix this issue.
I strongly suggest that this is viewed as blocker since the plugin fails for
methods that are not annoated with scr-annotations.
And I suggest that the plugin does *not* fail if a method could not be found.
Instead a warning should be enough to notify the user that there might be a
problem.
Any ideas when the 1.8.1 release could happen?
> scr-plugin: "Annotated method {0} not found"
>
>
> Key: FELIX-3739
> URL: https://issues.apache.org/jira/browse/FELIX-3739
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.8.0, scr ant task 1.2.0, scr
> generator 1.2.0
> Environment: Linux, Maven 3, Java 7
>Reporter: Johannes Schneider
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.8.2, scr ant task 1.2.2, scr
> generator 1.2.2
>
>
> I run in to that[1] problem.
> The method that is not found looks like that:
> > @Nonnull public static Entry create( @Nonnull T
> > object,
> @Nonnull >byte[] expected ) {
> > }
> I have debugged this and it comes to that:
> in ClassScanner#237 parameters are compared. The second parameter of
> my method (byte[]) has a strange difference here:
> parameterTypeName: [B
> signature[index].getClassName(): byte[]
> So I think this might be related to the asm usage
> I *think* instead of "signature[index].getClassName()" there should be
> called
> signature[index].getDescriptor()
> Any idea how I could work around that problem (without changing my
> method's signature)?
> Thanks,
> Johannes
> [1]
> [ERROR] Failed to execute goal
> org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found.
> 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:601)
> 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:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found.
> at
> org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:222)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>
[jira] [Comment Edited] (FELIX-3739) scr-plugin: "Annotated method {0} not found"
[
https://issues.apache.org/jira/browse/FELIX-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502037#comment-13502037
]
Johannes Schneider edited comment on FELIX-3739 at 11/21/12 3:19 PM:
-
The same problem occurs when there is a constructor that is annotated:
@Inject
public DefaultSerializationService(@Nonnull EntryDescriptorProviderService
entryDescriptorProviderService) {
results in: "Annoated method not found."
--> 1.8.1-SNAPSHOT does *not* fix this issue.
I strongly suggest that this is viewed as blocker since the plugin fails for
methods that are not annoated with scr-annotations.
And I suggest that the plugin does *not* fail if a method could not be found.
Instead a warning should be enough to notify the user that there might be a
problem.
was (Author: j...@cedarsoft.com):
The same problem occurs when there is a constructor that is annotated:
@Inject
public DefaultSerializationService(@Nonnull EntryDescriptorProviderService
entryDescriptorProviderService) {
results in: "Annoated method not found."
--> 1.8.1-SNAPSHOT does *not* fix this issue.
I strongly suggest that this is viewed as blocker since the plugin fails for
methods that are not annoated with scr-annotations.
And I suggest that the plugin does *not* fail if a method could not be found.
Instead a warning should be enough to notify the user that there might be a
problem.
Any ideas when the 1.8.1 release could happen?
> scr-plugin: "Annotated method {0} not found"
>
>
> Key: FELIX-3739
> URL: https://issues.apache.org/jira/browse/FELIX-3739
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.8.0, scr ant task 1.2.0, scr
> generator 1.2.0
> Environment: Linux, Maven 3, Java 7
>Reporter: Johannes Schneider
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.8.2, scr ant task 1.2.2, scr
> generator 1.2.2
>
>
> I run in to that[1] problem.
> The method that is not found looks like that:
> > @Nonnull public static Entry create( @Nonnull T
> > object,
> @Nonnull >byte[] expected ) {
> > }
> I have debugged this and it comes to that:
> in ClassScanner#237 parameters are compared. The second parameter of
> my method (byte[]) has a strange difference here:
> parameterTypeName: [B
> signature[index].getClassName(): byte[]
> So I think this might be related to the asm usage
> I *think* instead of "signature[index].getClassName()" there should be
> called
> signature[index].getDescriptor()
> Any idea how I could work around that problem (without changing my
> method's signature)?
> Thanks,
> Johannes
> [1]
> [ERROR] Failed to execute goal
> org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.felix:maven-scr-plugin:1.8.0:scr
> (generate-scr-scrdescriptor) on project test-utils:
> com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
> Annotated method create not found.
> 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:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.la
[jira] [Created] (FELIX-3772) maven-bundle-plugin does not scan blueprint in workspace outside default location
Rigas Grigoropoulos created FELIX-3772:
--
Summary: maven-bundle-plugin does not scan blueprint in workspace
outside default location
Key: FELIX-3772
URL: https://issues.apache.org/jira/browse/FELIX-3772
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.3.7
Environment: Windows 7, Maven 3.0.4
Reporter: Rigas Grigoropoulos
Priority: Minor
maven-bundle-plugin will not scan blueprint xml files in the workspace during a
Maven build, unless the blueprint file is located at OSGI-INF/blueprint/ and an
instruction "Bundle-Blueprint: OSGI-INF/blueprint" is provided.
The bug is in org.apache.felix.bundleplugin.BlueprintPlugin and in method
analyzeJar.
Original code:
String bpHeader = analyzer.getProperty( "Bundle-Blueprint",
"OSGI-INF/blueprint" );
Map> map = Processor.parseHeader( bpHeader,
null );
for ( String root : map.keySet() )
{
Jar jar = analyzer.getJar();
Map dir = jar.getDirectories().get( root );
if ( dir == null || dir.isEmpty() )
{
Resource resource = jar.getResource( root );
if ( resource != null )
process( analyzer, root, resource, headers );
return false;
}
This code reads a custom location from the Bundle-Blueprint instruction,
locates the resource in the classpath and does the processing, but then just
returns false.
Changing as follows fixes the problem:
if ( resource != null )
process( analyzer, root, resource, headers );
continue;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501822#comment-13501822
]
Tomas Forsman commented on FELIX-3407:
--
Is there a new version of bnd available?
If so, when could this be available in the maven-bundle-plugin?
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> Import-Package:
> example.a.one;version="[1.0,2)",org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> Import-Service:
> example.c.ExampleExtendedInterfaceA;multiple:=true;availability:=optional
> Tool: Bnd-1.50.0
> The "example.a.two" package import is missing since type-erasure removes the
> generic part of ExampleInterfaceA in the bundle-c interface.
> This results in a NoClassDefFondError of example.a.two.ExampleInterfaceB from
> bundle-c when trying to deploy bundle-d.
> "Error tracking new service reference java.lang.NoClassDefFoundError:
> example.a.two.ExampleInterfaceB not found by example.bundle-c [159]"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ServiceGraph
Hi Arjun Cool. Will look into it ASAP. Regards Felix Am 20.11.2012 um 11:47 schrieb Arjun Panday: > Hi Felix, > > I committed a fix yesterday. Indeed the code is much simpler, I got rid > of the extra servlet and I didn't even need to implement getResource > since you do that for me in SimpleWebConsolePlugin. > > Maybe you want to have a quick look and tell me if you think I missed > something? > > Should I close the JIRA once the commit is available in the trunk or > when the release is out? > > Thanks, > Arjun > > > Felix Meschberger wrote: >> Hi Arjun, >> >> Sounds great. If you need some more help, just get back to the list. >> >> Regards >> Felix >> >> Am 19.11.2012 um 11:29 schrieb Arjun Panday: >> >> >>> Thank you Felix, >>> >>> I'm afraid my integration with WebConsolePlugin dates a bit and I >>> probably already missed some points at the time. >>> I should probably try to fix this myself to update my understanding of >>> the webconsole! >>> >>> I was about to attempt a new release anyway. >>> >>> /Arjun >>> >>> >>> Felix Meschberger wrote: >>> Hi I tried to tackle FELIX-3764 [1] just to realize that this plugin IMHO is not properly integrated with the web console: * registers a /servicegraph/json servlet * registers /servicegraphe resources The problem with this is, that it doesn't account for non-root servlet contexts, is not integrated with the URL space and does not leverage the Web Console access control mechanisms. I suggest to change this plugin as follows: * Handle the .../json request as part of the WebConsolePlugin.service method * Implement a URL getResource [2] method in the WebConsolePlugin class This allows for full integration, leveraging access control and URL space integration plus also allows for using the appRoot and pluginRoot Web Console properties [3]. Does this make sense ? Regards Felix [1] https://issues.apache.org/jira/browse/FELIX-3764 [2] http://felix.apache.org/site/providing-resources.html [3] http://felix.apache.org/site/providing-web-console-plugins.html >> >> >
[jira] [Created] (FELIX-3771) Regression fixed at FELIX-971 is reintroduced at FELIX-3082
Tuomas Kiviaho created FELIX-3771: - Summary: Regression fixed at FELIX-971 is reintroduced at FELIX-3082 Key: FELIX-3771 URL: https://issues.apache.org/jira/browse/FELIX-3771 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.2 Reporter: Tuomas Kiviaho Priority: Minor I got similar stacktrace that was listed at FELIX-971 and checked the Fisheye for how it was fixed. I discovered that FELIX-3082 reverted the fix thus making ServiceTrackers fail again at removedService. This happens to me when framework is exited before bundles are closed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
