[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)
[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] [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=revision&revision=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] [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=revision&revision=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-4811) Optimize ConfigurationManager#listConfigurations
[ https://issues.apache.org/jira/browse/FELIX-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-4811. Resolution: Fixed Fix Version/s: configadmin-1.8.2 Assignee: Guillaume Nodet Fixed with http://svn.apache.org/viewvc?view=revision&revision=1663369 > Optimize ConfigurationManager#listConfigurations > > > Key: FELIX-4811 > URL: https://issues.apache.org/jira/browse/FELIX-4811 > Project: Felix > Issue Type: Improvement > Components: Configuration Admin >Affects Versions: configadmin-1.8.0 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: configadmin-1.8.2 > > Attachments: yourkit.png > > > The ConfigurationManager#listConfigurations is far from optimal. > It iterates on all configurations, thereby creating a copy of the properties > for each configuration. Then, for each configuration, filter#match() is > called, which itself create a case insentive copy of the properties for > matching. > If you have quite a lot of configurations and quite a lof of SCR components, > it can be quite time consuming. > Attached is a YourKit profile view which shows that 90% of the time is spent > into copying properties for nothing. -- 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
[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:List="1.0,1.1,1.2", \ > osgi.ee; osgi.ee="JavaSE"; > version:List="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)
[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-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.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 "r", where 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-r
* Then a staging release is put in
https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r/
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-r
instead of
http://repository.apache.org/content/repositories
The usage of this command is:
{code}
sh check_staged_release.sh r /tmp/felix-staging
(replace r 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-r/org.apache.felix.dependencymanager-r-src.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-deps.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-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-r)
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-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.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 th
[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-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.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 "r", where 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-r
* Then a staging release is put in
https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r/
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-r
instead of
http://repository.apache.org/content/repositories
The usage of this command is:
{code}
sh check_staged_release.sh r /tmp/felix-staging
(replace r 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-r/org.apache.felix.dependencymanager-r-src.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-deps.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-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-r)
[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-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.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 "r", where is a positive integer number
starting at 1 and is incremented upon each
[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-rsrc.zip), a source binary dependencies
archive (org.apache.felix.dependencymanager-rdeps.zip) containing all
build-time binary dependencies, and a binary archive
(org.apache.felix.dependencymanager-rbin.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 "r", where 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-r
* Then a staging release is put in
https://dist.apache.org/repos/dist/dev/felix/org.apache.felix.dependencymanager-r/
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-r
instead of
http://repository.apache.org/content/repositories
The usage of this command is:
{code}
sh check_staged_release.sh r /tmp/felix-staging
(replace r 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-r/org.apache.felix.dependencymanager-r-src.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-deps.zip
**
https://dist.apache.org/repos/dist/release/felix/org.apache.felix.dependencymanager-r/org.apache.felix.dependencymanager-r-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-r)
[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)
Re: [VOTE] Release Apache Felix Http Jetty 3.0.2
> On 01 Mar 2015, at 15:24, Carsten Ziegeler 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-4817) Baseline plugin is not thread safe
Carsten Ziegeler created FELIX-4817: --- Summary: 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)
Re: [VOTE] Release Apache Felix Http Jetty 3.0.2
+1 David On 1 March 2015 at 14:24, Carsten Ziegeler 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
