New Parent POM (Re: FELIX-1747)
Hi all, At long last I have now committed the changes to the Felix parent POM described in FELIX-1747 [1]. Along with this I have committed changes to the Configuration Admin (configadmin) and Declarative Services (scr) projects to use this new parent POM. To see, what this parent POM is all about with respect to releasing look particularly at these things in the configadmin and scr projects: * Extensions to precanned LICENSE, NOTICE, and DEPENDENCIES files can be provided in the src/main/appended-resources folder. See the scr project for an example * To see the outcome of a release build run the following mvn command: $ mvn -Papache-release clean verify This will build the project run all tests, generate artifacts for releasing, checks files with the RAT plugin and uses the IANAL plugin to verify the presence of required legal files. WDYT ? Next step -- if we would want to pursue this -- would be to release the new parent POM and start converting the projects ... Regards Felix [1] https://issues.apache.org/jira/browse/FELIX-1747
[jira] Commented: (FELIX-1747) Use Remote Resources Plugin to generate the legal files
[ https://issues.apache.org/jira/browse/FELIX-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990817#comment-12990817 ] Felix Meschberger commented on FELIX-1747: -- I have finally commited the following changes: Rev. 1067334/1067334 - Parent POM changes Rev. 1067335- Adapted Declarative Services bundle (SCR) Rev. 1067336- Adapted Configuration Admin bundle > Use Remote Resources Plugin to generate the legal files > --- > > Key: FELIX-1747 > URL: https://issues.apache.org/jira/browse/FELIX-1747 > Project: Felix > Issue Type: Wish >Reporter: Felix Meschberger > Attachments: FELIX-1747-apache-parent-7-v2.patch, > FELIX-1747-apache-parent-7.patch, > FELIX-1747-parent-pom-with-felix-assembly-descriptors.patch, > FELIX-1747-parent-pom.patch > > > Richard Hall started a discussion on the dev list to redo the Apache Felix > NOTICE file [1] and also created a Wiki page as the basis for further > discussion [2]. > I have now tried to convert the WebConsole project and the parent pom into > using the remote resources plugin. > The parent POM is modified to depend on the Apache parent 6, which already > includes the remote resources plugin setup. I also added the > maven-ianal-plugin which verifies the presence of the legal files (and IIRC > also runs rat on the source). I will attach the parent pom patch. > Note, that depending on the Apache parent 6, we can even get rid of most of > our release profile setup, which is already present in the Apache parent 6. > The modified Web Console project is available in my sandbox at [3]. The > changes are > - depend on the snapshot parent pom (expecting modification patch applied) > - removed all notice and license files from root folder > - created src/main/appended-resources folder with the following contents > - supplemental-models.xml for the JSON additional information (this > file is required only for incomplete dependencies) > - LICENSE.vm - additional licenses in one single file - will be merged > with ASL2 file > - NOTICE.vm - additional notes (only silk icons are required here) > The result is the correct LICENSE file (ASL2 plus all dependent licenses) and > correct NOTICE only containining required notes and finally a DEPENDENCIES > file listing M2 dependencies with their organizational and license > information. > One thing that is still missing from this setup is the correct setup of the > maven assembly plugin: This plugin does not pack the generated LICENSE and > NOTICE files using the plugin provided descriptors. The solution would be to > define our own descriptors in a separate project, which we can refer to in > the assembly plugin setup (see [4] for how we could do this). This would > simplify parent pom setup for releases even more because we could define the > descriptors without bz2 generation and directly attach the generated > assemblies. > [1] http://markmail.org/thread/x2gcnlwil46imks3 > [2] > http://cwiki.apache.org/confluence/display/FELIX/NOTICE+file+template+%28PROPOSED%29 > [3] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/webconsole_notice > [4] > http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2741) NPE in ResolverImpl.calculatePackageSpaces
[ https://issues.apache.org/jira/browse/FELIX-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990801#comment-12990801 ] Ancoron Luciferis commented on FELIX-2741: -- That could indeed be an issue. I'm still unable to reproduce it, once I get to see a similar exception and with the latest versions of GlassFish 3.1 I had few luck in producing such an issue and even if I was "able" to produce it I was completely unable to reproduce it. But as it always seems to be related to "DynamicImport-Package" stuff, I think the system bundle could be involved here. > NPE in ResolverImpl.calculatePackageSpaces > -- > > Key: FELIX-2741 > URL: https://issues.apache.org/jira/browse/FELIX-2741 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.0.6 >Reporter: Sahoo > Fix For: framework-3.2.0 > > > A GlassFish user has reported a NPE while doing stress testing and the stack > is given below: > [#|2010-12-22T11:28:28.910+0100|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=18;_ThreadName=Thread-1;|java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:557) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:619) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:619) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:94) > at > org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:3982) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3397) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1714) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1136) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1122) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1115) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:433) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241) > |#] > m_wires must be null for this NPE to be caused by the following code: > for (Wire wire : module.getWires()) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2824. -- Resolution: Fixed Fixed in Rev. 1067309 by setting up the configuration support instance in case the configuration admin service is already registered when declarative services starts > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990768#comment-12990768 ] Felix Meschberger commented on FELIX-2824: -- With the refactoring of FELIX-2578 the new configuration support instance is created upon a Service event received from the Configuration Admin service registration. If the ConfigurationAdmin service is already active before the Declarative Services bundle is started, this service event is never received by the DS bundle and thus the configuration support instance is not created. > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (FELIX-2819) packageinfo files in src/main/java are ignored
[ https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990756#comment-12990756 ] Alasdair Nottingham edited comment on FELIX-2819 at 2/4/11 9:34 PM: That said, words is all you'll get, but thanks again. Alasdair was (Author: not): That said, works is all you'll get, but thanks again. Alasdair > packageinfo files in src/main/java are ignored > -- > > Key: FELIX-2819 > URL: https://issues.apache.org/jira/browse/FELIX-2819 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Reporter: Alasdair Nottingham > > The bnd tool can pick up the package version from a packageinfo file if it is > stored next to the java files. > The maven-bundle-plugin will only include them in the jar, and make them > visible to bnd if they are in the src/main/resources directory. I would like > to use these files for specifying versions, rather than putting it in the > pom. This allows me to specify the version once in this file even if it is > repackaged in a different jar later. > The problem is I have to put the files into src/main/resources which > significantly reduces the chance of updating them when a change is made. > Could the maven-bundle-plugin be updated to put the packageinfo files from > src/main/java into the jar before calling bnd? > Thanks > Alasdair -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
On 2/4/11 16:23, Alasdair Nottingham wrote: Assuming my vote counts, something I'm not sure about since I'm not a felix committer and I never could work out that part of the "rules" Technically, only PMC members vote count for legal purposes, but for something like this, I think we can use what ever definition of consensus we want. -> richard On 4 February 2011 17:17, Richard S. Hall wrote: On 2/4/11 12:10, Alasdair Nottingham wrote: In that case I change my non-binding B vote to a non-binding A vote. A (non-binding). The balance has tipped...A is now ahead by two! :-o -> richard On 4 February 2011 16:37, Richard S. Hallwrote: On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does "failed release" mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. ->richard Jeremy On 4 February 2011 08:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (FELIX-2819) packageinfo files in src/main/java are ignored
[ https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990756#comment-12990756 ] Alasdair Nottingham commented on FELIX-2819: That said, works is all you'll get, but thanks again. Alasdair > packageinfo files in src/main/java are ignored > -- > > Key: FELIX-2819 > URL: https://issues.apache.org/jira/browse/FELIX-2819 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Reporter: Alasdair Nottingham > > The bnd tool can pick up the package version from a packageinfo file if it is > stored next to the java files. > The maven-bundle-plugin will only include them in the jar, and make them > visible to bnd if they are in the src/main/resources directory. I would like > to use these files for specifying versions, rather than putting it in the > pom. This allows me to specify the version once in this file even if it is > repackaged in a different jar later. > The problem is I have to put the files into src/main/resources which > significantly reduces the chance of updating them when a change is made. > Could the maven-bundle-plugin be updated to put the packageinfo files from > src/main/java into the jar before calling bnd? > Thanks > Alasdair -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2819) packageinfo files in src/main/java are ignored
[ https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990755#comment-12990755 ] Alasdair Nottingham commented on FELIX-2819: Words alone cannot express my joy at learning about this workaround. Thank you very much. Alasdair > packageinfo files in src/main/java are ignored > -- > > Key: FELIX-2819 > URL: https://issues.apache.org/jira/browse/FELIX-2819 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Reporter: Alasdair Nottingham > > The bnd tool can pick up the package version from a packageinfo file if it is > stored next to the java files. > The maven-bundle-plugin will only include them in the jar, and make them > visible to bnd if they are in the src/main/resources directory. I would like > to use these files for specifying versions, rather than putting it in the > pom. This allows me to specify the version once in this file even if it is > repackaged in a different jar later. > The problem is I have to put the files into src/main/resources which > significantly reduces the chance of updating them when a change is made. > Could the maven-bundle-plugin be updated to put the packageinfo files from > src/main/java into the jar before calling bnd? > Thanks > Alasdair -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
Assuming my vote counts, something I'm not sure about since I'm not a felix committer and I never could work out that part of the "rules" On 4 February 2011 17:17, Richard S. Hall wrote: > On 2/4/11 12:10, Alasdair Nottingham wrote: >> >> In that case I change my non-binding B vote to a non-binding A vote. >> >> A (non-binding). > > The balance has tipped...A is now ahead by two! :-o > > -> richard > >> On 4 February 2011 16:37, Richard S. Hall wrote: >>> >>> On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does "failed release" mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. >>> >>> Yes, (ii). This is when we call a vote, but then decide to cancel the >>> vote >>> for some reason. So the artifacts have never made it into maven central >>> or >>> apache.org/dist. >>> >>> -> richard >>> Jeremy On 4 February 2011 08:50, Guillaume Nodet wrote: > > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different > version > > The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > >> >> > -- Alasdair Nottingham n...@apache.org
[jira] Issue Comment Edited: (FELIX-2819) packageinfo files in src/main/java are ignored
[
https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990744#comment-12990744
]
Simon Chemouil edited comment on FELIX-2819 at 2/4/11 9:17 PM:
---
By the way, if you're not doing it already (or for people who might read this
issue), here's the cleanest workaround :
{code:XML}
src/main/resources
${project.build.sourceDirectory}
**/*.java
**/.*
${project.build.sourceDirectory}
**/packageinfo
{code}
On our project we put the "include all resources that are in src/" rule in a
parent POM... Of course, it would still be nice if maven-bundle-plugin would
manage bnd-related files out-of-the-box.
Hope this helps,
Simon
Edit: formating is completely messed up...
was (Author: magnet):
By the way, if you're not doing it already (or for people who might read
this issue), here's the cleanest workaround :
{code:XML}
src/main/resources
${project.build.sourceDirectory}
**/*.java
**/.*
${project.build.sourceDirectory}
**/packageinfo
{code}
On our project we put the "include all resources that are in src/" rule in a
parent POM... Of course, it would still be nice if maven-bundle-plugin would
manage bnd-related files out-of-the-box.
Hope this helps,
Simon
> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them
> visible to bnd if they are in the src/main/resources directory. I would like
> to use these files for specifying versions, rather than putting it in the
> pom. This allows me to specify the version once in this file even if it is
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which
> significantly reduces the chance of updating them when a change is made.
> Could the maven-bundle-plugin be updated to put the packageinfo files from
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (FELIX-2819) packageinfo files in src/main/java are ignored
[
https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990744#comment-12990744
]
Simon Chemouil edited comment on FELIX-2819 at 2/4/11 9:14 PM:
---
By the way, if you're not doing it already (or for people who might read this
issue), here's the cleanest workaround :
{code:XML}
src/main/resources
${project.build.sourceDirectory}
**/*.java
**/.*
${project.build.sourceDirectory}
**/packageinfo
{code}
On our project we put the "include all resources that are in src/" rule in a
parent POM... Of course, it would still be nice if maven-bundle-plugin would
manage bnd-related files out-of-the-box.
Hope this helps,
Simon
was (Author: magnet):
By the way, if you're not doing it already (or for people who might read
this issue), here's the cleanest workaround :
src/main/resources
${project.build.sourceDirectory}
**/*.java
**/.*
${project.build.sourceDirectory}
**/packageinfo
On our project we put the "include all resources that are in src/" rule in a
parent POM... Of course, it would still be nice if maven-bundle-plugin would
manage bnd-related files out-of-the-box.
Hope this helps,
Simon
> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them
> visible to bnd if they are in the src/main/resources directory. I would like
> to use these files for specifying versions, rather than putting it in the
> pom. This allows me to specify the version once in this file even if it is
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which
> significantly reduces the chance of updating them when a change is made.
> Could the maven-bundle-plugin be updated to put the packageinfo files from
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2819) packageinfo files in src/main/java are ignored
[
https://issues.apache.org/jira/browse/FELIX-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990744#comment-12990744
]
Simon Chemouil commented on FELIX-2819:
---
By the way, if you're not doing it already (or for people who might read this
issue), here's the cleanest workaround :
src/main/resources
${project.build.sourceDirectory}
**/*.java
**/.*
${project.build.sourceDirectory}
**/packageinfo
On our project we put the "include all resources that are in src/" rule in a
parent POM... Of course, it would still be nice if maven-bundle-plugin would
manage bnd-related files out-of-the-box.
Hope this helps,
Simon
> packageinfo files in src/main/java are ignored
> --
>
> Key: FELIX-2819
> URL: https://issues.apache.org/jira/browse/FELIX-2819
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Reporter: Alasdair Nottingham
>
> The bnd tool can pick up the package version from a packageinfo file if it is
> stored next to the java files.
> The maven-bundle-plugin will only include them in the jar, and make them
> visible to bnd if they are in the src/main/resources directory. I would like
> to use these files for specifying versions, rather than putting it in the
> pom. This allows me to specify the version once in this file even if it is
> repackaged in a different jar later.
> The problem is I have to put the files into src/main/resources which
> significantly reduces the chance of updating them when a change is made.
> Could the maven-bundle-plugin be updated to put the packageinfo files from
> src/main/java into the jar before calling bnd?
> Thanks
> Alasdair
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (FELIX-2741) NPE in ResolverImpl.calculatePackageSpaces
[ https://issues.apache.org/jira/browse/FELIX-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990743#comment-12990743 ] Richard S. Hall edited comment on FELIX-2741 at 2/4/11 9:13 PM: I have to believe this is related to FELIX-2822 if not the same thing, since no other module should be able to have null wires. was (Author: rickhall): I have to believe these two are actually the same thing, since no other module should be able to have null wires. > NPE in ResolverImpl.calculatePackageSpaces > -- > > Key: FELIX-2741 > URL: https://issues.apache.org/jira/browse/FELIX-2741 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-3.0.6 >Reporter: Sahoo > Fix For: framework-3.2.0 > > > A GlassFish user has reported a NPE while doing stress testing and the stack > is given below: > [#|2010-12-22T11:28:28.910+0100|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=18;_ThreadName=Thread-1;|java.lang.NullPointerException > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:557) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:619) > at > org.apache.felix.framework.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:619) > at > org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:94) > at > org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:3982) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3397) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1714) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1136) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1122) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1115) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:433) > at > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241) > |#] > m_wires must be null for this NPE to be caused by the following code: > for (Wire wire : module.getWires()) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
Well, I'm on the fence. On the one hand, I doubt that it helps much to skip the release number but granted, it might help for the bookkeeping in rather strange cases. On the other hand, it can suck a bit to not have a 1.0.0 version for example but at the same time, it's not super important either as I don't think we should worry about "marketing versions" much. Overall, I guess I'm slightly in favor of A but mostly because of the _can_ v.s. the _must_ of B. I think we should just let the release manager of the vote make that decision on a case by case basis (especially, as we clearly have no consensus on the topic). +1 for A (assuming its a _can_ and not a _must_) regards, Karl On Fri, Feb 4, 2011 at 5:17 PM, Richard S. Hall wrote: > On 2/4/11 11:11, Stuart McCulloch wrote: >> >> On 4 February 2011 16:09, Richard S. Hall wrote: >> >>> So far, we are tied. :-) >> >> I guess that means you get the casting vote ;) > > No, no. I'm maintaining my 0. :-) > > Perhaps Karl has an opinion. > > -> richard > >>> On 2/4/11 3:50, Guillaume Nodet wrote: >>> Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! > -- Karl Pauls karlpa...@gmail.com
[jira] Resolved: (FELIX-2766) Calling update() on a newly created factory configuration causes FileNotFoundException
[ https://issues.apache.org/jira/browse/FELIX-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2766. -- Resolution: Fixed Assignee: Felix Meschberger I chose a slightly different approach in that I check for the existence of configuration in the update() method itself and only read if so. In addition the UpdateTask has a bug with respect to updating newly created configurations: When updating ManagedServiceFactory services nothing is done; when updating ManagedService services a NullPointerException is thrown because there is no guard against no dictionary (as is the case for newly created configurations. To fix this, the UpdateTask assumes an empty dictionary for newly created configurations whose getProperties() method returns null Fixed in Rev. 1067270 > Calling update() on a newly created factory configuration causes > FileNotFoundException > -- > > Key: FELIX-2766 > URL: https://issues.apache.org/jira/browse/FELIX-2766 > Project: Felix > Issue Type: Bug >Affects Versions: configadmin-1.2.8 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: configadmin-1.2.10 > > Attachments: felix-2766.diff > > > The following code throws java.io.FileNotFoundException > Configuration config = configurationAdmin.createFactoryConfiguration(name, > null); > config.update(); > because the Configuration is newly created and has never been persisted, but > the update() method tries to read the persistence file. > According to a comment by Peter Kriens on the OSGi Dev List [1], the update() > method should in this case just assume an empty dictionary and push this past > the configuration plugins into the ManagedServiceFactory service. > [1] http://www.mail-archive.com/osgi-dev@mail.osgi.org/msg01773.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-2824: Assignee: Felix Meschberger > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990671#comment-12990671 ] Felix Meschberger commented on FELIX-2824: -- Thanks for testing trunk and reporting the bug. I will look into it. > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
On Friday, February 4, 2011, Jeremy Hughes wrote: > Just to be clear does "failed release" mean: > > i) a release whose artifacts were published e.g. to apache.org/dist or > maven central then found to be bad Afaik, maven central has since a lng time a policy to never change a published artifact which definitely makes sense, so even if we want to do that (but which sane person would), it would not be possible. > ii) a release that failed before the artifacts were published > > I had been working to ii) but I can see there could be confusion. > > Jeremy > > On 4 February 2011 08:50, Guillaume Nodet wrote: >> Following the discussion, I'm starting a vote to decide on a policy >> for failed releases. >> >> [ ] A - Releases following a failed release can reuse the same version >> [ ] B - Releases following a failed release must use a different version >> >> The vote will be opened for at least 72 hours. >> Happy voting! >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
On 2/4/11 12:10, Alasdair Nottingham wrote: In that case I change my non-binding B vote to a non-binding A vote. A (non-binding). The balance has tipped...A is now ahead by two! :-o -> richard On 4 February 2011 16:37, Richard S. Hall wrote: On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does "failed release" mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. -> richard Jeremy On 4 February 2011 08:50, Guillaume Nodetwrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
In that case I change my non-binding B vote to a non-binding A vote. A (non-binding). On 4 February 2011 16:37, Richard S. Hall wrote: > On 2/4/11 11:29, Jeremy Hughes wrote: >> >> Just to be clear does "failed release" mean: >> >> i) a release whose artifacts were published e.g. to apache.org/dist or >> maven central then found to be bad >> ii) a release that failed before the artifacts were published >> >> I had been working to ii) but I can see there could be confusion. > > > Yes, (ii). This is when we call a vote, but then decide to cancel the vote > for some reason. So the artifacts have never made it into maven central or > apache.org/dist. > > -> richard > >> Jeremy >> >> On 4 February 2011 08:50, Guillaume Nodet wrote: >>> >>> Following the discussion, I'm starting a vote to decide on a policy >>> for failed releases. >>> >>> [ ] A - Releases following a failed release can reuse the same version >>> [ ] B - Releases following a failed release must use a different version >>> >>> The vote will be opened for at least 72 hours. >>> Happy voting! >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> >>> Blog: http://gnodet.blogspot.com/ >>> >>> Open Source SOA >>> http://fusesource.com >>> > -- Alasdair Nottingham n...@apache.org
[jira] Commented: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990620#comment-12990620 ] Stephen Flynn commented on FELIX-2824: -- Attached bundle should demonstrate the issue. SCR-1.6.0 activates 2 components as expected, not so with current SCR-1.6.2 snapshot. > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
[ https://issues.apache.org/jira/browse/FELIX-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Flynn updated FELIX-2824: - Attachment: policy-required-bug-example-1.0.0-sources.jar policy-required-bug-example-1.0.0.jar > Components that have a ConfigurationPolicy value of REQUIRE fail to activate > > > Key: FELIX-2824 > URL: https://issues.apache.org/jira/browse/FELIX-2824 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.2 > Environment: Felix 3.0.6 > Config admin 1.2.8 >Reporter: Stephen Flynn > Fix For: scr-1.6.2 > > Attachments: policy-required-bug-example-1.0.0-sources.jar, > policy-required-bug-example-1.0.0.jar > > > Components that have a ConfigurationPolicy value of REQUIRE are no longer > configured and activated by configuration admin. > This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
On 2/4/11 11:29, Jeremy Hughes wrote: Just to be clear does "failed release" mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Yes, (ii). This is when we call a vote, but then decide to cancel the vote for some reason. So the artifacts have never made it into maven central or apache.org/dist. -> richard Jeremy On 4 February 2011 08:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
Just to be clear does "failed release" mean: i) a release whose artifacts were published e.g. to apache.org/dist or maven central then found to be bad ii) a release that failed before the artifacts were published I had been working to ii) but I can see there could be confusion. Jeremy On 4 February 2011 08:50, Guillaume Nodet wrote: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com >
Re: [VOTE] Versioning after a failed release
On 2/4/11 11:11, Stuart McCulloch wrote: On 4 February 2011 16:09, Richard S. Hall wrote: So far, we are tied. :-) I guess that means you get the casting vote ;) No, no. I'm maintaining my 0. :-) Perhaps Karl has an opinion. -> richard On 2/4/11 3:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
Re: [VOTE] Versioning after a failed release
On 4 February 2011 16:09, Richard S. Hall wrote: > So far, we are tied. :-) I guess that means you get the casting vote ;) -> richard > > On 2/4/11 3:50, Guillaume Nodet wrote: > >> Following the discussion, I'm starting a vote to decide on a policy >> for failed releases. >> >> [ ] A - Releases following a failed release can reuse the same version >> [ ] B - Releases following a failed release must use a different version >> >> The vote will be opened for at least 72 hours. >> Happy voting! >> > -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
So far, we are tied. :-) -> richard On 2/4/11 3:50, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
[jira] Created: (FELIX-2824) Components that have a ConfigurationPolicy value of REQUIRE fail to activate
Components that have a ConfigurationPolicy value of REQUIRE fail to activate Key: FELIX-2824 URL: https://issues.apache.org/jira/browse/FELIX-2824 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.2 Environment: Felix 3.0.6 Config admin 1.2.8 Reporter: Stephen Flynn Fix For: scr-1.6.2 Components that have a ConfigurationPolicy value of REQUIRE are no longer configured and activated by configuration admin. This was working fine in scr-1.6.0 and earlier versions. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
[X] B - Releases following a failed release must use a different version Carsten Guillaume Nodet wrote > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! > -- Carsten Ziegeler cziege...@apache.org
[jira] Resolved: (FELIX-2771) Configuration Admin does not work on Foundation 1.2 and Mika
[ https://issues.apache.org/jira/browse/FELIX-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2771. -- Resolution: Fixed Fix Version/s: configadmin-1.2.10 Assignee: Felix Meschberger Thanks for reporting these issues. I have fixed them in Rev. 1067154 as follows: PrivilegedActionException: use getException() instead of getCause() Boolean.valueOf(boolean): use boolean ? TRUE : FALSE SecureRandom: fall back to Random > Configuration Admin does not work on Foundation 1.2 and Mika > > > Key: FELIX-2771 > URL: https://issues.apache.org/jira/browse/FELIX-2771 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.2.8 >Reporter: Clement Escoffier >Assignee: Felix Meschberger >Priority: Minor > Fix For: configadmin-1.2.10 > > > The configuration admin implementation uses classes and methods not available > in Foundation and/or Mika. > In Foundation: > The method getCause() is undefined for the type PrivilegedActionException > The method valueOf(String) in the type Boolean does not exist for the > arguments (boolean) > On Mika, the SecureRandom class is not available: > couldn't find a SecureRandom > at java.security.SecureRandom.(SecureRandom.java:78) > at > org.apache.felix.cm.impl.ConfigurationManager.createPid(ConfigurationManager.java:870) > at > org.apache.felix.cm.impl.ConfigurationManager.createFactoryConfiguration(ConfigurationManager.java:450) > at > org.apache.felix.cm.impl.ConfigurationAdminImpl.createFactoryConfiguration(ConfigurationAdminImpl.java:84) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
On 4 February 2011 08:50, Guillaume Nodet wrote: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > +1 for A ... while I understand the reasons behind B, I just don't like the idea of making it mandatory TBH users shouldn't be affected by restaging as the staged binaries never reach Maven central, and it is easy to retag releases in svn The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Stuart
Re: [VOTE] Versioning after a failed release
A (non-binding) (We were using the maven bundle plugin 2.3.0 snapshot here, and I think the re-release in the end is more trouble to follow than restarting the release process with the same version after it failed -- after all there was no 2.3.0 release). Simon On Fri, Feb 4, 2011 at 11:59 AM, Andreas Pieber wrote: > A (non-binding) > > kind regards, > andreas > > On Fri, Feb 04, 2011 at 09:50:35AM +0100, Guillaume Nodet wrote: > > Following the discussion, I'm starting a vote to decide on a policy > > for failed releases. > > > > [ ] A - Releases following a failed release can reuse the same version > > [ ] B - Releases following a failed release must use a different version > > > > The vote will be opened for at least 72 hours. > > Happy voting! > > > > -- > > Cheers, > > Guillaume Nodet > > > > Blog: http://gnodet.blogspot.com/ > > > > Open Source SOA > > http://fusesource.com >
[jira] Resolved: (FELIX-2682) Implements proposed Configuration Admin Service extensions
[ https://issues.apache.org/jira/browse/FELIX-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2682. -- Resolution: Won't Fix It looks like the Configuration Admin service extensions have been dropped from the R4.3 release in favor of bringing more substantial changes in a later release... Thus, I resolve this issue for now > Implements proposed Configuration Admin Service extensions > -- > > Key: FELIX-2682 > URL: https://issues.apache.org/jira/browse/FELIX-2682 > Project: Felix > Issue Type: Task > Components: Configuration Admin, Specification compliance >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > The OSGi R4.3 Draft 2 specification contains a number of enhancements to the > Configuration Admin Service, which we should start to implement: >* Bundle Locations are not used and respected any more (i.e. Configuration > assigned is not restricted by location) >* get/setBundleLocation methods are deprecated aliases for the new > get/setGroup methods >* Configuration assignement is now restricted by group and enforced by > Java 2 security permissions > (If security is not enabled, group restrictions are not enforced) >* new Configuration.getChangeCount() method >* Targetted PIDs >* Services may share configurations with the same PID (all services with a > given PID are provided with the configuration) >* Coordinator Service support >* more fine-grained permission model > This issue is not about the "User Friendly Configuration" specification. This > specification is handled in a separate bundle and will most probably also end > up in its own Service specification. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
A (non-binding) kind regards, andreas On Fri, Feb 04, 2011 at 09:50:35AM +0100, Guillaume Nodet wrote: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com pgpzdwaqImBAe.pgp Description: PGP signature
[jira] Resolved: (FELIX-2578) Declarative Services bundle does not start without Configuration Admin API wired
[ https://issues.apache.org/jira/browse/FELIX-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2578. -- Resolution: Fixed Refactored Configuration Admin Support in Rev. 1067145: The ConfigurationAdmin (and Metatype) APIs are dynamically bound on demand The bundle's own configuration is now retrieved using a ManagedService registered as using the ServiceFactory pattern. The component configuration is refactored in that there is a support class interface between the component registry and Configuration Admin. The support class is only instantiated once the Configuration Admin service is available. Once the service is unregistered the support class is removed again. This support class not only provides initial component configuration but also configuration updates by registering a ConfigurationListener. I have tested it in a Sling environment and so far all looks good. > Declarative Services bundle does not start without Configuration Admin API > wired > > > Key: FELIX-2578 > URL: https://issues.apache.org/jira/browse/FELIX-2578 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.6.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-1.6.2 > > Attachments: patch > > > The Declarative Services bundle imports the Configuration Admin package > (org.osgi.service.cm) optionally with the intent to be able to operate > without the Configuration Admin Service and its API present. > In reality, the bundle does not start without the API being wired with the > following exception: > org.osgi.framework.BundleException: Activator start error in bundle > org.apache.felix.scr [5]. > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1864) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1734) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892) > [...] > Caused by: java.lang.NoClassDefFoundError: > org/osgi/service/cm/ConfigurationListener > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:621) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1829) > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:716) > at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > at java.lang.Class.getConstructor0(Class.java:2699) > at java.lang.Class.newInstance0(Class.java:326) > at java.lang.Class.newInstance(Class.java:308) > at > org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3659) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:1812) > ... 31 more > Caused by: java.lang.ClassNotFoundException: > org.osgi.service.cm.ConfigurationListener > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772) > at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > ... 46 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Versioning after a failed release
B (non-binding) Alasdair Nottingham On 4 Feb 2011, at 09:42, Guillaume Nodet wrote: > A > > On Fri, Feb 4, 2011 at 09:50, Guillaume Nodet wrote: >> Following the discussion, I'm starting a vote to decide on a policy >> for failed releases. >> >> [ ] A - Releases following a failed release can reuse the same version >> [ ] B - Releases following a failed release must use a different version >> >> The vote will be opened for at least 72 hours. >> Happy voting! >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com
Re: [VOTE] Versioning after a failed release
A On Fri, Feb 4, 2011 at 09:50, Guillaume Nodet wrote: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Versioning after a failed release
I'm voting for B: use different version numbers for each "attempt" On 4 Feb 2011, at 9:50 , Guillaume Nodet wrote: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com
Re: [VOTE] Versioning after a failed release
B - Releases following a failed release must use a different version. For me traceability is key. Much more transparent to the user. Toni On Fri, Feb 4, 2011 at 10:05 AM, Felix Meschberger wrote: > Hi, > > B - never reuse version numbers > > Regards > Felix > > Am Freitag, den 04.02.2011, 08:50 + schrieb Guillaume Nodet: > > Following the discussion, I'm starting a vote to decide on a policy > > for failed releases. > > > > [ ] A - Releases following a failed release can reuse the same version > > [ ] B - Releases following a failed release must use a different version > > > > The vote will be opened for at least 72 hours. > > Happy voting! > > > > > -- *Toni Menzel - http://www.okidokiteam.com*
Re: [VOTE] Versioning after a failed release
Hi, B - never reuse version numbers Regards Felix Am Freitag, den 04.02.2011, 08:50 + schrieb Guillaume Nodet: > Following the discussion, I'm starting a vote to decide on a policy > for failed releases. > > [ ] A - Releases following a failed release can reuse the same version > [ ] B - Releases following a failed release must use a different version > > The vote will be opened for at least 72 hours. > Happy voting! >
Re: [VOTE] Versioning after a failed release
+1 for A. Regards JB On 02/04/2011 09:50 AM, Guillaume Nodet wrote: Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting!
[VOTE] Versioning after a failed release
Following the discussion, I'm starting a vote to decide on a policy for failed releases. [ ] A - Releases following a failed release can reuse the same version [ ] B - Releases following a failed release must use a different version The vote will be opened for at least 72 hours. Happy voting! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Re-trying releases
Fair enough. I'll start a vote now. On Fri, Feb 4, 2011 at 09:39, Carsten Ziegeler wrote: > Guillaume Nodet wrote >> On Fri, Feb 4, 2011 at 02:52, Richard S. Hall wrote: >>> >>> If enough people respond maybe we can reach some sort of consensus...or else >>> we could call a vote on it. >> >> Can other felix members speak here ? >> > I guess we don't find consensus by just discussing :) Some of us prefer > it this way, others the other way. I prefer increasing the version > number for each retry, it requires no additional work (except changing > the version in jira) and makes it easier to track if people are using > failed releases. Sure, comparing the hash of the binary artifact would > solve this as well, but just looking at the version number is soo easy :) > > If - as a project - we agree to use the same version number for retries > I'm ok with as well. > > But I agree we should do this consistently and just write it down > somewhere. So let's call a vote and the majority wins :) > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Re-trying releases
Guillaume Nodet wrote > On Fri, Feb 4, 2011 at 02:52, Richard S. Hall wrote: >> >> If enough people respond maybe we can reach some sort of consensus...or else >> we could call a vote on it. > > Can other felix members speak here ? > I guess we don't find consensus by just discussing :) Some of us prefer it this way, others the other way. I prefer increasing the version number for each retry, it requires no additional work (except changing the version in jira) and makes it easier to track if people are using failed releases. Sure, comparing the hash of the binary artifact would solve this as well, but just looking at the version number is soo easy :) If - as a project - we agree to use the same version number for retries I'm ok with as well. But I agree we should do this consistently and just write it down somewhere. So let's call a vote and the majority wins :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release fileinstall-3.1.10
Works for me. Thank you! +1 (non-binding) kind regards, andreas On Wed, Feb 02, 2011 at 03:37:15PM +0100, Guillaume Nodet wrote: > Vote on fileinstall .3.1.10 > > This release fixes three issues > https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8&version=12316134&styleName=Text&projectId=12310100&Create=Create > * [FELIX-2798] - ArtifactListener services are not ordered > according to the OSGi ranking > * [FELIX-2799] - FileInstall creates multiple configurations for > factory configurations on windows > * [FELIX-2818] - File Install does not support empty configuration > when no configuration already exists > > The staging repo is available at: > https://repository.apache.org/content/repositories/orgapachefelix-026/ > > 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 026 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com pgppDH2N34kZx.pgp Description: PGP signature
Re: [Fwd: New Autoexport version to be installed into Confluence]
Hi, Am Freitag, den 04.02.2011, 07:37 + schrieb Marcel Offermans: > Hello Felix, > > Thanks. Two small issues: > > It looks like you've copied the trademark notice footer from Sling (it still > reads Sling instead of Felix). Yes, I did. Ooops ;-) Fixed and re-exported. > There seems to be some whitespace in the word "Foun_dation". Yep, this is a copy-paste issue. Fixed, too. Thanks for noting. Regards Felix > > Greetings, Marcel > > > On 4 Feb 2011, at 7:45 , Felix Meschberger wrote: > > > I have made a backup of our Site Template at [1]. > > > > While being at it, I added two divs: > > - Information on the last modification (who, when) of the page > > - Trademark notices as required by the new trademark guidelines > > > > ... and of course I exported the site to include these changes. > > > > Regards > > Felix > > > > [1] http://people.apache.org/~fmeschbe/confluence/FELIX.vm > > > > From: "Gav..." > > Date: 4 February 2011 7:08:18 GMT+01:00 > > To: > > Subject: New Autoexport version to be installed into Confluence > > > > > > Hi All, > > > > On Sunday 6th February I intend to remove the current AutoExport version we > > are > > currently using (-dkulp1.0 altered by Uli :) ) and replace it with the new > > version now hosted and maintained at Atlassian version [1]. > > > > Any project with altered templates might want to consider saving them > > elsewhere > > before this change occurs. > > > > Gav... > > > > > > [1] - https://plugins.atlassian.com/plugin/details/33010 > > > > > > > > > > > > >
