[jira] [Updated] (FELIX-4010) SCR Plugin aborts when scanning a Java 8 class file
[ https://issues.apache.org/jira/browse/FELIX-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4010: Fix Version/s: scr generator 1.8.2 scr ant task 1.9.0 maven-scr-plugin 1.14.2 SCR Plugin aborts when scanning a Java 8 class file --- Key: FELIX-4010 URL: https://issues.apache.org/jira/browse/FELIX-4010 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.11.0 Reporter: Felix Meschberger Fix For: maven-scr-plugin 1.14.2, scr ant task 1.9.0, scr generator 1.8.2 It looks like the ASM library referred to by the SCR plugin is not compatible with Java 8 class file version 52. How to reproduce: Use Java 8 to run a maven based project build where at least one of the @Component annotated classes extend (or implement) a Java 8 runtime provided class, e.g. java.io.Serializable, in class file version 52. -- 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] [Assigned] (FELIX-4010) SCR Plugin aborts when scanning a Java 8 class file
[ https://issues.apache.org/jira/browse/FELIX-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-4010: --- Assignee: Carsten Ziegeler SCR Plugin aborts when scanning a Java 8 class file --- Key: FELIX-4010 URL: https://issues.apache.org/jira/browse/FELIX-4010 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.11.0 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: maven-scr-plugin 1.14.2, scr ant task 1.9.0, scr generator 1.8.2 It looks like the ASM library referred to by the SCR plugin is not compatible with Java 8 class file version 52. How to reproduce: Use Java 8 to run a maven based project build where at least one of the @Component annotated classes extend (or implement) a Java 8 runtime provided class, e.g. java.io.Serializable, in class file version 52. -- 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: [VOTE] Release Felix HTTP v2.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/18/13 4:13 PM, Jan Willem Janssen wrote: Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) +1 (non-binding). - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRTIPAAoJEKF/mP2eHDc4eV0QAKvb2uU9QifIvMIBL7CY0nRs 3XkPcu5g1QD6Sgy4o3uvFTviYVj1Ym/i7XQby3vt957QuH92F8v+uGQZ1F1v3i/L iieDJuycPEprTnfu+22pZKw6jAEdALYgmXk9z1o3NQyBUzIsZPzKtjAdD+fn58tN CmZzuDM4mAgjBKQJpuwWiUgBwQfHd+Et9I0+GpTR8NyrBODJw6kJOTPFfhfz0Sgv aL6GmSK1AzZVEB/m7YhmlLY7oXoypgGpj9iP9lwoO6MFOlhmK/fcwtS2oGToP0l+ IRr5rSDNo3nA2dBoyAs9Bxx3yMTeaLtoYQBqV/7kt0OnDEaB1za2BZErQNLCTDTa 1ExUa/ontdw1FKo768JP4amcGFCxsfVqzrzOjV4dNFVyYNWTDxi1x6a32GlqOz3p NONQp6QyPeWxGcYkOew1XuMCI/xB+Ajl7XdFIEUooXTfnR7uQySADU0/HaGDHLyM 8biBswX0TSeTE3OpMT9y5MUrBLkGd4yS+kLxzLhQmqjq9fkfYblJi8VwtvJ+TAwr 4lGu1ilMQsIO6aW73bSMBb6N9uS7D808CksEQyG3cjAmRhWqCWGGfpxyjjrowf5d 9NoW/XzGSU0ABFIms2TntKtnN4mgWHVs3riFeh9wf6b25+QIoocNrmyLxx3f7LgV A4A2/Kkke09NOm3F1BRM =+2AB -END PGP SIGNATURE-
[RESULT] [VOTE] Release Felix HTTP v2.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The vote has passed with the following result : +1 (binding): Pierre de Rop, Felix Meschberger Rob Walker; +1 (non binding): Bram de Kruijff Jan Willem Janssen. No other votes were cast. I will copy this release to the Felix dist directory and promote the artifacts to the central Maven repository. - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSRTMgAAoJEKF/mP2eHDc4Z+QP/1j2qyC0ZVmTyENUnZAXdhrg fYKzZyBzvvwfccNIaE7w6sxmKRi5BSAuHPNXS7hR9rEbere8S5TnKEj0EsjnPh+i pvMrPwItbJmIVSdCr83nPTkGt/CgqjqoQ8mZzLDIz6EwhWaCegMyGfHrCmL6BNgU siXNrr79K8+FBDH2+iZdompCExEbX9WsMixmaPlsINz3K0A2o3TIhHX3rlVDJ0x/ tQNTDO46j1PcnGHJzylcUhv8tNz6msHjRrg7juirAAZ3FfKNSlN1GQGG4CnIsbET AsR7GxQjInjUjWJ3879Ywf+0ozyIWM1b19BAyZ7k9q36x2KDv3+YQFO0gGuNKMZa Tu67BVJJRCjJ22SeFsHJREDAtlAl6OHJ8Qs7tOV5O/m8iJPeTYQD3LYYAtyS14ej 5g+XEnlPocbeVto7H5vcSAKbGvf3dAVRQMWPFEeOE4PKmFeZLhiawRIabZIDOEai JazdrqgiCMOHtyStAyB+IxRzLqRnfKzY2m2jPcIg4V86LySrpL9kSfx4/Df8rksC PU15N5UnZkcfRXiOci4NR0PpgIIgJB2yC8WoFJYhpAdrHFWpCd3WpWgKmqbvdirt Ro5rKOYGJobefx718RypO2jzuTz26fe0ifj/vUHgLwoKjMk+KDrDro4s93exRoWE R1siYRV9v0kefMuHgGET =FzgJ -END PGP SIGNATURE-
[jira] [Commented] (FELIX-4245) Deadlock in Dependency
[ https://issues.apache.org/jira/browse/FELIX-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779745#comment-13779745 ] Clement Escoffier commented on FELIX-4245: -- Fixed in trunk. Deadlock in Dependency -- Key: FELIX-4245 URL: https://issues.apache.org/jira/browse/FELIX-4245 Project: Felix Issue Type: Task Components: iPOJO Affects Versions: ipojo-runtime-1.10.1 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.10.2 There is a deadlock condition in the dependency class. The dependency class does not follow the synchronization protocol from the dependency model. This leads to the deadlock. First Thread: Name: fileinstall-/home/torito/workspace/Cilia/tests/runtime/target/distribution/cilia-remote-distribution/load State: BLOCKED on org.apache.felix.ipojo.handlers.dependency.Dependency@1d9aed0 owned by: [iPOJO] pool-248-thread-1 Total blocked: 3 Total waited: 4 Stack trace: org.apache.felix.ipojo.handlers.dependency.Dependency.isFrozen(Dependency.java:236) org.apache.felix.ipojo.util.DependencyModel.onChange(DependencyModel.java:978) org.apache.felix.ipojo.dependency.impl.ServiceReferenceManager.fireUpdate(ServiceReferenceManager.java:448) org.apache.felix.ipojo.dependency.impl.ServiceReferenceManager.onNewMatchingService(ServiceReferenceManager.java:412) org.apache.felix.ipojo.dependency.impl.ServiceReferenceManager.addedService(ServiceReferenceManager.java:391) org.apache.felix.ipojo.util.Tracker$Tracked.trackAdding(Tracker.java:711) org.apache.felix.ipojo.util.Tracker$Tracked.track(Tracker.java:672) org.apache.felix.ipojo.util.Tracker$Tracked.serviceChanged(Tracker.java:633) org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) org.apache.felix.framework.Felix.registerService(Felix.java:3275) org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:320) org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:414) org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler.__M_configure(ArchitectureHandler.java:64) org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler.configure(ArchitectureHandler.java) org.apache.felix.ipojo.HandlerManager.init(HandlerManager.java:73) org.apache.felix.ipojo.InstanceManager.configure(InstanceManager.java:203) org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:177) org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:309) - locked org.apache.felix.ipojo.ComponentFactory@2a3025 org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:236) org.ow2.chameleon.rose.api.Instance$InstanceCreator.addingService(Instance.java:140) org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) org.ow2.chameleon.rose.api.Instance.start(Instance.java:55) org.ow2.chameleon.rose.api.Machine.start(Machine.java:72) org.ow2.chameleon.rose.configurator.Configurator.__M_install(Configurator.java:134) org.ow2.chameleon.rose.configurator.Configurator.install(Configurator.java) org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:862) org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:790) org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:428) org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245) Second Thread: Name: [iPOJO] pool-248-thread-1 State: WAITING on java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@170e93a owned by: fileinstall-/home/torito/workspace/Cilia/tests/runtime/target/distribution/cilia-remote-distribution/load Total blocked: 6 Total waited: 2 Stack trace: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
[jira] [Created] (FELIX-4246) maven-scr-plugin 1.14 deletes scr descriptor .xml files on subsequent (incremental) eclipse build
Stefan Egli created FELIX-4246:
--
Summary: maven-scr-plugin 1.14 deletes scr descriptor .xml files
on subsequent (incremental) eclipse build
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner is
invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for deleting/cleaning
up?
--
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] [Assigned] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
[
https://issues.apache.org/jira/browse/FELIX-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-4241:
---
Assignee: Carsten Ziegeler
Change default output directory for SCR annotations to
${project.build.directory}/classes
-
Key: FELIX-4241
URL: https://issues.apache.org/jira/browse/FELIX-4241
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.14.2
Attachments: FELIX-4242-1.patch
Currently the plugin outputs the generated files under
${project.build.directory}/scr-plugin-generated . This change allows it to
place its contents in the same place as the java compiled classes and the
MANIFEST.MF generated by the maven-bundle-plugin.
The result is that the exploded bundle contents is placed into a single
directory and can be used by tooling - such as the Sling IDE tools - to
incrementally update a bundle running in an OSGi container without going
through a full maven package + deploy cycle.
--
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] [Updated] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
[
https://issues.apache.org/jira/browse/FELIX-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4241:
Fix Version/s: maven-scr-plugin 1.14.2
Change default output directory for SCR annotations to
${project.build.directory}/classes
-
Key: FELIX-4241
URL: https://issues.apache.org/jira/browse/FELIX-4241
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Reporter: Robert Munteanu
Priority: Minor
Fix For: maven-scr-plugin 1.14.2
Attachments: FELIX-4242-1.patch
Currently the plugin outputs the generated files under
${project.build.directory}/scr-plugin-generated . This change allows it to
place its contents in the same place as the java compiled classes and the
MANIFEST.MF generated by the maven-bundle-plugin.
The result is that the exploded bundle contents is placed into a single
directory and can be used by tooling - such as the Sling IDE tools - to
incrementally update a bundle running in an OSGi container without going
through a full maven package + deploy cycle.
--
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] [Resolved] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
[
https://issues.apache.org/jira/browse/FELIX-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4241.
-
Resolution: Fixed
Thanks for your patch, Robert. it's applied
I agree that this is a better default, especially given the m2e integration
While this is an incompatible change it shouldn't cause any problems for
downstream users
Change default output directory for SCR annotations to
${project.build.directory}/classes
-
Key: FELIX-4241
URL: https://issues.apache.org/jira/browse/FELIX-4241
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.14.2
Attachments: FELIX-4242-1.patch
Currently the plugin outputs the generated files under
${project.build.directory}/scr-plugin-generated . This change allows it to
place its contents in the same place as the java compiled classes and the
MANIFEST.MF generated by the maven-bundle-plugin.
The result is that the exploded bundle contents is placed into a single
directory and can be used by tooling - such as the Sling IDE tools - to
incrementally update a bundle running in an OSGi container without going
through a full maven package + deploy cycle.
--
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] [Resolved] (FELIX-4010) SCR Plugin aborts when scanning a Java 8 class file
[ https://issues.apache.org/jira/browse/FELIX-4010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4010. - Resolution: Fixed I'm excluding java. and javax. now from scanning SCR Plugin aborts when scanning a Java 8 class file --- Key: FELIX-4010 URL: https://issues.apache.org/jira/browse/FELIX-4010 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.11.0 Reporter: Felix Meschberger Assignee: Carsten Ziegeler Fix For: maven-scr-plugin 1.14.2, scr ant task 1.9.0, scr generator 1.8.2 It looks like the ASM library referred to by the SCR plugin is not compatible with Java 8 class file version 52. How to reproduce: Use Java 8 to run a maven based project build where at least one of the @Component annotated classes extend (or implement) a Java 8 runtime provided class, e.g. java.io.Serializable, in class file version 52. -- 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] [Updated] (FELIX-4246) Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4246:
Fix Version/s: scr generator 1.8.2
maven-scr-plugin 1.14.2
Metatype descriptor files get deleted on subsequent (incremental) eclipse
build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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] [Updated] (FELIX-4246) Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4246:
Summary: Metatype descriptor files get deleted on subsequent (incremental)
eclipse build (was: maven-scr-plugin 1.14 deletes scr descriptor .xml files on
subsequent (incremental) eclipse build)
Metatype descriptor files get deleted on subsequent (incremental) eclipse
build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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] [Updated] (FELIX-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated FELIX-4246:
Summary: SCR and Metatype descriptor files get deleted on subsequent
(incremental) eclipse build (was: Metatype descriptor files get deleted on
subsequent (incremental) eclipse build)
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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] [Work started] (FELIX-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4246 started by Carsten Ziegeler.
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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] [Assigned] (FELIX-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-4246:
---
Assignee: Carsten Ziegeler
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779844#comment-13779844
]
Carsten Ziegeler commented on FELIX-4246:
-
Both descriptor files are affected - the plugin deletes all of them if there is
no source. This looks like a wrong behaviour in the case of an incremental
build.
As a first fix, I'Ve added an incremental flag to the options which is set by
the maven plugin and in that case no descriptor files are removed.
In the ant case everything is removed (like before) - and a mvn clean should
remove the whole target directory. So this should work
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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] [Resolved] (FELIX-4192) SCR Generator fails with a NPE in case a class level Reference doesn't define a referenceInterface
[
https://issues.apache.org/jira/browse/FELIX-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4192.
-
Resolution: Fixed
Fix Version/s: scr ant task 1.9.0
maven-scr-plugin 1.14.2
SCR Generator fails with a NPE in case a class level Reference doesn't define
a referenceInterface
--
Key: FELIX-4192
URL: https://issues.apache.org/jira/browse/FELIX-4192
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Environment: JDK7
Reporter: Daniel Kuffner
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.14.2, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4192-test-case.diff
Consider following simple component:
{code}
@Component
@Reference(name=a, bind=setA, unbind=unsetA)
public class MyJavaClass {
}
{code}
the generator will fail with a NPE (see stacktrace). It would be preferable
if the generator will fail with a usfull error message.
Stacktrace:
{code}
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:332)
at
java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1144)
at java.lang.ClassLoader.getClassLoadingLock(ClassLoader.java:462)
at java.lang.ClassLoader.loadClass(ClassLoader.java:403)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at
org.apache.felix.scrplugin.helper.Validator.findMethod(Validator.java:568)
at
org.apache.felix.scrplugin.SCRDescriptorGenerator.processReferences(SCRDescriptorGenerator.java:647)
at
org.apache.felix.scrplugin.SCRDescriptorGenerator.createComponent(SCRDescriptorGenerator.java:384)
at
org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:161)
at
net.chilicat.felixscr.intellij.build.scr.AbstractScrProcessor.executeImpl(AbstractScrProcessor.java:86)
at
net.chilicat.felixscr.intellij.build.scr.AbstractScrProcessor.execute(AbstractScrProcessor.java:42)
at
net.chilicat.felixscr.intellij.build.ScrProcessingItem.execute(ScrProcessingItem.java:39)
at
net.chilicat.felixscr.intellij.build.ScrCompiler.process(ScrCompiler.java:108)
{code}
--
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: [VOTE] Release Felix HTTP v2.2.1
+1 (non binding) Regards JB On 09/25/2013 04:47 PM, Felix Meschberger wrote: +1 Regards Felix Am 18.09.2013 um 16:13 schrieb Jan Willem Janssen: Signierter PGP Teil Hi, After some initial struggles preparing the release, it is time to cast a vote on a new release of Felix HTTP. We solved the following issues since the 2.2.0 release: https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20component%20%3D%20%22HTTP%20Service%22%20AND%20resolved%20%3E%3D%202011-01-26%20AND%20resolved%20%3C%3D%202013-09-18 There are still some outstanding issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20%22HTTP%20Service%22 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-072/ 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 072 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is revolving around PulseOn and Amdatu/ Luminis Technologies B.V. J.C. Wilslaan 29 7313 HK Apeldoorn +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[jira] [Resolved] (FELIX-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4246.
-
Resolution: Fixed
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin 1.14.2, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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-4246) SCR and Metatype descriptor files get deleted on subsequent (incremental) eclipse build
[
https://issues.apache.org/jira/browse/FELIX-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779849#comment-13779849
]
Stefan Egli commented on FELIX-4246:
FYI: Tested and verified, the files dont get deleted anymore with the latest
fix.
SCR and Metatype descriptor files get deleted on subsequent (incremental)
eclipse build
---
Key: FELIX-4246
URL: https://issues.apache.org/jira/browse/FELIX-4246
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin 1.14.0
Environment: Eclipse, m2eclipse
Reporter: Stefan Egli
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin 1.15.0, scr generator 1.8.2
There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked
fine in 1.13.0*. Consider the following scenario:
* a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0
and contains java classes annotated with @Service and/or @Components
* the project is cleaned ('clean project') and built ('build project')
- the descriptor .xml files are created as expected
* when the project is built again (incrementally, eg manually triggering
another 'build project'), the descriptor .xml files are deleted
Some debugging narrows the problem down to the
MavenProjectScanner.getSourcesForScanKind, where the buildContext.newScanner
is invoked. The scanner returned there is of type EclipseBuildContext (set by
m2eclipse) when doing a build right after a clean - and in this case the
scanner finds java files, sets those via project.setSources and
MetaTypeIO.generateDescriptors correctly generates the descriptors.
In the incremental(-eclipse)-build case though, the buildContext.newScanner
returns an EclipseIncrementalBuildContext - which results in an empty set of
sources being passed to project.setScanner, hence later down the call-stack
MetaTypeIO.generateDescriptors gets an empty list of components, thus *thinks
it's a good idea to go through the metatype directory and delete 'obsolete'
metatype files* - when in fact they are not quite obsolete..
Maybe it would be better to hook into the 'clean' method for
deleting/cleaning up?
--
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
PackageAdmin#getExportedPackages does not work on packages exported by attached fragments
Hi, we're encountering FELIX-3239 - as I don't know the codebase, any hint on how to solve this? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Unable to build SCR trunk
Hi,
while trying to build SCR trunk I always get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process
(default) on project org.apache.felix.scr: Execution default of goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process failed:
For artifact {null:null:null:jar}: The groupId cannot be empty. - [Help 1]
Anyone else seeing this?
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
Re: Unable to build SCR trunk
Hi Carsten,
From my side, I don't have this problem,
I just rebuilt scr like this:
java -version
java version 1.7.0_21
mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
rm -rf ~/.m2/repository/*
cd ~/work/osgi/felix-trunk/utils
mvn clean install
cd ../scr
mvs clean install
does this help ?
regards;
/Pierre
On Fri, Sep 27, 2013 at 2:02 PM, Carsten Ziegeler cziege...@apache.orgwrote:
Hi,
while trying to build SCR trunk I always get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process
(default) on project org.apache.felix.scr: Execution default of goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process failed:
For artifact {null:null:null:jar}: The groupId cannot be empty. - [Help 1]
Anyone else seeing this?
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[jira] [Commented] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments
[ https://issues.apache.org/jira/browse/FELIX-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779887#comment-13779887 ] Richard S. Hall commented on FELIX-3239: I think I understand why this started happening. While specifying the R5 resolver API we changed how we handled attached fragment capabilities. The old approach actually attached fragment capabilities to the host, but the new approach doesn't. This is likely the root of the issue. I'll try to take a look into it. PackageAdmin#getExportedPackages does not work on packages exported by attached fragments - Key: FELIX-3239 URL: https://issues.apache.org/jira/browse/FELIX-3239 Project: Felix Issue Type: Bug Affects Versions: framework-4.0.1 Reporter: Guillaume Nodet Fix For: framework-4.4.0 -- 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: Unable to build SCR trunk
Hi Pierre,
thanks - but no, I tried the same with the difference of using Java 6 and
Maven 3.0.5 - but I always get this error.
Strange, I'll continue investigating
Carsten
2013/9/27 Pierre De Rop pierre.de...@gmail.com
Hi Carsten,
From my side, I don't have this problem,
I just rebuilt scr like this:
java -version
java version 1.7.0_21
mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
rm -rf ~/.m2/repository/*
cd ~/work/osgi/felix-trunk/utils
mvn clean install
cd ../scr
mvs clean install
does this help ?
regards;
/Pierre
On Fri, Sep 27, 2013 at 2:02 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
while trying to build SCR trunk I always get:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process
(default) on project org.apache.felix.scr: Execution default of goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.1:process
failed:
For artifact {null:null:null:jar}: The groupId cannot be empty. - [Help
1]
Anyone else seeing this?
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
--
Carsten Ziegeler
cziege...@apache.org
Re: [VOTE] Release ServiceDiagnostics Webconsole Plugin version 0.1.3
Hi everyone, I'm still missing one PMC vote to close the release... anyone? Thanks, Arjun On 09/16/2013 03:06 PM, Felix Meschberger wrote: +1 I wonder, whether a parent project is really needed for a single project making use of that parent ? In any case, the parent project will probably only be pushed to the Maven repo but not to .../dist, right ? Regards Felix Am 16.09.2013 um 12:54 schrieb Arjun Panday: Hi, I'd like to release a new version of the ServiceDiagnostics webconsole plugin. A sample launcher showing the required dependencies can be found here: http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/servicediagnostics/run.sh --- Changes from 0.1.2 to 0.1.3 --- ** Bugs * [FELIX-3898] name parsing issue on BundleDependency * [FELIX-4162] incorrect loop detection ** Improvements * [FELIX-3899] switch to Scala 2.10 * [FELIX-3769] webconsole categories * [FELIX-4163] command line interface * circular dependencies shown on a separate graph with or wihtout optionals * new visualisations of the service registry: service providers, using bundles, and bundles wiring via services * show components as implementations and services as interfaces * graph filter supports basic logical expressions Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-053/ https://repository.apache.org/content/repositories/orgapachefelix-054/ You can usethis 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 O53 /tmp/felix-staging-parent sh check_staged_release.sh 054 /tmp/felix-staging-plugin Please vote to approvethis release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be openfor 72 hours. Best regards, Arjun
Re: [VOTE] Release ServiceDiagnostics Webconsole Plugin version 0.1.3
+1, Clement On 16 sept. 2013, at 12:54, Arjun Panday arjun.pan...@alcatel-lucent.com wrote: Hi, I'd like to release a new version of the ServiceDiagnostics webconsole plugin. A sample launcher showing the required dependencies can be found here: http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/servicediagnostics/run.sh --- Changes from 0.1.2 to 0.1.3 --- ** Bugs * [FELIX-3898] name parsing issue on BundleDependency * [FELIX-4162] incorrect loop detection ** Improvements * [FELIX-3899] switch to Scala 2.10 * [FELIX-3769] webconsole categories * [FELIX-4163] command line interface * circular dependencies shown on a separate graph with or wihtout optionals * new visualisations of the service registry: service providers, using bundles, and bundles wiring via services * show components as implementations and services as interfaces * graph filter supports basic logical expressions Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-053/ https://repository.apache.org/content/repositories/orgapachefelix-054/ You can usethis 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 O53 /tmp/felix-staging-parent sh check_staged_release.sh 054 /tmp/felix-staging-plugin Please vote to approvethis release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be openfor 72 hours. Best regards, Arjun
[jira] [Created] (FELIX-4247) Memory leak with ServiceUsage and inner class (Listener style)
Guillaume Sauthier created FELIX-4247:
-
Summary: Memory leak with ServiceUsage and inner class (Listener
style)
Key: FELIX-4247
URL: https://issues.apache.org/jira/browse/FELIX-4247
Project: Felix
Issue Type: Bug
Components: iPOJO
Reporter: Guillaume Sauthier
Assume that you have a @Component using a swing-like technology with a load of
Listeners and callbacks.
You'll probably write something like:
{code:java}
button.addClickListener(new ClickListener() {
// boilerplate code
myDependency.useIt();
});
{code}
Where myDependency is a @Requires field.
When the listener is executed, it is used from outside of the component (from
iPOJO POV), its method is not intercepted and a reference is kept in
ServiceUsage$Usage.
--
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-4248) ServiceUsage ThreadLocal removal
Guillaume Sauthier created FELIX-4248: - Summary: ServiceUsage ThreadLocal removal Key: FELIX-4248 URL: https://issues.apache.org/jira/browse/FELIX-4248 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Guillaume Sauthier Currently, ServiceUsage is never removed from the ThreadLocal. So we have references to iPOJO classes around even after bundle uninstall. -- 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] [Comment Edited] (FELIX-4248) ServiceUsage ThreadLocal removal
[
https://issues.apache.org/jira/browse/FELIX-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779913#comment-13779913
]
Guillaume Sauthier edited comment on FELIX-4248 at 9/27/13 1:20 PM:
The current code also have {{m_usage.set(usage)}} that should not be required.
was (Author: sauthieg):
The current code also have {{{m_usage.set(usage)}}} that should not be
required.
ServiceUsage ThreadLocal removal
Key: FELIX-4248
URL: https://issues.apache.org/jira/browse/FELIX-4248
Project: Felix
Issue Type: Bug
Components: iPOJO
Reporter: Guillaume Sauthier
Currently, ServiceUsage is never removed from the ThreadLocal.
So we have references to iPOJO classes around even after bundle uninstall.
--
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-4248) ServiceUsage ThreadLocal removal
[
https://issues.apache.org/jira/browse/FELIX-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779913#comment-13779913
]
Guillaume Sauthier commented on FELIX-4248:
---
The current code also have {{{m_usage.set(usage)}}} that should not be required.
ServiceUsage ThreadLocal removal
Key: FELIX-4248
URL: https://issues.apache.org/jira/browse/FELIX-4248
Project: Felix
Issue Type: Bug
Components: iPOJO
Reporter: Guillaume Sauthier
Currently, ServiceUsage is never removed from the ThreadLocal.
So we have references to iPOJO classes around even after bundle uninstall.
--
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 ServiceDiagnostics Webconsole Plugin version 0.1.3
Thanks a lot everyone, The vote has passed with the following result : +1 (binding): Felix Meschberger, Pierre De Rop, Clement Escoffier, Carsten Ziegeler +1 (non binding): Jean-Baptiste Onofré I will copy this release to the Felix dist directory and promote the artifacts to the central Maven repository. Regards, Arjun On 09/27/2013 03:15 PM, Carsten Ziegeler wrote: +1 (sorry totally overlooked this) Carsten 2013/9/27 Clement Escoffier clement.escoff...@gmail.com +1, Clement On 16 sept. 2013, at 12:54, Arjun Panday arjun.pan...@alcatel-lucent.com wrote: Hi, I'd like to release a new version of the ServiceDiagnostics webconsole plugin. A sample launcher showing the required dependencies can be found here: http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/servicediagnostics/run.sh --- Changes from 0.1.2 to 0.1.3 --- ** Bugs * [FELIX-3898] name parsing issue on BundleDependency * [FELIX-4162] incorrect loop detection ** Improvements * [FELIX-3899] switch to Scala 2.10 * [FELIX-3769] webconsole categories * [FELIX-4163] command line interface * circular dependencies shown on a separate graph with or wihtout optionals * new visualisations of the service registry: service providers, using bundles, and bundles wiring via services * show components as implementations and services as interfaces * graph filter supports basic logical expressions Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-053/ https://repository.apache.org/content/repositories/orgapachefelix-054/ You can usethis 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 O53 /tmp/felix-staging-parent sh check_staged_release.sh 054 /tmp/felix-staging-plugin Please vote to approvethis release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be openfor 72 hours. Best regards, Arjun
[jira] [Created] (FELIX-4249) Make the default error location 1,1 instead of 0,0
Robert Munteanu created FELIX-4249: -- Summary: Make the default error location 1,1 instead of 0,0 Key: FELIX-4249 URL: https://issues.apache.org/jira/browse/FELIX-4249 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: scr generator 1.8.0 Reporter: Robert Munteanu Priority: Minor The scr generator's error reporting places the errors by default at the 0,0 coordinates. In practice, this means that in Eclipse the error/warning is associated with the file and shown in the problems view but not in the editor. To make this more visible, I suggest that we change the error location to 1,1, which places it in the first line of the file. Should we want to, we can extract line ( but not column ) information from ASM to place the warning closer to the source. -- 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] [Updated] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[ https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4249: --- Attachment: FELIX-4249-1.patch Make the default error location 1,1 instead of 0,0 -- Key: FELIX-4249 URL: https://issues.apache.org/jira/browse/FELIX-4249 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: scr generator 1.8.0 Reporter: Robert Munteanu Priority: Minor Attachments: FELIX-4249-1.patch The scr generator's error reporting places the errors by default at the 0,0 coordinates. In practice, this means that in Eclipse the error/warning is associated with the file and shown in the problems view but not in the editor. To make this more visible, I suggest that we change the error location to 1,1, which places it in the first line of the file. Should we want to, we can extract line ( but not column ) information from ASM to place the warning closer to the source. -- 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
