Re: [VOTE] Release Apache Felix Http Jetty 3.0.2
+1 David On 1 March 2015 at 14:24, Carsten Ziegeler cziege...@apache.org wrote: Hi, We solved 2 issues in this release, the most important one is the update of Jetty to close the JetLeak vulnerability. https://issues.apache.org/jira/browse/FELIX/fixforversion/12329567 This release also includes a new parent pom required for the new version. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1052/ 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 1052 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for at least 72 hours. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Updated] (FELIX-4808) JDK 9 - default.property does not define eecap-1.9
[ https://issues.apache.org/jira/browse/FELIX-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arindam Bandyopadhyay updated FELIX-4808: - Issue Type: Improvement (was: Bug) JDK 9 - default.property does not define eecap-1.9 -- Key: FELIX-4808 URL: https://issues.apache.org/jira/browse/FELIX-4808 Project: Felix Issue Type: Improvement Components: Main Distribution Reporter: Arindam Bandyopadhyay Priority: Critical default.property under felix.jar does not define eecap-1.9 . default.property file under felix.jar should contain the following entry eecap-1.9= osgi.ee; osgi.ee=OSGi/Minimum; version:ListVersion=1.0,1.1,1.2, \ osgi.ee; osgi.ee=JavaSE; version:ListVersion=1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8,1.9 This entry is needed to resolve the Require-Capability osgi.ee if we run using JDK 9. Glassfish uses Felix as a osgi container . I tried to run glassfish using JDK 9. However glassfish could not start up as some of it's modules need to resolve Require-Capability osgi.ee . So if we need to run felix in JDK 9 we need to add eecap-1.9 in default.property file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Needing some help to release Dependency Manager
Hi everyone, This week I would like to try to make a difficult release for dependency manager. This release is unusual, because we are now building DM using Gradle and BndTools, but we are not using Maven anymore. So, because of that, we have to use a different release process, which is described in [1]. For this release, we have used the simplest form of release process, which is a basic Apache process (see [2]). So, for now, we are not using the Maven Nexus repository, and we don't release to Maven central, but we'll possibly try to do that later (by gradually improving our gradle release script). So, before attempting to do that release, I have few questions: 1) how is generted the Felix download page (see [3]) ? According to [1], we'll put the final released DM archives in the following Apache release repo locations: https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/org.apache.felix.dependencymanager-r1-src.zip https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/org.apache.felix.dependencymanager-r1-deps.zip https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/org.apache.felix.dependencymanager-r1-bin.zip (and all *.asc, *.sha, *.md5 signatures for each archives above) The -src.zip will contain the whole bndtools source workspace for DM; the -deps.zip will contain the build-time binaries being part of the bndtools source DM workspace, and the -bin.zip file will contain the DM binary bundles (for convenience). I guess that the Felix download page won't be able to display these three zip files ? Then how could I deal with this problem ? Is it possible to manually update the Felix download page, by just adding some links in the page (that will point to https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r1/ ?) 2) for this new release process, we are not using the nexus repository and we are not release to maven central (we'll try to do that in a later release). But is there is way to do this manually using the nexus web admin ?. I don't know if this is even possible since we are not using the nexus staging repo ? Any idea about how to do that manually ? 3) Then, is it possible to manually upload the released binary artifacts (from the -bin.zip) in the Felix OBR ? Many thanks for your help. cheers; /Pierre [1] https://issues.apache.org/jira/browse/FELIX-4818 [2] http://www.apache.org/dev/release.html [3] http://felix.apache.org/downloads.cgi
Re: [VOTE] Release Apache Felix Http Jetty 3.0.2
On 01 Mar 2015, at 15:24, Carsten Ziegeler cziege...@apache.org wrote: Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for at least 72 hours. Verified the signatures: +1. -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is revolving around INAETICS and Amdatu Luminis Technologies B.V. Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 signature.asc Description: Message signed with OpenPGP using GPGMail
[jira] [Resolved] (FELIX-4817) Baseline plugin is not thread safe
[ https://issues.apache.org/jira/browse/FELIX-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4817. - Resolution: Fixed Baseline plugin is not thread safe -- Key: FELIX-4817 URL: https://issues.apache.org/jira/browse/FELIX-4817 Project: Felix Issue Type: Bug Affects Versions: maven-bundle-plugin-2.5.3 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: maven-bundle-plugin-2.5.4 Although the baseline mojo is marked as a thread safe maven plugin, it's using instance variables to keep state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4818) New release process for Dependency Manager
Pierre De Rop created FELIX-4818: Summary: New release process for Dependency Manager Key: FELIX-4818 URL: https://issues.apache.org/jira/browse/FELIX-4818 Project: Felix Issue Type: Wish Components: Dependency Manager Reporter: Pierre De Rop Assignee: Pierre De Rop Fix For: org.apache.felix.dependencymanager-r1 The new Dependency Manager 4.0 is now built using gradle and bndtools (see FELIX-4816). But this has an impact on the release process because we are not using Maven anymore. So, this issue describes a new release process for DM, which is for now minimal: we don't use the nexus staging repository and we don't release to maven central (this is optional). But we'll try to refine and improve the release process gradually, in next DM releases. So, here is the new release process description: * it is based mostly on the basic Apache release process (see [1]), and is also inspired from the Apache Ace release process (see [2]), and the Amdatu release process (see [3]) which are also using bndtools. * the DM4 release will be in the form of three archives: a source based archive (org.apache.felix.dependencymanager-rnsrc.zip), a source binary dependencies archive (org.apache.felix.dependencymanager-rndeps.zip) containing all build-time binary dependencies, and a binary archive (org.apache.felix.dependencymanager-rnbin.zip) containing all DM bundles for convenience. * Each released artifacts (-src, -deps, -bin) has the same unique release version number, regardless of the outcome of the vote. This implies that release version used for releases are not to be reused. By convention, a release version is defined as rN, where N is a positive integer number starting at 1 and is incremented upon each release. * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum files are provided for all archives. * Before making a release, the dependency manager source will be tagged to https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-rn * Then a staging release is put in https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn/ directory which will contain the three -src.zip, -deps.zip and -bin.zip archives. * Then a vote starts, and vote participants must then use a custom check_staged_release.sh (see [4]). This script, unlike the original Felix check_stage_release.sh, will download staging from https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn instead of http://repository.apache.org/content/repositories The usage of this command is: {code} sh check_staged_release.sh rn /tmp/felix-staging (replace rn by the actual staging release reversion, like r1) {code} * Then if the vote has passed, the staging release is promoted and moved to: ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-src.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-deps.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-bin.zip * Else, of the vote has failed, the staging release is simply deleted from the staging area (https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn) [1] http://www.apache.org/dev/release.html [2] https://ace.apache.org/docs/release-guide.html [3] https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure [4] http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4818) New release process for Dependency Manager
[ https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-4818: - Description: The new Dependency Manager 4.0 is now built using gradle and bndtools (see FELIX-4816). But this has an impact on the release process because we are not using Maven anymore. So, this issue describes a new release process for DM, which is for now minimal: we don't use the nexus staging repository and we don't release to maven central (this is optional). But we'll try to refine and improve the release process gradually, in next DM releases. So, here is the new release process description: * it is based mostly on the basic Apache release process (see [1]), and is also inspired from the Apache Ace release process (see [2]), and the Amdatu release process (see [3]) which are also using bndtools. * the DM4 release will be in the form of three archives: a source based archive (org.apache.felix.dependencymanager-rnsrc.zip), a source binary dependencies archive (org.apache.felix.dependencymanager-rndeps.zip) containing all build-time binary dependencies, and a binary archive (org.apache.felix.dependencymanager-rnbin.zip) containing all DM bundles for convenience. * Each released artifacts (-src, -deps, -bin) has the same unique release version number, regardless of the outcome of the vote. This implies that release version used for releases are not to be reused. By convention, a release version is defined as rN, where N is a positive integer number starting at 1 and is incremented upon each release. * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum files are provided for all archives. * Before making a release, the dependency manager source will be tagged to https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-rn * Then a staging release is put in https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn/ directory which will contain the three -src.zip, -deps.zip and -bin.zip archives. * Then a vote starts, and vote participants must then use a custom check_staged_release.sh (see [4]). This script, unlike the original Felix check_stage_release.sh, will download staging from https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn instead of http://repository.apache.org/content/repositories The usage of this command is: {code} sh check_staged_release.sh rn /tmp/felix-staging (replace rn by the actual staging release reversion, like r1) {code} * Then if the vote has passed, the staging release is promoted and moved to: ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-src.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-deps.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-bin.zip * Else, if the vote has failed, the staging release is simply deleted from the staging area (https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn) More informations can be found in [5] concerning how to use the gradle script, when making a release. [1] http://www.apache.org/dev/release.html [2] https://ace.apache.org/docs/release-guide.html [3] https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure [4] http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh [5] http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/README.release was: The new Dependency Manager 4.0 is now built using gradle and bndtools (see FELIX-4816). But this has an impact on the release process because we are not using Maven anymore. So, this issue describes a new release process for DM, which is for now minimal: we don't use the nexus staging repository and we don't release to maven central (this is optional). But we'll try to refine and improve the release process gradually, in next DM releases. So, here is the new release process description: * it is based mostly on the basic Apache release process (see [1]), and is also inspired from the Apache Ace release process (see [2]), and the Amdatu release process (see [3]) which are also using bndtools. * the DM4 release will be in the form of three archives: a source based archive (org.apache.felix.dependencymanager-rnsrc.zip), a source binary dependencies archive (org.apache.felix.dependencymanager-rndeps.zip) containing all build-time binary dependencies, and a binary archive (org.apache.felix.dependencymanager-rnbin.zip) containing all DM bundles for convenience. * Each released artifacts (-src, -deps, -bin) has the same unique release version number, regardless of the outcome of the
[jira] [Updated] (FELIX-4818) New release process for Dependency Manager
[ https://issues.apache.org/jira/browse/FELIX-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-4818: - Description: The new Dependency Manager 4.0 is now built using gradle and bndtools (see FELIX-4816). But this has an impact on the release process because we are not using Maven anymore. So, this issue describes a new release process for DM, which is for now minimal: we don't use the nexus staging repository and we don't release to maven central (this is optional). But we'll try to refine and improve the release process gradually, in next DM releases. So, here is the new release process description: * it is based mostly on the basic Apache release process (see [1]), and is also inspired from the Apache Ace release process (see [2]), and the Amdatu release process (see [3]) which are also using bndtools. * the DM4 release will be in the form of three archives: a source based archive (org.apache.felix.dependencymanager-rnsrc.zip), a source binary dependencies archive (org.apache.felix.dependencymanager-rndeps.zip) containing all build-time binary dependencies, and a binary archive (org.apache.felix.dependencymanager-rnbin.zip) containing all DM bundles for convenience. * Each released artifacts (-src, -deps, -bin) has the same unique release version number, regardless of the outcome of the vote. This implies that release version used for releases are not to be reused. By convention, a release version is defined as rN, where N is a positive integer number starting at 1 and is incremented upon each release. * To verify the integrity of archives, .asc, .md5, and .sha (512) checksum files are provided for all archives. * Before making a release, the dependency manager source will be tagged to https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.dependencymanager-rn * Then a staging release is put in https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn/ directory which will contain the three -src.zip, -deps.zip and -bin.zip archives. * Then a vote starts, and vote participants must then use a custom check_staged_release.sh (see [4]). This script, unlike the original Felix check_stage_release.sh, will download staging from https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn instead of http://repository.apache.org/content/repositories The usage of this command is: {code} sh check_staged_release.sh rn /tmp/felix-staging (replace rn by the actual staging release reversion, like r1) {code} * Then if the vote has passed, the staging release is promoted and moved to: ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-src.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-deps.zip ** https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-rn/org.apache.felix.dependencymanager-rn-bin.zip * Else, if the vote has failed, the staging release is simply deleted from the staging area (https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-rn) [1] http://www.apache.org/dev/release.html [2] https://ace.apache.org/docs/release-guide.html [3] https://amdatu.atlassian.net/wiki/display/AMDATUDEV/Amdatu+Release+Procedure [4] http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh was: The new Dependency Manager 4.0 is now built using gradle and bndtools (see FELIX-4816). But this has an impact on the release process because we are not using Maven anymore. So, this issue describes a new release process for DM, which is for now minimal: we don't use the nexus staging repository and we don't release to maven central (this is optional). But we'll try to refine and improve the release process gradually, in next DM releases. So, here is the new release process description: * it is based mostly on the basic Apache release process (see [1]), and is also inspired from the Apache Ace release process (see [2]), and the Amdatu release process (see [3]) which are also using bndtools. * the DM4 release will be in the form of three archives: a source based archive (org.apache.felix.dependencymanager-rnsrc.zip), a source binary dependencies archive (org.apache.felix.dependencymanager-rndeps.zip) containing all build-time binary dependencies, and a binary archive (org.apache.felix.dependencymanager-rnbin.zip) containing all DM bundles for convenience. * Each released artifacts (-src, -deps, -bin) has the same unique release version number, regardless of the outcome of the vote. This implies that release version used for releases are not to be reused. By convention, a release version is defined as rN, where N is a positive integer number starting at 1 and is
[jira] [Resolved] (FELIX-4810) Cache WeakZipFile#entries
[ https://issues.apache.org/jira/browse/FELIX-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-4810. Resolution: Fixed Fixed with http://svn.apache.org/viewvc?view=revisionrevision=1663368 Cache WeakZipFile#entries - Key: FELIX-4810 URL: https://issues.apache.org/jira/browse/FELIX-4810 Project: Felix Issue Type: Improvement Components: Framework Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: framework-4.6.1 Attachments: FELIX-4810.patch The WeakZipFile#entries() method is used in several places when there's a need to iterate through bundle resources. That can happen quite a lot of times if there are multiple extenders. Caching this value would allow: * avoid scanning all bundles multiple times, especially when they are resolved / started * given it mostly happen when the bundle is resolved or started, using a SoftReference makes sense to not consume memory while still providing a good caching behaviour -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4812) BundleRepository can be quite CPU intensive when starting a lot of bundles
[ https://issues.apache.org/jira/browse/FELIX-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-4812. Resolution: Fixed Fixed with http://svn.apache.org/viewvc?view=revisionrevision=1663370 BundleRepository can be quite CPU intensive when starting a lot of bundles -- Key: FELIX-4812 URL: https://issues.apache.org/jira/browse/FELIX-4812 Project: Felix Issue Type: Improvement Components: Bundle Repository (OBR) Affects Versions: bundlerepository-2.0.2 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: bundlerepository-2.0.4 The reason is that each time a bundle is modified or a service registered, the whole resource is recreated. When OBR local repository is not really used, it can be quite costly. A good approach would be to use lazy resources instead of computing the resource upfront, so that the requirements and capabilities are only computed when the resource is actually used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4819) Use Set instead of List for cycle detection
[ https://issues.apache.org/jira/browse/FELIX-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Marschall updated FELIX-4819: -- Attachment: ResolverImpl.java.patch Patch that fixes the issue. The patch replaces the following pattern: {code} if (set.contains(object)) { return; } set.add(object); {code} with this one: {code} if (!set.add(object)) { return; } {code} in order to minimize the hash lookups. Use Set instead of List for cycle detection --- Key: FELIX-4819 URL: https://issues.apache.org/jira/browse/FELIX-4819 Project: Felix Issue Type: Improvement Components: Resolver Reporter: Philippe Marschall Attachments: ResolverImpl.java.patch We did some profiling of the Felix resolver in our application and 16% were spent in {{ArrayList#indexOf}} called by ArrayList#contains}}. It seems that {{ResolverImpl}} uses {{java.util.ArrayList}} for data structures on which it only calls {{#add}} and {{#contains}} with the latter being O(n). A {{java.util.HashSet}} is the appropriate data structure for such this use case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4819) Use Set instead of List for cycle detection
Philippe Marschall created FELIX-4819: - Summary: Use Set instead of List for cycle detection Key: FELIX-4819 URL: https://issues.apache.org/jira/browse/FELIX-4819 Project: Felix Issue Type: Improvement Components: Resolver Reporter: Philippe Marschall We did some profiling of the Felix resolver in our application and 16% were spent in {{ArrayList#indexOf}} called by ArrayList#contains}}. It seems that {{ResolverImpl}} uses {{java.util.ArrayList}} for data structures on which it only calls {{#add}} and {{#contains}} with the latter being O(n). A {{java.util.HashSet}} is the appropriate data structure for such this use case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4819) Use Set instead of List for cycle detection
[ https://issues.apache.org/jira/browse/FELIX-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Marschall updated FELIX-4819: -- Labels: patch (was: ) Use Set instead of List for cycle detection --- Key: FELIX-4819 URL: https://issues.apache.org/jira/browse/FELIX-4819 Project: Felix Issue Type: Improvement Components: Resolver Reporter: Philippe Marschall Labels: patch Attachments: ResolverImpl.java.patch We did some profiling of the Felix resolver in our application and 16% were spent in {{ArrayList#indexOf}} called by ArrayList#contains}}. It seems that {{ResolverImpl}} uses {{java.util.ArrayList}} for data structures on which it only calls {{#add}} and {{#contains}} with the latter being O(n). A {{java.util.HashSet}} is the appropriate data structure for such this use case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)