[jira] [Resolved] (FELIX-2948) scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle)
[ https://issues.apache.org/jira/browse/FELIX-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-2948. - Resolution: Fixed Thanks for testing! > scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle) > -- > > Key: FELIX-2948 > URL: https://issues.apache.org/jira/browse/FELIX-2948 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.7.0, scr ant task 1.1.0, scr > generator 1.1.0 >Reporter: Andrei Pozolotin >Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin-1.7.2, scr ant task 1.1.2, scr > generator 1.1.2 > > > scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle) > 1) when you run scr-maven-plugin in the eclipse ide with m2e plugin > then it seems at first to work fine: > a) import this project in the eclipse with help of m2e: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-001 > b) and run "eclipse -> project -> clean"; it produces this success log: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-001/doc-inf/build-m2e.log > 2) but when your try > a) a second project which depends on first: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-002 > b) then "eclipse -> project -> clean" now produces the following failure log: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-002/doc-inf/build-m2e.log > 3) this is because scr-maven-plugin expects dependency to be in the jar form > but m2e instead (and appropriately) provides a path to the exploded bundle in > the ./target/classes > of the dependency project (if it is a workspace project); > 4) the workaround is to disable workspace project resolution in m2e > but this impedes development speed considerably -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] EventAdmin 1.2.12 release
+1 Carsten Carsten Ziegeler wrote > I would like to call a vote on the following subproject release: > > eventadmin 1.2.12 > > This release fixes another regression introduced in a previous release: > > https://issues.apache.org/jira/browse/FELIX-2915 > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-023/ > > 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 023 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > > Regards > Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] EventAdmin 1.2.12 release
Richard S. Hall wrote > Why has the released source project artifacts changed? > > Naming-wise, it is now called source-release, wasn't it called project > before? Also, there is only a ZIP artifact created, but we always > generated ZIP and tar.gz, no? > This is how it is defined in the parent apache pom (version 9). While the name change is not nice, I don't think this is a real problem as we just have to use correct links from the website for that. Similar for the format, zip is supported by all platforms and as long as we don't have scripts included, one source artifact is enough. But that's probably something we should discuss - we can override this in our parent pom if we want to. However, I don't consider this a blocker for the release. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] framework 3.2.2 and related subproject
+1 - Rob framework 3.2.2 main 3.2.2 main.distribution 3.2.2 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-020/ 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 020 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) I would like to call a vote on the following subproject releases: -- Ascert - Taking systems to the Edge r...@ascert.com +44 (0)20 7488 3470 www.ascert.com
[jira] [Closed] (FELIX-2958) Unable to remove previously added repository from OBR
[ https://issues.apache.org/jira/browse/FELIX-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor closed FELIX-2958. -- Thank you! > Unable to remove previously added repository from OBR > - > > Key: FELIX-2958 > URL: https://issues.apache.org/jira/browse/FELIX-2958 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor >Assignee: Richard S. Hall > Fix For: bundlerepository-1.6.6 > > Attachments: FELIX-2958.patch > > > When adding a new repository to OBR, the passed url is converted into an > actual URL object and the repository is stored in a map under > url.toExternalForm() key. However, when removing a repository, the raw url > string is used remove the repository from the map. Because of the uri > conversion to URL object in addRepository(), the passed in string and the > string produced by URL.toExternalForm() might be slightly different. That can > make removeRepository() not work right (the repository won't be removed). > For example, URL.toExternalForm() on file:///media/d/m2/repository.xml > returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2958) Unable to remove previously added repository from OBR
[ https://issues.apache.org/jira/browse/FELIX-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-2958. Resolution: Fixed Fix Version/s: bundlerepository-1.6.6 Assignee: Richard S. Hall Applied the patch. Please close if you are satisfied. Thanks! > Unable to remove previously added repository from OBR > - > > Key: FELIX-2958 > URL: https://issues.apache.org/jira/browse/FELIX-2958 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor >Assignee: Richard S. Hall > Fix For: bundlerepository-1.6.6 > > Attachments: FELIX-2958.patch > > > When adding a new repository to OBR, the passed url is converted into an > actual URL object and the repository is stored in a map under > url.toExternalForm() key. However, when removing a repository, the raw url > string is used remove the repository from the map. Because of the uri > conversion to URL object in addRepository(), the passed in string and the > string produced by URL.toExternalForm() might be slightly different. That can > make removeRepository() not work right (the repository won't be removed). > For example, URL.toExternalForm() on file:///media/d/m2/repository.xml > returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2958) Unable to remove previously added repository from OBR
[ https://issues.apache.org/jira/browse/FELIX-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2958: --- Attachment: FELIX-2958.patch Attached patch for this issue. > Unable to remove previously added repository from OBR > - > > Key: FELIX-2958 > URL: https://issues.apache.org/jira/browse/FELIX-2958 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-1.6.4 >Reporter: Jarek Gawor > Attachments: FELIX-2958.patch > > > When adding a new repository to OBR, the passed url is converted into an > actual URL object and the repository is stored in a map under > url.toExternalForm() key. However, when removing a repository, the raw url > string is used remove the repository from the map. Because of the uri > conversion to URL object in addRepository(), the passed in string and the > string produced by URL.toExternalForm() might be slightly different. That can > make removeRepository() not work right (the repository won't be removed). > For example, URL.toExternalForm() on file:///media/d/m2/repository.xml > returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2958) Unable to remove previously added repository from OBR
Unable to remove previously added repository from OBR - Key: FELIX-2958 URL: https://issues.apache.org/jira/browse/FELIX-2958 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Affects Versions: bundlerepository-1.6.4 Reporter: Jarek Gawor When adding a new repository to OBR, the passed url is converted into an actual URL object and the repository is stored in a map under url.toExternalForm() key. However, when removing a repository, the raw url string is used remove the repository from the map. Because of the uri conversion to URL object in addRepository(), the passed in string and the string produced by URL.toExternalForm() might be slightly different. That can make removeRepository() not work right (the repository won't be removed). For example, URL.toExternalForm() on file:///media/d/m2/repository.xml returns file:/media/d/m2/repository.xml. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] EventAdmin 1.2.12 release
Why has the released source project artifacts changed? Naming-wise, it is now called source-release, wasn't it called project before? Also, there is only a ZIP artifact created, but we always generated ZIP and tar.gz, no? -> richard On 5/18/11 3:51, Carsten Ziegeler wrote: I would like to call a vote on the following subproject release: eventadmin 1.2.12 This release fixes another regression introduced in a previous release: https://issues.apache.org/jira/browse/FELIX-2915 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-023/ 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 023 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Regards Carsten
Re: [VOTE] framework 3.2.2 and related subproject
+1 We still need to fix DEPS file in framework sources... -> richard On 5/17/11 17:04, Karl Pauls wrote: I would like to call a vote on the following subproject releases: framework 3.2.2 main 3.2.2 main.distribution 3.2.2 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-020/ 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 020 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
[jira] [Commented] (FELIX-2948) scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle)
[ https://issues.apache.org/jira/browse/FELIX-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035415#comment-13035415 ] Andrei Pozolotin commented on FELIX-2948: - Carsten: I tried maven-scr-plugin-1.7.1-20110517.073734-2.jar; it works! you are the best, thank you. Andrei. > scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle) > -- > > Key: FELIX-2948 > URL: https://issues.apache.org/jira/browse/FELIX-2948 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.7.0, scr ant task 1.1.0, scr > generator 1.1.0 >Reporter: Andrei Pozolotin >Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin-1.7.2, scr ant task 1.1.2, scr > generator 1.1.2 > > > scr-maven-plugin fails with org.maven.ide.eclipse plugin (exploded bundle) > 1) when you run scr-maven-plugin in the eclipse ide with m2e plugin > then it seems at first to work fine: > a) import this project in the eclipse with help of m2e: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-001 > b) and run "eclipse -> project -> clean"; it produces this success log: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-001/doc-inf/build-m2e.log > 2) but when your try > a) a second project which depends on first: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-002 > b) then "eclipse -> project -> clean" now produces the following failure log: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-002/doc-inf/build-m2e.log > 3) this is because scr-maven-plugin expects dependency to be in the jar form > but m2e instead (and appropriately) provides a path to the exploded bundle in > the ./target/classes > of the dependency project (if it is a workspace project); > 4) the workaround is to disable workspace project resolution in m2e > but this impedes development speed considerably -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2955) IllegalStateException when doing a 'dm notavail' shell command.
[ https://issues.apache.org/jira/browse/FELIX-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-2955. - Resolution: Fixed Added a test to validate the problem, and a fix to make it go away. > IllegalStateException when doing a 'dm notavail' shell command. > --- > > Key: FELIX-2955 > URL: https://issues.apache.org/jira/browse/FELIX-2955 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 >Reporter: Marcel Offermans >Assignee: Marcel Offermans > > Using the shell command sometimes gives an exception somewhat like this one: > osgi> dm notavail > java.lang.IllegalStateException: BundleContext is no longer valid > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.checkValid(BundleContextImpl.java:1003) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.getBundle(BundleContextImpl.java:151) > at > org.apache.felix.dm.impl.index.BundleContextInterceptorBase.getBundle(BundleContextInterceptorBase.java:61) > at > org.apache.felix.dm.shell.DMCommand$DependencyManagerSorter.compare(DMCommand.java:234) > at java.util.Arrays.mergeSort(Arrays.java:1270) > at java.util.Arrays.mergeSort(Arrays.java:1282) > at java.util.Arrays.mergeSort(Arrays.java:1281) > at java.util.Arrays.mergeSort(Arrays.java:1282) > at java.util.Arrays.mergeSort(Arrays.java:1281) > at java.util.Arrays.mergeSort(Arrays.java:1281) > at java.util.Arrays.sort(Arrays.java:1210) > at java.util.Collections.sort(Collections.java:159) > at org.apache.felix.dm.shell.DMCommand.execute(DMCommand.java:89) > at > org.apache.felix.dm.shell.EquinoxDMCommand._dm(EquinoxDMCommand.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:156) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:141) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:105) > at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2957) Filter scope should be an array
[ https://issues.apache.org/jira/browse/FELIX-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-2957. - Resolution: Fixed Fixed in revision 1124271 > Filter scope should be an array > --- > > Key: FELIX-2957 > URL: https://issues.apache.org/jira/browse/FELIX-2957 > Project: Felix > Issue Type: Improvement > Components: Maven SCR Plugin >Affects Versions: scr annotations 1.5.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr annotations 1.6.0 > > > The filter scope for a sling servlet filter is a multi value field -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2957) Filter scope should be an array
Filter scope should be an array --- Key: FELIX-2957 URL: https://issues.apache.org/jira/browse/FELIX-2957 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: scr annotations 1.5.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: scr annotations 1.6.0 The filter scope for a sling servlet filter is a multi value field -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
new feature request: iPOJO component-flow-composition
I enjoyed iPOJO very much, although just using it for 2 weeks. iPOJO provides a charming component runtime. Is it convenient to extend iPOJO to support component-flow-composition? The imaginary flow-composition is data-driven, without loop flow-control. Just think SPSS clementine, or Weka knowledge-flow. Looking forward to some guidance. Best regards, drhades
[jira] [Resolved] (FELIX-2956) DM/ json should be embedded in the annotation scanner plugin
[ https://issues.apache.org/jira/browse/FELIX-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop resolved FELIX-2956. -- Resolution: Fixed Fix Version/s: log-1.0.1 fixed in trunk, revision 1124200. > DM/ json should be embedded in the annotation scanner plugin > > > Key: FELIX-2956 > URL: https://issues.apache.org/jira/browse/FELIX-2956 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: log-1.0.1 > > > This change request concerns the Dependency Manager annotation scanner plugin > artifact: > When compiling a bundle containing dependency manager annotations, it is > necessary to use the > DM annotation plugin, which scans all annotations at compilation phase and > generates corresponding > component descriptors under META-INF/dependencymanager/, in the target > bundle. > This DM annotation plugin requires json, when being executed. Under maven, > there is no problem, > and users don't have to depend on json, just on the dm annotation plugin. > But, when compiling outside maven (using Bnd, or Bnd Ant Task), then it is > necessary to download json manually > and put it in the bnd classpath. So, it would be just easier if json was > already embedded in the DM annotation.jar artifact, > (in this case, the LICENSE.json file have to be included in the annotation > artifact). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2956) DM/ json should be embedded in the annotation scanner plugin
[ https://issues.apache.org/jira/browse/FELIX-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-2956. > DM/ json should be embedded in the annotation scanner plugin > > > Key: FELIX-2956 > URL: https://issues.apache.org/jira/browse/FELIX-2956 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > > This change request concerns the Dependency Manager annotation scanner plugin > artifact: > When compiling a bundle containing dependency manager annotations, it is > necessary to use the > DM annotation plugin, which scans all annotations at compilation phase and > generates corresponding > component descriptors under META-INF/dependencymanager/, in the target > bundle. > This DM annotation plugin requires json, when being executed. Under maven, > there is no problem, > and users don't have to depend on json, just on the dm annotation plugin. > But, when compiling outside maven (using Bnd, or Bnd Ant Task), then it is > necessary to download json manually > and put it in the bnd classpath. So, it would be just easier if json was > already embedded in the DM annotation.jar artifact, > (in this case, the LICENSE.json file have to be included in the annotation > artifact). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2956) DM/ json should be embedded in the annotation scanner plugin
[ https://issues.apache.org/jira/browse/FELIX-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-2956: - Fix Version/s: (was: log-1.0.1) > DM/ json should be embedded in the annotation scanner plugin > > > Key: FELIX-2956 > URL: https://issues.apache.org/jira/browse/FELIX-2956 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-3.0.0 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > > This change request concerns the Dependency Manager annotation scanner plugin > artifact: > When compiling a bundle containing dependency manager annotations, it is > necessary to use the > DM annotation plugin, which scans all annotations at compilation phase and > generates corresponding > component descriptors under META-INF/dependencymanager/, in the target > bundle. > This DM annotation plugin requires json, when being executed. Under maven, > there is no problem, > and users don't have to depend on json, just on the dm annotation plugin. > But, when compiling outside maven (using Bnd, or Bnd Ant Task), then it is > necessary to download json manually > and put it in the bnd classpath. So, it would be just easier if json was > already embedded in the DM annotation.jar artifact, > (in this case, the LICENSE.json file have to be included in the annotation > artifact). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2956) DM/ json should be embedded in the annotation scanner plugin
DM/ json should be embedded in the annotation scanner plugin Key: FELIX-2956 URL: https://issues.apache.org/jira/browse/FELIX-2956 Project: Felix Issue Type: Improvement Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Pierre De Rop Assignee: Pierre De Rop Priority: Trivial This change request concerns the Dependency Manager annotation scanner plugin artifact: When compiling a bundle containing dependency manager annotations, it is necessary to use the DM annotation plugin, which scans all annotations at compilation phase and generates corresponding component descriptors under META-INF/dependencymanager/, in the target bundle. This DM annotation plugin requires json, when being executed. Under maven, there is no problem, and users don't have to depend on json, just on the dm annotation plugin. But, when compiling outside maven (using Bnd, or Bnd Ant Task), then it is necessary to download json manually and put it in the bnd classpath. So, it would be just easier if json was already embedded in the DM annotation.jar artifact, (in this case, the LICENSE.json file have to be included in the annotation artifact). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2955) IllegalStateException when doing a 'dm notavail' shell command.
IllegalStateException when doing a 'dm notavail' shell command. --- Key: FELIX-2955 URL: https://issues.apache.org/jira/browse/FELIX-2955 Project: Felix Issue Type: Bug Components: Dependency Manager Affects Versions: dependencymanager-3.0.0 Reporter: Marcel Offermans Assignee: Marcel Offermans Using the shell command sometimes gives an exception somewhat like this one: osgi> dm notavail java.lang.IllegalStateException: BundleContext is no longer valid at org.eclipse.osgi.framework.internal.core.BundleContextImpl.checkValid(BundleContextImpl.java:1003) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getBundle(BundleContextImpl.java:151) at org.apache.felix.dm.impl.index.BundleContextInterceptorBase.getBundle(BundleContextInterceptorBase.java:61) at org.apache.felix.dm.shell.DMCommand$DependencyManagerSorter.compare(DMCommand.java:234) at java.util.Arrays.mergeSort(Arrays.java:1270) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.sort(Arrays.java:1210) at java.util.Collections.sort(Collections.java:159) at org.apache.felix.dm.shell.DMCommand.execute(DMCommand.java:89) at org.apache.felix.dm.shell.EquinoxDMCommand._dm(EquinoxDMCommand.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:156) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.runConsole(FrameworkConsole.java:141) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:105) at java.lang.Thread.run(Thread.java:680) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-2954) DM/ annotated component factory does not allow to provide a component instance explicitly
[
https://issues.apache.org/jira/browse/FELIX-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-2954.
> DM/ annotated component factory does not allow to provide a component
> instance explicitly
> -
>
> Key: FELIX-2954
> URL: https://issues.apache.org/jira/browse/FELIX-2954
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> This change request concerns dependency manager annotations.
> Currently, it is possible to trigger an instantiation of a given annotated
> dependency manager Component, using the "factorySet" attribute of the
> "@Component" annotation.
> A "factory set" is similar to declarative service "component factory", except
> that a Set is provided in the OSGi registry, instead of the
> "org.osgi.service.component.ComponentFactory" SCR object.
> This Set acts as a factory API and can be considered as a
> repository of component instances configurations.
> (there is one component created per each dictionary stored in the set).
> For instance, in the following example, the component X is instantiated by
> the component Y, like this:
> @Component(factorySet="MyComponentFactory")
> class X implements Z {
> ...
> }
> @Component
> class Y {
> @ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
> Set _XFactory; // This Set acts as a Factory API for
> creating X component instances.
> @Start
> void start() {
> // Instantiate a X component instance
> Dictionary x1 = new Hashtable() {{ put("foo", "bar"); }};
> _XFactory.add(x1); // create a new X component instance
> }
> }
> In the above example, Y instantiates one X component, by passing an instance
> dictionary configuration into the set "_XFactory".
> The X component is instantiated using the X default constructor, and
> currently, the Y component can not create itself the X component instance
> object.
> The purpose of this change request is to allow the Y class to explicitly
> provide the X component instance, by passing a special
> key in the component configuration (x1), whose value may contain the actual
> component instance object.
> For instance:
> @Component
> class Y {
> @ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
> Set _XFactory;
> @Start
> void start() {
> // Instantiate a X component instance, and pass the real component
> instance in the dictionary:
> Dictionary x1 = new Hashtable() {{
>put("foo", "bar");
>put("dm.factory.instance", new X(whatever params));
>}};
> _XFactory.add(x1); // create a new X dependency manager component
> instance, using the object instance passed to the "dm.factory.instance" key
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2954) DM/ annotated component factory does not allow to provide a component instance explicitly
[
https://issues.apache.org/jira/browse/FELIX-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop resolved FELIX-2954.
--
Resolution: Fixed
Fixed in trunk.
> DM/ annotated component factory does not allow to provide a component
> instance explicitly
> -
>
> Key: FELIX-2954
> URL: https://issues.apache.org/jira/browse/FELIX-2954
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> This change request concerns dependency manager annotations.
> Currently, it is possible to trigger an instantiation of a given annotated
> dependency manager Component, using the "factorySet" attribute of the
> "@Component" annotation.
> A "factory set" is similar to declarative service "component factory", except
> that a Set is provided in the OSGi registry, instead of the
> "org.osgi.service.component.ComponentFactory" SCR object.
> This Set acts as a factory API and can be considered as a
> repository of component instances configurations.
> (there is one component created per each dictionary stored in the set).
> For instance, in the following example, the component X is instantiated by
> the component Y, like this:
> @Component(factorySet="MyComponentFactory")
> class X implements Z {
> ...
> }
> @Component
> class Y {
> @ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
> Set _XFactory; // This Set acts as a Factory API for
> creating X component instances.
> @Start
> void start() {
> // Instantiate a X component instance
> Dictionary x1 = new Hashtable() {{ put("foo", "bar"); }};
> _XFactory.add(x1); // create a new X component instance
> }
> }
> In the above example, Y instantiates one X component, by passing an instance
> dictionary configuration into the set "_XFactory".
> The X component is instantiated using the X default constructor, and
> currently, the Y component can not create itself the X component instance
> object.
> The purpose of this change request is to allow the Y class to explicitly
> provide the X component instance, by passing a special
> key in the component configuration (x1), whose value may contain the actual
> component instance object.
> For instance:
> @Component
> class Y {
> @ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
> Set _XFactory;
> @Start
> void start() {
> // Instantiate a X component instance, and pass the real component
> instance in the dictionary:
> Dictionary x1 = new Hashtable() {{
>put("foo", "bar");
>put("dm.factory.instance", new X(whatever params));
>}};
> _XFactory.add(x1); // create a new X dependency manager component
> instance, using the object instance passed to the "dm.factory.instance" key
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2954) DM/ annotated component factory does not allow to provide a component instance explicitly
DM/ annotated component factory does not allow to provide a component instance
explicitly
-
Key: FELIX-2954
URL: https://issues.apache.org/jira/browse/FELIX-2954
Project: Felix
Issue Type: Improvement
Components: Dependency Manager
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor
This change request concerns dependency manager annotations.
Currently, it is possible to trigger an instantiation of a given annotated
dependency manager Component, using the "factorySet" attribute of the
"@Component" annotation.
A "factory set" is similar to declarative service "component factory", except
that a Set is provided in the OSGi registry, instead of the
"org.osgi.service.component.ComponentFactory" SCR object.
This Set acts as a factory API and can be considered as a repository
of component instances configurations.
(there is one component created per each dictionary stored in the set).
For instance, in the following example, the component X is instantiated by the
component Y, like this:
@Component(factorySet="MyComponentFactory")
class X implements Z {
...
}
@Component
class Y {
@ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
Set _XFactory; // This Set acts as a Factory API for creating
X component instances.
@Start
void start() {
// Instantiate a X component instance
Dictionary x1 = new Hashtable() {{ put("foo", "bar"); }};
_XFactory.add(x1); // create a new X component instance
}
}
In the above example, Y instantiates one X component, by passing an instance
dictionary configuration into the set "_XFactory".
The X component is instantiated using the X default constructor, and currently,
the Y component can not create itself the X component instance object.
The purpose of this change request is to allow the Y class to explicitly
provide the X component instance, by passing a special
key in the component configuration (x1), whose value may contain the actual
component instance object.
For instance:
@Component
class Y {
@ServiceDependency(filter="(dm.factory.name=MyComponentFactory)")
Set _XFactory;
@Start
void start() {
// Instantiate a X component instance, and pass the real component
instance in the dictionary:
Dictionary x1 = new Hashtable() {{
put("foo", "bar");
put("dm.factory.instance", new X(whatever params));
}};
_XFactory.add(x1); // create a new X dependency manager component
instance, using the object instance passed to the "dm.factory.instance" key
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] iPOJO Event Admin Handler 1.8.0 release
+1, Regards, Clement On 17.05.11 23:15, "Karl Pauls" wrote: >+1 > >regards, > >Karl > >On Thu, May 12, 2011 at 7:53 PM, Richard S. Hall >wrote: >> +1 >> >> DEPS file didn't end up in sources JAR... >> >> -> richard >> >> On 5/11/11 15:32, Clement Escoffier wrote: >>> >>> Hi, >>> It's time to cut a release of the iPOJO Event Admin Handler 1.8.0. >>> >>> We solved 4 issues in this release: >>> ** Bug >>> * [FELIX-2718] - EventHandler are invoked one by one when using the >>> @Subscribe handler >>> >>> ** Improvement >>> * [FELIX-2631] - Rename @Publisher and @Subscriber attributes to >>> follow >>> the java naming conventions >>> * [FELIX-2634] - Rename the @Publisher annotation into @Publishes >>> annotation to avoid collision >>> * [FELIX-2711] - The event admin handler should provides a Handler >>> Description >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachefelix-006/ >>> >>> 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 006 /tmp/felix-staging >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Veto the release (please provide specific comments) >>> >>> Regards, >>> >>> Clement >>> >>> >>> >> > > > >-- >Karl Pauls >karlpa...@gmail.com
Re: [VOTE] framework 3.2.2 and related subproject
+1 (non-binding) Regards JB On 05/18/2011 09:36 AM, Pierre De Rop wrote: +1 (non binding) regards; /Pierre On Tue, May 17, 2011 at 11:04 PM, Karl Pauls wrote: I would like to call a vote on the following subproject releases: framework 3.2.2 main 3.2.2 main.distribution 3.2.2 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-020/ 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 020 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] framework 3.2.2 and related subproject
+1 Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] EventAdmin 1.2.12 release
I would like to call a vote on the following subproject release: eventadmin 1.2.12 This release fixes another regression introduced in a previous release: https://issues.apache.org/jira/browse/FELIX-2915 Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-023/ 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 023 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] framework 3.2.2 and related subproject
+1 (non binding) regards; /Pierre On Tue, May 17, 2011 at 11:04 PM, Karl Pauls wrote: > I would like to call a vote on the following subproject releases: > > framework 3.2.2 > main 3.2.2 > main.distribution 3.2.2 > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-020/ > > 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 020 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) >
Re: [VOTE] framework 3.2.2 and related subproject
+1
