[CANCEL] [VOTE] Release maven-bundle-plugin 2.3.0
I'll recut a release to fix the legal stuff. On Mon, Jan 31, 2011 at 17:45, Guillaume Nodet gno...@gmail.com wrote: I would like to call a vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-020/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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) -- 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
[jira] Created: (FELIX-2818) File Install does not support empty configuration when no configuration already exists
File Install does not support empty configuration when no configuration already exists -- Key: FELIX-2818 URL: https://issues.apache.org/jira/browse/FELIX-2818 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.1.8 Reporter: Clement Escoffier Assignee: Clement Escoffier If you have an empty cfg (for a ManagedServiceFactory) file in a folder managed by file install, and if this configuration was never pushed, the configuration will never be pushed. File Install checks if there is an existing configuration, if not create an empty HashTable. As the cfg file is empty, the two Hashtables are equals and so the configuration is not pushed to the configuration admin. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release webconsole 3.1.8
+1 I've updated the copyright in NOTICE and DEPENDENCIES files. On Tue, Feb 1, 2011 at 20:28, Richard S. Hall he...@ungoverned.org wrote: On 2/1/11 13:58, Carsten Ziegeler wrote: Richard S. Hall wrote The copyright year wasn't updated...I can't remember, do we consider this a big deal or not? No, we don't :) Ok, then: +1 Please update the copyright years in the NOTICE and DEPENDENCIES files in trunk. - richard Carsten - richard On 2/1/11 3:16, Guillaume Nodet wrote: This release fixes several issues * [FELIX-2713] - Problem in HtmlConfigurationWriter * [FELIX-2729] - Webconsole - Configuration fails to print configuration for bundles without MetatypeService config * [FELIX-2735] - ClassCastException in PermissionsConfigurationPrinter * [FELIX-2793] - Plugin request is not detected as html request if context path contains a dot * [FELIX-2795] - Parameters are not removed from symbolic name when installing a bundle The staging repo is available at: 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) This vote will be open for 72 hours. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Resolved: (FELIX-2818) File Install does not support empty configuration when no configuration already exists
[ https://issues.apache.org/jira/browse/FELIX-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-2818. -- Resolution: Fixed Fixed in trunk. File Install does not support empty configuration when no configuration already exists -- Key: FELIX-2818 URL: https://issues.apache.org/jira/browse/FELIX-2818 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.1.8 Reporter: Clement Escoffier Assignee: Clement Escoffier If you have an empty cfg (for a ManagedServiceFactory) file in a folder managed by file install, and if this configuration was never pushed, the configuration will never be pushed. File Install checks if there is an existing configuration, if not create an empty HashTable. As the cfg file is empty, the two Hashtables are equals and so the configuration is not pushed to the configuration admin. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2818) File Install does not support empty configuration when no configuration already exists
[ https://issues.apache.org/jira/browse/FELIX-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-2818: - Fix Version/s: fileinstall-3.1.10 Just update the fix version. File Install does not support empty configuration when no configuration already exists -- Key: FELIX-2818 URL: https://issues.apache.org/jira/browse/FELIX-2818 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.1.8 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: fileinstall-3.1.10 If you have an empty cfg (for a ManagedServiceFactory) file in a folder managed by file install, and if this configuration was never pushed, the configuration will never be pushed. File Install checks if there is an existing configuration, if not create an empty HashTable. As the cfg file is empty, the two Hashtables are equals and so the configuration is not pushed to the configuration admin. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
+1 Regards JB On 02/02/2011 10:41 AM, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
Hi, -1 Sorry to veto this vote. AFAICT you cannot try again with the same version number. Regards Felix Am Mittwoch, den 02.02.2011, 09:41 + schrieb Guillaume Nodet: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release fileinstall-3.1.8 (2nd try)
Hi -1 Sorry to veto the vote. AFAICT you cannot retry with the same version number. Regards Felix Am Montag, den 31.01.2011, 08:34 + schrieb Guillaume Nodet: Same as before, but the release actually contains both fixes and an updated changelog This release fixes two issues https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310100fixfor=12316099 * FELIX-2799 FileInstall creates multiple configurations for factory configurations on windows * FELIX-2798 ArtifactListener services are not ordered according to the OSGi ranking The staging repo is available at: https://repository.apache.org/content/repositories/orgapachefelix-017/ 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 017 /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.
[DISCUSS] Re-trying releases
Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[CANCEL] [VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
I cancel this release and will re-spin a 2.3.2 asap. On Wed, Feb 2, 2011 at 11:19, Felix Meschberger fmesc...@adobe.com wrote: Hi, -1 Sorry to veto this vote. AFAICT you cannot try again with the same version number. Regards Felix Am Mittwoch, den 02.02.2011, 09:41 + schrieb Guillaume Nodet: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [CANCEL] [VOTE] Release fileinstall-3.1.8 (2nd try)
Hi, Does this release will contain the fixed I committed this morning (FELIX-2818) ? Regards, Clement On 02.02.11 15:06, Guillaume Nodet gno...@gmail.com wrote: I cancel this release and will re-spin a 3.1.10 now. On Wed, Feb 2, 2011 at 11:21, Felix Meschberger fmesc...@adobe.com wrote: Hi -1 Sorry to veto the vote. AFAICT you cannot retry with the same version number. Regards Felix Am Montag, den 31.01.2011, 08:34 + schrieb Guillaume Nodet: Same as before, but the release actually contains both fixes and an updated changelog This release fixes two issues https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid =12310100fixfor=12316099 * FELIX-2799 FileInstall creates multiple configurations for factory configurations on windows * FELIX-2798 ArtifactListener services are not ordered according to the OSGi ranking The staging repo is available at: https://repository.apache.org/content/repositories/orgapachefelix-017/ 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 017 /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
[VOTE] Release fileinstall-3.1.10
Vote on fileinstall .3.1.10 This release fixes three issues https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316134styleName=TextprojectId=12310100Create=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
Re: [CANCEL] [VOTE] Release fileinstall-3.1.8 (2nd try)
Yes. On Wed, Feb 2, 2011 at 15:20, Clement Escoffier clement.escoff...@gmail.com wrote: Hi, Does this release will contain the fixed I committed this morning (FELIX-2818) ? Regards, Clement On 02.02.11 15:06, Guillaume Nodet gno...@gmail.com wrote: I cancel this release and will re-spin a 3.1.10 now. On Wed, Feb 2, 2011 at 11:21, Felix Meschberger fmesc...@adobe.com wrote: Hi -1 Sorry to veto the vote. AFAICT you cannot retry with the same version number. Regards Felix Am Montag, den 31.01.2011, 08:34 + schrieb Guillaume Nodet: Same as before, but the release actually contains both fixes and an updated changelog This release fixes two issues https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid =12310100fixfor=12316099 * FELIX-2799 FileInstall creates multiple configurations for factory configurations on windows * FELIX-2798 ArtifactListener services are not ordered according to the OSGi ranking The staging repo is available at: https://repository.apache.org/content/repositories/orgapachefelix-017/ 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 017 /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 -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Re-trying releases
Hi, Am Mittwoch, den 02.02.2011, 14:01 + schrieb Guillaume Nodet: The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) Probably yes. So I have to apologize to have rushed in with a would-be-veto. I should rather only have raised my concern without placing a vote. Last, remember each PMC decides on its own rules to govern its project. Right -- to a certain degree. There are things a PMC cannot decide on. And this is what makes the ASF strong. So the fact Roy sent an email on Jackrabbit doesn't make it an official policy for the ASF (and the ASF itself doesn't care about such technical details). Since I could not come up with any official policy and assuming that thus there is none, I have to agree with you here ... I'll re-roll those releases, Thanks a lot. but I'd like things to be agreed upon *and* documented at some point. Agreed. My opinion is to state, that each vote must be with a new, increased version number regardless of the outcome (success or failure) or earlier votes of the same project. Regards Felix On Wed, Feb 2, 2011 at 14:59, Guillaume Nodet gno...@gmail.com wrote: On Wed, Feb 2, 2011 at 14:18, Felix Meschberger fmesc...@adobe.com wrote: Hi, My vetoes (actually there is no veto in a release vote since this is a majority vote) I know there's no vetoes in releases, but the goal is usually to gather a consensus. The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) are grounded on a message Roy Fielding once sent to the Jackrabbit list [1]: The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). I suppose that depends on the definition of most. Over the dozen of projects I'm involved at the ASF, this is the first time I see that. Maybe for projects like httpd that was the case, but I don't expect many people that aren't felix committers to have downloaded those released in the last 48 hours, so I still stand by the fact that in our case, people are very aware that the jars aren't official yet. Anyway, if that's us becoming an official Felix project policy, I'd like that to be written somewhere. Oral tradition is not really good for newcomers ;-) Unfortunately I cannot readily find the written rule for this, but this makes perfect sense to me, which is why I would prefer to get a new version number. Which is also why I always choose a new version number for a release vote after I had to cancel a vote. Regards Felix [1] http://markmail.org/message/533ybky6pqwwc2is Am Mittwoch, den 02.02.2011, 11:16 + schrieb Guillaume Nodet: Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[VOTE] Release maven-bundle-plugin 2.3.2
I would like to call another vote on the maven-bundle-plugin 2.3.2 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-027/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316061styleName=TextprojectId=12310100Create=Create 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 027 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release webconsole 3.1.8
+1 Regards Felix Am Dienstag, den 01.02.2011, 08:16 + schrieb Guillaume Nodet: This release fixes several issues * [FELIX-2713] - Problem in HtmlConfigurationWriter * [FELIX-2729] - Webconsole - Configuration fails to print configuration for bundles without MetatypeService config * [FELIX-2735] - ClassCastException in PermissionsConfigurationPrinter * [FELIX-2793] - Plugin request is not detected as html request if context path contains a dot * [FELIX-2795] - Parameters are not removed from symbolic name when installing a bundle The staging repo is available at: 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) This vote will be open for 72 hours.
Re: [VOTE] Release fileinstall-3.1.10
+1 Regards Felix Am Mittwoch, den 02.02.2011, 14:37 + schrieb Guillaume Nodet: Vote on fileinstall .3.1.10 This release fixes three issues https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316134styleName=TextprojectId=12310100Create=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.
Re: [VOTE] Release fileinstall-3.1.10
+1 Regards JB On 02/02/2011 03:37 PM, Guillaume Nodet wrote: Vote on fileinstall .3.1.10 This release fixes three issues https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316134styleName=TextprojectId=12310100Create=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.
Re: [DISCUSS] Re-trying releases
Hi, Am Mittwoch, den 02.02.2011, 14:42 + schrieb Richard S. Hall: I think originally we were more strict on changing the version number after failed votes, but we've since backed off. The reason for not being as strict, if I recall, is that people can still download the failed version while it's available with the signatures and put them up on some web site and call them official and people wouldn't know because the signatures are valid. So, what are we really gaining by changing the version number? The problem is exactly, that people may grab these packages under vote and put them up. We cancel the vote; rebuild the package with the same version number; succeed and publish. At this point in time we not only have an invalid package uploaded which can be identified as invalid (there is no tag for the failed release and there is no vote success). Rather we have two instances of a package with the same version number in the wild. One is invalid and one is official. But which is which ? I hope I did properly summarize the problem sketched by Roy. Regards Felix - richard On 2/2/11 9:01, Guillaume Nodet wrote: Last, remember each PMC decides on its own rules to govern its project. So the fact Roy sent an email on Jackrabbit doesn't make it an official policy for the ASF (and the ASF itself doesn't care about such technical details). I'll re-roll those releases, but I'd like things to be agreed upon *and* documented at some point. On Wed, Feb 2, 2011 at 14:59, Guillaume Nodetgno...@gmail.com wrote: On Wed, Feb 2, 2011 at 14:18, Felix Meschbergerfmesc...@adobe.com wrote: Hi, My vetoes (actually there is no veto in a release vote since this is a majority vote) I know there's no vetoes in releases, but the goal is usually to gather a consensus. The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) are grounded on a message Roy Fielding once sent to the Jackrabbit list [1]: The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). I suppose that depends on the definition of most. Over the dozen of projects I'm involved at the ASF, this is the first time I see that. Maybe for projects like httpd that was the case, but I don't expect many people that aren't felix committers to have downloaded those released in the last 48 hours, so I still stand by the fact that in our case, people are very aware that the jars aren't official yet. Anyway, if that's us becoming an official Felix project policy, I'd like that to be written somewhere. Oral tradition is not really good for newcomers ;-) Unfortunately I cannot readily find the written rule for this, but this makes perfect sense to me, which is why I would prefer to get a new version number. Which is also why I always choose a new version number for a release vote after I had to cancel a vote. Regards Felix [1] http://markmail.org/message/533ybky6pqwwc2is Am Mittwoch, den 02.02.2011, 11:16 + schrieb Guillaume Nodet: Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
I haven't fully looked at the release yet, but I was looking in my trunk build... The NOTICE file is for required notices for included software. It lists (besides Apache) OSGi and aQute. The DEPENDENCIES files says we include these too. But I don't see them in the generated JAR file. Are these left over from the old days when we did embed them? - richard On 2/2/11 4:41, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release maven-bundle-plugin 2.3.2
You're way too quick on your releases...I don't even get a chance to look... :-) On 2/2/11 9:39, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.2 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-027/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316061styleName=TextprojectId=12310100Create=Create 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 027 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [DISCUSS] Re-trying releases
I think since issue has been solved a while ago by mandating all artifacts have pgp / md5 signatures to identify if those are valid or not. That's the whole (and only afaik) point of those additional required files. On Wed, Feb 2, 2011 at 15:49, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Mittwoch, den 02.02.2011, 14:42 + schrieb Richard S. Hall: I think originally we were more strict on changing the version number after failed votes, but we've since backed off. The reason for not being as strict, if I recall, is that people can still download the failed version while it's available with the signatures and put them up on some web site and call them official and people wouldn't know because the signatures are valid. So, what are we really gaining by changing the version number? The problem is exactly, that people may grab these packages under vote and put them up. We cancel the vote; rebuild the package with the same version number; succeed and publish. At this point in time we not only have an invalid package uploaded which can be identified as invalid (there is no tag for the failed release and there is no vote success). Rather we have two instances of a package with the same version number in the wild. One is invalid and one is official. But which is which ? I hope I did properly summarize the problem sketched by Roy. Regards Felix - richard On 2/2/11 9:01, Guillaume Nodet wrote: Last, remember each PMC decides on its own rules to govern its project. So the fact Roy sent an email on Jackrabbit doesn't make it an official policy for the ASF (and the ASF itself doesn't care about such technical details). I'll re-roll those releases, but I'd like things to be agreed upon *and* documented at some point. On Wed, Feb 2, 2011 at 14:59, Guillaume Nodetgno...@gmail.com wrote: On Wed, Feb 2, 2011 at 14:18, Felix Meschbergerfmesc...@adobe.com wrote: Hi, My vetoes (actually there is no veto in a release vote since this is a majority vote) I know there's no vetoes in releases, but the goal is usually to gather a consensus. The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) are grounded on a message Roy Fielding once sent to the Jackrabbit list [1]: The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). I suppose that depends on the definition of most. Over the dozen of projects I'm involved at the ASF, this is the first time I see that. Maybe for projects like httpd that was the case, but I don't expect many people that aren't felix committers to have downloaded those released in the last 48 hours, so I still stand by the fact that in our case, people are very aware that the jars aren't official yet. Anyway, if that's us becoming an official Felix project policy, I'd like that to be written somewhere. Oral tradition is not really good for newcomers ;-) Unfortunately I cannot readily find the written rule for this, but this makes perfect sense to me, which is why I would prefer to get a new version number. Which is also why I always choose a new version number for a release vote after I had to cancel a vote. Regards Felix [1] http://markmail.org/message/533ybky6pqwwc2is Am Mittwoch, den 02.02.2011, 11:16 + schrieb Guillaume Nodet: Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- 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: [DISCUSS] Re-trying releases
On 2/2/11 9:49, Felix Meschberger wrote: Hi, Am Mittwoch, den 02.02.2011, 14:42 + schrieb Richard S. Hall: I think originally we were more strict on changing the version number after failed votes, but we've since backed off. The reason for not being as strict, if I recall, is that people can still download the failed version while it's available with the signatures and put them up on some web site and call them official and people wouldn't know because the signatures are valid. So, what are we really gaining by changing the version number? The problem is exactly, that people may grab these packages under vote and put them up. We cancel the vote; rebuild the package with the same version number; succeed and publish. At this point in time we not only have an invalid package uploaded which can be identified as invalid (there is no tag for the failed release and there is no vote success). Rather we have two instances of a package with the same version number in the wild. One is invalid and one is official. But which is which ? I understand that argument, but we don't completely eliminate the confusion, since there is still a failed version in the wild with valid signatures. So, unless someone comes and does an audit of our releases and finds out there isn't one (and understands what this means), then they won't know that their release with valid signatures isn't valid. In the end, I can care less either way. But lately we haven't been as strict about this. I am fine with not worrying about it, but if others want to worry about it we can do that too. - richard I hope I did properly summarize the problem sketched by Roy. Regards Felix - richard On 2/2/11 9:01, Guillaume Nodet wrote: Last, remember each PMC decides on its own rules to govern its project. So the fact Roy sent an email on Jackrabbit doesn't make it an official policy for the ASF (and the ASF itself doesn't care about such technical details). I'll re-roll those releases, but I'd like things to be agreed upon *and* documented at some point. On Wed, Feb 2, 2011 at 14:59, Guillaume Nodetgno...@gmail.com wrote: On Wed, Feb 2, 2011 at 14:18, Felix Meschbergerfmesc...@adobe.com wrote: Hi, My vetoes (actually there is no veto in a release vote since this is a majority vote) I know there's no vetoes in releases, but the goal is usually to gather a consensus. The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) are grounded on a message Roy Fielding once sent to the Jackrabbit list [1]: The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). I suppose that depends on the definition of most. Over the dozen of projects I'm involved at the ASF, this is the first time I see that. Maybe for projects like httpd that was the case, but I don't expect many people that aren't felix committers to have downloaded those released in the last 48 hours, so I still stand by the fact that in our case, people are very aware that the jars aren't official yet. Anyway, if that's us becoming an official Felix project policy, I'd like that to be written somewhere. Oral tradition is not really good for newcomers ;-) Unfortunately I cannot readily find the written rule for this, but this makes perfect sense to me, which is why I would prefer to get a new version number. Which is also why I always choose a new version number for a release vote after I had to cancel a vote. Regards Felix [1] http://markmail.org/message/533ybky6pqwwc2is Am Mittwoch, den 02.02.2011, 11:16 + schrieb Guillaume Nodet: Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Re-trying releases
They should not have valid signatures. Signatures are supposed to be always provided by the ASF infrastructure, else anybody can claim being a valid release. On Wed, Feb 2, 2011 at 16:00, Richard S. Hall he...@ungoverned.org wrote: On 2/2/11 9:49, Felix Meschberger wrote: Hi, Am Mittwoch, den 02.02.2011, 14:42 + schrieb Richard S. Hall: I think originally we were more strict on changing the version number after failed votes, but we've since backed off. The reason for not being as strict, if I recall, is that people can still download the failed version while it's available with the signatures and put them up on some web site and call them official and people wouldn't know because the signatures are valid. So, what are we really gaining by changing the version number? The problem is exactly, that people may grab these packages under vote and put them up. We cancel the vote; rebuild the package with the same version number; succeed and publish. At this point in time we not only have an invalid package uploaded which can be identified as invalid (there is no tag for the failed release and there is no vote success). Rather we have two instances of a package with the same version number in the wild. One is invalid and one is official. But which is which ? I understand that argument, but we don't completely eliminate the confusion, since there is still a failed version in the wild with valid signatures. So, unless someone comes and does an audit of our releases and finds out there isn't one (and understands what this means), then they won't know that their release with valid signatures isn't valid. In the end, I can care less either way. But lately we haven't been as strict about this. I am fine with not worrying about it, but if others want to worry about it we can do that too. - richard I hope I did properly summarize the problem sketched by Roy. Regards Felix - richard On 2/2/11 9:01, Guillaume Nodet wrote: Last, remember each PMC decides on its own rules to govern its project. So the fact Roy sent an email on Jackrabbit doesn't make it an official policy for the ASF (and the ASF itself doesn't care about such technical details). I'll re-roll those releases, but I'd like things to be agreed upon *and* documented at some point. On Wed, Feb 2, 2011 at 14:59, Guillaume Nodetgno...@gmail.com wrote: On Wed, Feb 2, 2011 at 14:18, Felix Meschbergerfmesc...@adobe.com wrote: Hi, My vetoes (actually there is no veto in a release vote since this is a majority vote) I know there's no vetoes in releases, but the goal is usually to gather a consensus. The fact you voted -1 puts a lot of pressure on me if I want to go to the majority in order to have those released ;-) are grounded on a message Roy Fielding once sent to the Jackrabbit list [1]: The problem with doing all of our laundry in public is that the public often download our unreleased packages even when we tell them not to. For that reason, most Apache projects increment the patch-level number each time a new package is produced (releases do not need to be sequential). I suppose that depends on the definition of most. Over the dozen of projects I'm involved at the ASF, this is the first time I see that. Maybe for projects like httpd that was the case, but I don't expect many people that aren't felix committers to have downloaded those released in the last 48 hours, so I still stand by the fact that in our case, people are very aware that the jars aren't official yet. Anyway, if that's us becoming an official Felix project policy, I'd like that to be written somewhere. Oral tradition is not really good for newcomers ;-) Unfortunately I cannot readily find the written rule for this, but this makes perfect sense to me, which is why I would prefer to get a new version number. Which is also why I always choose a new version number for a release vote after I had to cancel a vote. Regards Felix [1] http://markmail.org/message/533ybky6pqwwc2is Am Mittwoch, den 02.02.2011, 11:16 + schrieb Guillaume Nodet: Over the past two years, I've been doing several releases in Felix and i've re-rolled some with the same version without any problems. I don't see any mention about not reusing the same number twice in the release process: http://felix.apache.org/site/release-management-nexus.html What's the driver behing that ? Until those releases are published, poeple accessing those are fully aware of waht they are, so I don't see that as a problem. -- 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] Release maven-bundle-plugin 2.3.0 (2nd try)
I think they're left over from when we used to embed BND. I can't find any source file that doesn't seem to come from the ASF. Do you want me to recut a 2.3.4 ? On Wed, Feb 2, 2011 at 15:55, Richard S. Hall he...@ungoverned.org wrote: I haven't fully looked at the release yet, but I was looking in my trunk build... The NOTICE file is for required notices for included software. It lists (besides Apache) OSGi and aQute. The DEPENDENCIES files says we include these too. But I don't see them in the generated JAR file. Are these left over from the old days when we did embed them? - richard On 2/2/11 4:41, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release maven-bundle-plugin 2.3.0 (2nd try)
On 2/2/11 10:07, Guillaume Nodet wrote: I think they're left over from when we used to embed BND. I can't find any source file that doesn't seem to come from the ASF. Do you want me to recut a 2.3.4 ? Probably, since you are so good at it. :-) - richard On Wed, Feb 2, 2011 at 15:55, Richard S. Hallhe...@ungoverned.org wrote: I haven't fully looked at the release yet, but I was looking in my trunk build... The NOTICE file is for required notices for included software. It lists (besides Apache) OSGi and aQute. The DEPENDENCIES files says we include these too. But I don't see them in the generated JAR file. Are these left over from the old days when we did embed them? - richard On 2/2/11 4:41, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.0 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-025/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8d589633a054278ec7f36db6fcb02560518a1b8fversion=12316061styleName=TextprojectId=12310100Create=Create 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 025 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
EventAdmin
Hi All
I'm using an embedded instance of Felix, and trying to post a simple event to
the EventAdmin service. My code is trivial:
ServiceReference ref = context.getServiceReference(EventAdmin.class.getName());
if(ref != null) {
EventAdmin ea = (EventAdmin) context.getService(ref);
if(ea != null) {
ea.postEvent(evt);
}
}
The only unusual thing is that I'm calling this from outside the framework,
so I get my BundleContext object by calling:
BundleContext context = felix.getBundleContext();
When I run this, I get the following ClassCastException:
02-02 15:49:28.839: ERROR/SkiftaService(12471): java.lang.ClassCastException:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
Now, if this was a ClassLoader issue, I'd expect the
context.getServiceReference() to return null, but this isn't the case. Anyone
got aany idea why I'm getting this?
Thanks
Bruce
Re: EventAdmin
Its from my code: all of the other lines of the stack trace are in my code
and not the framework/event admin service.
On 02/02/2011 16:11, Karl Pauls karlpa...@gmail.com wrote:
Is this exception happening inside felix/eventadmin code or inside
your code? Could you maybe provide the stacktrace of the exception?
regards,
Karl
On Wed, Feb 2, 2011 at 5:04 PM, Jackson, Bruce bru...@qualcomm.com
wrote:
Hi All
I'm using an embedded instance of Felix, and trying to post a simple
event to the EventAdmin service. My code is trivial:
ServiceReference ref =
context.getServiceReference(EventAdmin.class.getName());
if(ref != null) {
EventAdmin ea = (EventAdmin) context.getService(ref);
if(ea != null) {
ea.postEvent(evt);
}
}
The only unusual thing is that I'm calling this from outside the
framework, so I get my BundleContext object by calling:
BundleContext context = felix.getBundleContext();
When I run this, I get the following ClassCastException:
02-02 15:49:28.839: ERROR/SkiftaService(12471):
java.lang.ClassCastException:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
Now, if this was a ClassLoader issue, I'd expect the
context.getServiceReference() to return null, but this isn't the case.
Anyone got aany idea why I'm getting this?
Thanks
Bruce
--
Karl Pauls
karlpa...@gmail.com
Re: EventAdmin
I've added the following code to see what I'm actually getting back from
the service lookup as below:
Object o = context.getService(ref);;
Class c = o.getClass();
while(c != null) {
System.err.println( ea service: + c.getName());
c = c.getSuperclass();
}
I get the following output:
02-02 16:27:43.049: WARN/System.err(12909): ea service:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
02-02 16:27:43.049: WARN/System.err(12909): ea service: java.lang.Object
So, something odd is certainly happening here.
On 02/02/2011 16:16, Jackson, Bruce bru...@qualcomm.com wrote:
Its from my code: all of the other lines of the stack trace are in my code
and not the framework/event admin service.
On 02/02/2011 16:11, Karl Pauls karlpa...@gmail.com wrote:
Is this exception happening inside felix/eventadmin code or inside
your code? Could you maybe provide the stacktrace of the exception?
regards,
Karl
On Wed, Feb 2, 2011 at 5:04 PM, Jackson, Bruce bru...@qualcomm.com
wrote:
Hi All
I'm using an embedded instance of Felix, and trying to post a simple
event to the EventAdmin service. My code is trivial:
ServiceReference ref =
context.getServiceReference(EventAdmin.class.getName());
if(ref != null) {
EventAdmin ea = (EventAdmin) context.getService(ref);
if(ea != null) {
ea.postEvent(evt);
}
}
The only unusual thing is that I'm calling this from outside the
framework, so I get my BundleContext object by calling:
BundleContext context = felix.getBundleContext();
When I run this, I get the following ClassCastException:
02-02 15:49:28.839: ERROR/SkiftaService(12471):
java.lang.ClassCastException:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
Now, if this was a ClassLoader issue, I'd expect the
context.getServiceReference() to return null, but this isn't the case.
Anyone got aany idea why I'm getting this?
Thanks
Bruce
--
Karl Pauls
karlpa...@gmail.com
Re: EventAdmin
Ok, but isn't it then just the case that you have the eventadmin
classes on the outside as well as on the inside of the framework? That
would explain the classcast exception as you are trying to assign the
eventadmin service from the inside of the framework to your variable
on the outside.
I guess you need to make sure you are delegating the eventadmin
package down to the bundles inside the framework (you can do that by
adding them to the system package exports). The framework can't
protect you in this case (by returning null for the service) as it
doesn't know what classes you have available on the outside of the
framework.
regards,
Karl
On Wed, Feb 2, 2011 at 5:16 PM, Jackson, Bruce bru...@qualcomm.com wrote:
Its from my code: all of the other lines of the stack trace are in my code
and not the framework/event admin service.
On 02/02/2011 16:11, Karl Pauls karlpa...@gmail.com wrote:
Is this exception happening inside felix/eventadmin code or inside
your code? Could you maybe provide the stacktrace of the exception?
regards,
Karl
On Wed, Feb 2, 2011 at 5:04 PM, Jackson, Bruce bru...@qualcomm.com
wrote:
Hi All
I'm using an embedded instance of Felix, and trying to post a simple
event to the EventAdmin service. My code is trivial:
ServiceReference ref =
context.getServiceReference(EventAdmin.class.getName());
if(ref != null) {
EventAdmin ea = (EventAdmin) context.getService(ref);
if(ea != null) {
ea.postEvent(evt);
}
}
The only unusual thing is that I'm calling this from outside the
framework, so I get my BundleContext object by calling:
BundleContext context = felix.getBundleContext();
When I run this, I get the following ClassCastException:
02-02 15:49:28.839: ERROR/SkiftaService(12471):
java.lang.ClassCastException:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
Now, if this was a ClassLoader issue, I'd expect the
context.getServiceReference() to return null, but this isn't the case.
Anyone got aany idea why I'm getting this?
Thanks
Bruce
--
Karl Pauls
karlpa...@gmail.com
--
Karl Pauls
karlpa...@gmail.com
[CANCEL] [VOTE] Release maven-bundle-plugin 2.3.2
I cancel this release to fix the NOTICE / DEPENDENCIES as we don't include bnd anymore. On Wed, Feb 2, 2011 at 15:39, Guillaume Nodet gno...@gmail.com wrote: I would like to call another vote on the maven-bundle-plugin 2.3.2 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-027/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?atl_token=8159ff149eb3d70fdca9490b559e5269f0ea79d8version=12316061styleName=TextprojectId=12310100Create=Create 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 027 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- 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
[jira] Commented: (FELIX-2692) Support maven type 'wab' for web bundles
[ https://issues.apache.org/jira/browse/FELIX-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12989711#comment-12989711 ] Alasdair Nottingham commented on FELIX-2692: Hi, I believe this has been fixed now. The aries project is using the latest version of the maven-bundle-plugin to create WABs. Support maven type 'wab' for web bundles Key: FELIX-2692 URL: https://issues.apache.org/jira/browse/FELIX-2692 Project: Felix Issue Type: New Feature Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.0.1 Reporter: Alex Blewitt Given the standardisation on WABs as part of the official specification, and that WARs currently don't have web data associated with them, would it make sense to support a new packaging type 'wab' for Maven projects that does the same as the WAR plugin, but adding metadata as well? It might need to determine the difference between 'compile' and 'provided' for inclusion in the 'WEB-INF/lib' subdirectory, so that the dependency information is recorded but not packaged into the WAR file. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Release maven-bundle-plugin 2.3.4
I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 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 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-2819) packageinfo files in src/main/java are ignored
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] Created: (FELIX-2820) Provide a default value when using _wab/
Provide a default value when using _wab/ -- Key: FELIX-2820 URL: https://issues.apache.org/jira/browse/FELIX-2820 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Reporter: Alasdair Nottingham Currently when building a WAB with the maven bundle plugin I have to specify the following: wabsrc/main/webapp/wab to get the web content pulled in. I would like the maven bundle plugin to default _wab/ to set src/main/webapp. Thanks Alasdair -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: EventAdmin
Hi,
This looks like a classic case of ClassCastException on a
class/interface that was loaded using two different class loaders. The
interface of EventAdmin that you are referencing was loaded using a
different class loader than the class loader that was used by the
framework.
Regards,
Lucas
On Wed, Feb 2, 2011 at 1:32 PM, Jackson, Bruce bru...@qualcomm.com wrote:
I've added the following code to see what I'm actually getting back from
the service lookup as below:
Object o = context.getService(ref);;
Class c = o.getClass();
while(c != null) {
System.err.println( ea service: + c.getName());
c = c.getSuperclass();
}
I get the following output:
02-02 16:27:43.049: WARN/System.err(12909): ea service:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
02-02 16:27:43.049: WARN/System.err(12909): ea service: java.lang.Object
So, something odd is certainly happening here.
On 02/02/2011 16:16, Jackson, Bruce bru...@qualcomm.com wrote:
Its from my code: all of the other lines of the stack trace are in my code
and not the framework/event admin service.
On 02/02/2011 16:11, Karl Pauls karlpa...@gmail.com wrote:
Is this exception happening inside felix/eventadmin code or inside
your code? Could you maybe provide the stacktrace of the exception?
regards,
Karl
On Wed, Feb 2, 2011 at 5:04 PM, Jackson, Bruce bru...@qualcomm.com
wrote:
Hi All
I'm using an embedded instance of Felix, and trying to post a simple
event to the EventAdmin service. My code is trivial:
ServiceReference ref =
context.getServiceReference(EventAdmin.class.getName());
if(ref != null) {
EventAdmin ea = (EventAdmin) context.getService(ref);
if(ea != null) {
ea.postEvent(evt);
}
}
The only unusual thing is that I'm calling this from outside the
framework, so I get my BundleContext object by calling:
BundleContext context = felix.getBundleContext();
When I run this, I get the following ClassCastException:
02-02 15:49:28.839: ERROR/SkiftaService(12471):
java.lang.ClassCastException:
org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator
Now, if this was a ClassLoader issue, I'd expect the
context.getServiceReference() to return null, but this isn't the case.
Anyone got aany idea why I'm getting this?
Thanks
Bruce
--
Karl Pauls
karlpa...@gmail.com
Re: [VOTE] Release maven-bundle-plugin 2.3.4
+1 Regards JB On 02/02/2011 06:09 PM, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 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 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release maven-bundle-plugin 2.3.4
+1 Thanks for the hard work on this release Guillaume. Regards, Alex On Wed, Feb 2, 2011 at 8:40 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: +1 Regards JB On 02/02/2011 06:09 PM, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 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 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments)
Re: [VOTE] Release maven-bundle-plugin 2.3.4
+1 Regards, Hiram FuseSource Web: http://fusesource.com/ On Wed, Feb 2, 2011 at 12:09 PM, Guillaume Nodet gno...@gmail.com wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 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 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release maven-bundle-plugin 2.3.4
+1 (non binding) Thanks Guillaume! On Wed, Feb 2, 2011 at 6:47 PM, Alex Karasulu akaras...@apache.org wrote: +1 Thanks for the hard work on this release Guillaume. Regards, Alex On Wed, Feb 2, 2011 at 8:40 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: +1 Regards JB On 02/02/2011 06:09 PM, Guillaume Nodet wrote: I would like to call another vote on the maven-bundle-plugin 2.3.4 release: Staging repositories: https://repository.apache.org/content/repositories/orgapachefelix-029/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12316061 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 029 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) -- *Toni Menzel - http://www.okidokiteam.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-tabpanelfocusedCommentId=12989749#comment-12989749 ] Simon Chemouil commented on FELIX-2819: --- This would be nice indeed. Just for the record (you might find it useful), we use the @Version bnd annotation on the package statement in the package-info.java file to achieve the same, and Maven is happy with this since it's a Java source file. E.g, @Version(1.0.2) package com.mycompany.myproject.mypackage import aQute.bnd.annotation; One thing nice with this is that it's possible to use a String constant defined in a Java class, for those times when we want to make the version a part of the Java API... And this usage finally makes package-info.java interesting for more than just package javadoc. Drawbacks are that we depend on bnd.annotation's JAR at compile time only for manifest generation, and that no tool that I know of updates these versions when the API evolves. Hope this helps. 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
NPE with felix framework 3.0.8
I just had this exception while testing with the latest 3.0.8 java.lang.NullPointerException at org.apache.felix.framework.resolver.ResolverImpl.permutateIfNeeded(ResolverImpl.java:1140)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1066)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:176)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4100)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)[org.apache.felix.framework-3.0.8.jar:] at java.lang.ClassLoader.loadClass(ClassLoader.java:248)[:1.6.0_22] at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1612)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)[org.apache.felix.framework-3.0.8.jar:] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.findCompatibleNamespaceHandler(NamespaceHandlerRegistryImpl.java:369)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.registerHandler(NamespaceHandlerRegistryImpl.java:325)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.registerHandler(NamespaceHandlerRegistryImpl.java:135)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:97)[10:org.apache.aries.blueprint:0.3.0] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)[karaf.jar:] at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)[karaf.jar:] at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)[karaf.jar:] at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)[karaf.jar:] at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.access$000(Felix.java:80)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.registerService(Felix.java:2854)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)[org.apache.felix.framework-3.0.8.jar:] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:404)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:184)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:662)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:330)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227)[10:org.apache.aries.blueprint:0.3.0] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_22] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_22] at
Re: NPE with felix framework 3.0.8
I don't think anything changed in that area for 3.0.8, but you could try it on 3.0.7 to see. If it is reproducible, then open a bug and tell me how and I'll look into it. - richard On 2/2/11 16:30, Guillaume Nodet wrote: I just had this exception while testing with the latest 3.0.8 java.lang.NullPointerException at org.apache.felix.framework.resolver.ResolverImpl.permutateIfNeeded(ResolverImpl.java:1140)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1066)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:176)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix$FelixResolver.resolve(Felix.java:4100)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1412)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)[org.apache.felix.framework-3.0.8.jar:] at java.lang.ClassLoader.loadClass(ClassLoader.java:248)[:1.6.0_22] at org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:645)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1612)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:904)[org.apache.felix.framework-3.0.8.jar:] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.findCompatibleNamespaceHandler(NamespaceHandlerRegistryImpl.java:369)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.registerHandler(NamespaceHandlerRegistryImpl.java:325)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.registerHandler(NamespaceHandlerRegistryImpl.java:135)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.addingService(NamespaceHandlerRegistryImpl.java:97)[10:org.apache.aries.blueprint:0.3.0] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)[karaf.jar:] at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)[karaf.jar:] at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233)[karaf.jar:] at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:840)[karaf.jar:] at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.access$000(Felix.java:80)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.Felix.registerService(Felix.java:2854)[org.apache.felix.framework-3.0.8.jar:] at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)[org.apache.felix.framework-3.0.8.jar:] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:404)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.ServiceRecipe.register(ServiceRecipe.java:184)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerServices(BlueprintContainerImpl.java:662)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:330)[10:org.apache.aries.blueprint:0.3.0] at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227)[10:org.apache.aries.blueprint:0.3.0] at
