[jira] [Updated] (FELIX-5647) Errors in pom makes maven project builder bail out
[ https://issues.apache.org/jira/browse/FELIX-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-5647: - Attachment: test.assembly.with.dm.tgz Attached the assembly sample project; Please try to modify it with the issue you reported and I will then take a look at it. many thanks. > Errors in pom makes maven project builder bail out > -- > > Key: FELIX-5647 > URL: https://issues.apache.org/jira/browse/FELIX-5647 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-4.3.0 > Environment: Windows 10 >Reporter: Mario Toffia >Assignee: Pierre De Rop >Priority: Minor > Attachments: test.assembly.with.dm.tgz > > > (Could not find: "dependencymanager-4.4.0" of which is the version that I'm > really using - as the affects versions) > Description: > The pom file has packaging `bundle` but it does not include a `plugin` > section with _maven-bundle-plugin_. This makes the maven project builder to > bail out since it cannot find anything keyed to `bundle`. > All other felix projects works ok since they do declare 'maven-bundle-plugin > section in the build->plugin section. This makes plexus to resolve such. > I'm using this in a custom assembly plugin for my framework to resolve > artifacts etc using the maven project builder to perorm those tasks. > The only thing needed, i think, is to insert the following in the pom file: > ``` > > > > org.apache.felix > maven-bundle-plugin > 2.3.7 > true > > > > ``` > Cheers, > Mario -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5647) Errors in pom makes maven project builder bail out
[ https://issues.apache.org/jira/browse/FELIX-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071361#comment-16071361 ] Pierre De Rop commented on FELIX-5647: -- Hi Mario, I just published the dependencymanager r11 artifacts to maven central. So, as said, i'm using bndtools which generates poms inside dm artifacts, and I'm using them to publish to maven, and bndtools does not generate the poms with package=bundle. Since I'm not sure I fully understand the problem, I have attached to this issue a simple test maven project with an assembly. The test project contains a simple Activator and an assembly which simply contains the test target bundle, as well as dependencymanager artifacts. So, can you please take a look at it, and modify it with your issue in order to let me reproduce the issue myself ? thanks. > Errors in pom makes maven project builder bail out > -- > > Key: FELIX-5647 > URL: https://issues.apache.org/jira/browse/FELIX-5647 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: dependencymanager-4.3.0 > Environment: Windows 10 >Reporter: Mario Toffia >Assignee: Pierre De Rop >Priority: Minor > > (Could not find: "dependencymanager-4.4.0" of which is the version that I'm > really using - as the affects versions) > Description: > The pom file has packaging `bundle` but it does not include a `plugin` > section with _maven-bundle-plugin_. This makes the maven project builder to > bail out since it cannot find anything keyed to `bundle`. > All other felix projects works ok since they do declare 'maven-bundle-plugin > section in the build->plugin section. This makes plexus to resolve such. > I'm using this in a custom assembly plugin for my framework to resolve > artifacts etc using the maven project builder to perorm those tasks. > The only thing needed, i think, is to insert the following in the pom file: > ``` > > > > org.apache.felix > maven-bundle-plugin > 2.3.7 > true > > > > ``` > Cheers, > Mario -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5653) Simplify DM-Lambda samples
[ https://issues.apache.org/jira/browse/FELIX-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5653. > Simplify DM-Lambda samples > -- > > Key: FELIX-5653 > URL: https://issues.apache.org/jira/browse/FELIX-5653 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager Samples >Affects Versions: org.apache.felix.dependencymanager-r8 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Trivial > Fix For: org.apache.felix.dependencymanager-r11 > > > Some minor cleanup should be done in dm-lambda samples: the > src/org/apache/felix/dm/lambda/samples/hello sample is too complex, it should > be simplified with only a simple service provider and service consumer, and a > few typos need to be fixed in other samples. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5650) Support latest version of Gogo
[ https://issues.apache.org/jira/browse/FELIX-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5650. > Support latest version of Gogo > -- > > Key: FELIX-5650 > URL: https://issues.apache.org/jira/browse/FELIX-5650 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager Shell >Reporter: Sean Rohead >Assignee: Pierre De Rop > Fix For: org.apache.felix.dependencymanager-r11 > > > Dependency Manager Shell should work with Gogo 1.0 and greater. The current > version of Dependency Manager Shell has the following package import which > fails with the current version (1.0.6) of Gogo Shell: > org.apache.felix.service.command;version="[0.10,1)";status=provisional -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5657) DM released sources can't be rebuilt
[ https://issues.apache.org/jira/browse/FELIX-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5657. > DM released sources can't be rebuilt > > > Key: FELIX-5657 > URL: https://issues.apache.org/jira/browse/FELIX-5657 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: org.apache.felix.dependencymanager-r9 >Reporter: Pierre De Rop >Assignee: Pierre De Rop >Priority: Critical > Fix For: org.apache.felix.dependencymanager-r11 > > > since FELIX-5228, dm has been updated with bndlib 3.3.0. but at this point a > refactoring has been made and junit/hamcrest jars were moved from > cnf/buildrepo to cnf/non-osgirepo. > the problem is: the release/build.gradle script has not been updated in order > to include the cnf/non-osgirepo in the dm-deps zip, leading to a fatal > compile error. > notice that using latest bndtools, it could be possible to manage to avoid > using a dm-deps zip, because we'll do this later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5619) MultiProperyFilterIndex memory consumption
[ https://issues.apache.org/jira/browse/FELIX-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5619. > MultiProperyFilterIndex memory consumption > -- > > Key: FELIX-5619 > URL: https://issues.apache.org/jira/browse/FELIX-5619 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Affects Versions: org.apache.felix.dependencymanager-r9 >Reporter: Jeroen Daanen >Assignee: Pierre De Rop > Fix For: org.apache.felix.dependencymanager-r11 > > Attachments: Filter.java, MultiPropertyFilterIndex.java, > MultiPropertyFilterIndexPerformanceTest.java, > MultiPropertyFilterIndexReferencedTest.java, MultiPropertyKey.java, > MultiPropertyKeyTest.java, TestReference.java > > > In our product using the dependency manager and having configured several > filter index settings, the memory consumption of the MultiPropertyFilterIndex > is relatively high because it contains a map of string keys to service > reference, where the keys are concatenated strings based on the service > properties. These strings are all newly created objects resulting in > inefficient memory usage. > In the attachment you find a version of the index which uses less memory > because it no longer stores appended strings in new string objects, but > stores the original strings in string arrays. This way it can benefit for > instance from the garbage collector deduplicating strings. > Also attached are some unit tests to ensure the behavior did not change (note > that we could not find any existing unit tests on the > MultiPropertyFilterIndex). > If a large project is configured in our product we could have around 41500 > services total. The configured MultiproperyFilterIndexes then contain more > then 50 keys. > When executing the attached unit test > 'MultiPropertyFilterIndexPerformanceTest' for 50 service references we > found the memory consumption is reduced by 44%: > Existing implemenation: > fastest write time: 3.433 milliseconds > fastest read time: 1.577 milliseconds > memory consumption: 1374 MB > New implementation: > fastest write time: 2.329 milliseconds > fastest read time: 1.997 milliseconds > memory consumption: 771 MB > Would it be either possible to replace the existing implementation or make it > possible to supply a custom implementation of a filter index to the > dependency manager? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5623) Improve performance of ComponentImpl.getName method
[ https://issues.apache.org/jira/browse/FELIX-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5623. > Improve performance of ComponentImpl.getName method > --- > > Key: FELIX-5623 > URL: https://issues.apache.org/jira/browse/FELIX-5623 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Raluca Grigoras >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r11 > > Attachments: FELIX-5632.patch > > > We are using the dependency manager diagnostics API (the dependency graph) in > our application to display all components (registered and unregistered) in > the application UI (similar to the 'dm' shell command). We ran into a > performance problem (requesting the whole dependency graph takes very long), > and after profiling I found out that the ComponentImpl.getName method is the > reason. The component name is generated each time the method is called, > making the dependency graph generation slow. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5636) Component of aspect service does not have any service properties anymore
[
https://issues.apache.org/jira/browse/FELIX-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5636.
Assignee: Pierre De Rop
> Component of aspect service does not have any service properties anymore
>
>
> Key: FELIX-5636
> URL: https://issues.apache.org/jira/browse/FELIX-5636
> Project: Felix
> Issue Type: Bug
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9,
> org.apache.felix.dependencymanager-r10
>Reporter: Jeroen Daanen
>Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r11
>
>
> The Component for an aspect service does not have service properties. It
> looks like this is broken since r.1781908 (had a quick look, but could not
> find the cause in the time I had available).
> Without these properties it is not possible to add a dependency in the init
> method of the aspect based on one of the aspected service properties.
> Example to test it:
> {code}
> public class Activator extends DependencyActivatorBase {
> @Override
> public void init(BundleContext context, DependencyManager manager)
> throws Exception {
> Properties properties = new Properties();
> properties.put("PropKey", "PropValue");
> Component aComponent =
> manager.createComponent().setInterface(X.class.getName(),
> properties).setImplementation(new A());
> manager.add(aComponent);
>
> manager.add(manager.createAspectService(X.class, null,
> 100).setImplementation(B.class));
> }
> public static class A implements X {
> public void init(Component component) {
> System.out.println("Service properties in A: " +
> component.getServiceProperties());
> }
> }
> public static class B implements X {
> public void init(Component component) {
> System.out.println("Service properties in B: " +
> component.getServiceProperties());
> }
> }
> public interface X {
> }
> }
> {code}
> The init of B shows empty properties, I expected the inherited properties,
> aspect ranking etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (FELIX-5630) NullObject is created for a required dependency if the component is removed and added again to the dependency manager
[ https://issues.apache.org/jira/browse/FELIX-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop closed FELIX-5630. > NullObject is created for a required dependency if the component is removed > and added again to the dependency manager > - > > Key: FELIX-5630 > URL: https://issues.apache.org/jira/browse/FELIX-5630 > Project: Felix > Issue Type: Bug > Components: Dependency Manager >Affects Versions: org.apache.felix.dependencymanager-r1 >Reporter: Jeroen Daanen >Assignee: Pierre De Rop >Priority: Minor > Fix For: org.apache.felix.dependencymanager-r11 > > Attachments: Activator.java > > > I have a component A with a required dependency to B and C. > I add A, B and C to the dependency manager. > Then I remove A and B. > Finally I only add A again. Now the exception "Could not create null object > for class com.example.Activator$B is thrown". See the attached Activator. > I did not expect that a NullObject is ever created for a required dependency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (FELIX-5658) Include poms in dm artifacts
[
https://issues.apache.org/jira/browse/FELIX-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop closed FELIX-5658.
> Include poms in dm artifacts
>
>
> Key: FELIX-5658
> URL: https://issues.apache.org/jira/browse/FELIX-5658
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Trivial
> Fix For: org.apache.felix.dependencymanager-r11
>
>
> In some cases, when someone puts dm artifacts in a local nexus repository,
> then sometimes having the poms inside the dm artifacts is useful.
> To include the poms, simply add this in cnf/build.bnd:
> {code}
> # Generates poms in artifacts.
> -pom: groupid = org.apache.felix
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (FELIX-5658) Include poms in dm artifacts
[
https://issues.apache.org/jira/browse/FELIX-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-5658:
-
Description:
In some cases, when someone puts dm artifacts in a local nexus repository, then
sometimes having the poms inside the dm artifacts is useful.
To include the poms, simply add this in cnf/build.bnd:
{code}
# Generates poms in artifacts.
-pom: groupid = org.apache.felix
{code}
was:
In some cases, when someone puts dm artifacts in a local nexus repository, then
sometimes having the poms inside the dm artifacts is useful.
To include the poms, simply add this in cnf/build.bnd:
# Generates poms in artifacts.
-pom: groupid = org.apache.felix
> Include poms in dm artifacts
>
>
> Key: FELIX-5658
> URL: https://issues.apache.org/jira/browse/FELIX-5658
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Trivial
> Fix For: org.apache.felix.dependencymanager-r11
>
>
> In some cases, when someone puts dm artifacts in a local nexus repository,
> then sometimes having the poms inside the dm artifacts is useful.
> To include the poms, simply add this in cnf/build.bnd:
> {code}
> # Generates poms in artifacts.
> -pom: groupid = org.apache.felix
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[RESULT] [VOTE] Apache Felix Dependency Manager Release R11
Hi, The vote has passed with the following result : +1 (binding): David Bosschaert, Clement Escoffier, Jean-Batiste Onofré, Jan Willem Janssen, Pierre De Rop +1 (non binding): Francois Leygues, Juan Manuel Calderon, Cédric Dos Santos, Thanks a lot for your votes; I will copy this release to the Felix dist directory and promote the artifacts to the central Maven repository. regards Pierre
Re: [VOTE] Apache Felix Dependency Manager Release R11
+1 (binding) from my side. (many thanks for your votes) regards Pierre On Sat, Jul 1, 2017 at 6:19 PM, Pierre De Rop wrote: > Thanks Jan Willem for the feedbacks; > > - For the index.html.tmp file, can you please open a jira issue and > indicate in it which option you used to ignore the tmp file ? (I guess it's > "--reject=html,txt,tmp" ?); > and it's odd because I don't see any tmp files from > https://dist.apache.org/repos/dist/dev/felix/org.apache > .felix.dependencymanager-r11/ ?; > > - for the gogo shell, you indeed need to update to the latest gogo > version, because the version for the org.apache.felix.gogo.runtime bundle > has been bumped, and the dm shell depends on it. > As said in FELIX-5650, I could not manage to stay compatible with previous > gogo versions, and if it required to use the previous (non-jline) gogo > version, then in this case please use the dm shell from previous DM-R9 > version. > > - for FELIX-5660 where you need to build the annotations before other > bundles, it's an old issue, I will ask on bndtools mailing list if there is > a solution for this problem, and it is currently indicated in > https://svn.apache.org/repos/asf/felix/trunk/dependencyma > nager/release/resources/src/README.src that you indeed need to first > build the annotation jar before building all other bundles. > > thanks & regards > Pierre > > > > On Thu, Jun 29, 2017 at 11:08 AM, Jan Willem Janssen < > janwillem.jans...@luminis.eu> wrote: > >> Hi, >> >> > On 27 Jun 2017, at 09:17, Pierre De Rop wrote: >> > >> > Hello all, >> > >> > After a failed attempt to release the DM-R10 release, I would like to >> call >> > for a new vote on the Dependency Manager toplevel release R11. >> > >> > The following issues were solved: >> > >> > ** Bug >> >* [FELIX-5630] - NullObject is created for a required dependency if >> the >> > component is removed and added again to the dependency manager >> >* [FELIX-5636] - Component of aspect service does not have any >> service >> > properties anymore >> >* [FELIX-5657] - DM released sources can't be rebuilt >> > >> > ** Improvement >> >* [FELIX-5619] - MultiProperyFilterIndex memory consumption >> >* [FELIX-5623] - Improve performance of ComponentImpl.getName method >> >* [FELIX-5650] - Support latest version of Gogo >> >* [FELIX-5653] - Simplify DM-Lambda samples >> >* [FELIX-5658] - Include poms in dm artifacts >> > >> > You can use this UNIX script to download the release and verify the >> > signatures: >> > >> > >> > http://svn.apache.org/repos/asf/felix/trunk/dependencymanage >> r/release/check_staged_release.sh >> > >> > Usage: >> > >> >sh check_staged_release.sh r11 /tmp/felix-staging >> > >> > This script, unlike the original Felix check_stage_release.sh, is >> specific >> > to the new Dependency Manager release process (see FELIX-4818) and will >> > download staging from https://dist.apache.org/repos/dist/dev/felix >> instead >> > of http://repository.apache.org/content/repositories. >> > >> > To rebuild the DM binaries from the source, you can then refer to >> > https://svn.apache.org/repos/asf/felix/trunk/dependencymanag >> er/release/resources/src/README.src >> > >> > >> > Please vote to approve this release: >> > >> > [ ] +1 Approve the release >> > [ ] -1 Veto the release (please provide specific comments) >> >> The verification of the signatures had a small hiccup: there’s a >> `index.html.tmp` file >> present in the staging directory which breaks the signature check. >> Updating the script >> to also exclude `.tmp` files causes the verification to be successful. >> >> Did try the new DM bundles in a local project, which works, apart from >> the shell: you >> need to upgrade to the latest Gogo shell in order to make use of it. Not >> sure why this >> is needed yet. >> >> Building the release from sources is successful on the 2nd run after a >> clean: the first >> time, the build fails with the exception that the annotation processor >> cannot be found. >> The build is successful after re-running the build again. >> I’ve created FELIX-5660 for that. >> >> No showstoppers for me, so +1 on the release. >> >> -- >> Met vriendelijke groeten | Kind regards >> >> Jan Willem Janssen | Software Architect >> +31 631 765 814 >> >> >> My world is something with Amdatu and Apache >> >> Luminis Technologies >> John F. Kennedylaan 32 >> 7314 PS Apeldoorn >> +31 88 586 46 25 >> >> https://www.luminis.eu >> >> KvK (CoC) 09 16 28 93 >> BTW (VAT) NL8170.94.441.B.01 >> >> >
Re: [VOTE] Apache Felix Dependency Manager Release R11
Thanks Jan Willem for the feedbacks; - For the index.html.tmp file, can you please open a jira issue and indicate in it which option you used to ignore the tmp file ? (I guess it's "--reject=html,txt,tmp" ?); and it's odd because I don't see any tmp files from https://dist.apache.org/ repos/dist/dev/felix/org.apache.felix.dependencymanager-r11/ ?; - for the gogo shell, you indeed need to update to the latest gogo version, because the version for the org.apache.felix.gogo.runtime bundle has been bumped, and the dm shell depends on it. As said in FELIX-5650, I could not manage to stay compatible with previous gogo versions, and if it required to use the previous (non-jline) gogo version, then in this case please use the dm shell from previous DM-R9 version. - for FELIX-5660 where you need to build the annotations before other bundles, it's an old issue, I will ask on bndtools mailing list if there is a solution for this problem, and it is currently indicated in https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/ resources/src/README.src that you indeed need to first build the annotation jar before building all other bundles. thanks & regards Pierre On Thu, Jun 29, 2017 at 11:08 AM, Jan Willem Janssen < janwillem.jans...@luminis.eu> wrote: > Hi, > > > On 27 Jun 2017, at 09:17, Pierre De Rop wrote: > > > > Hello all, > > > > After a failed attempt to release the DM-R10 release, I would like to > call > > for a new vote on the Dependency Manager toplevel release R11. > > > > The following issues were solved: > > > > ** Bug > >* [FELIX-5630] - NullObject is created for a required dependency if > the > > component is removed and added again to the dependency manager > >* [FELIX-5636] - Component of aspect service does not have any service > > properties anymore > >* [FELIX-5657] - DM released sources can't be rebuilt > > > > ** Improvement > >* [FELIX-5619] - MultiProperyFilterIndex memory consumption > >* [FELIX-5623] - Improve performance of ComponentImpl.getName method > >* [FELIX-5650] - Support latest version of Gogo > >* [FELIX-5653] - Simplify DM-Lambda samples > >* [FELIX-5658] - Include poms in dm artifacts > > > > You can use this UNIX script to download the release and verify the > > signatures: > > > > > > http://svn.apache.org/repos/asf/felix/trunk/dependencymanage > r/release/check_staged_release.sh > > > > Usage: > > > >sh check_staged_release.sh r11 /tmp/felix-staging > > > > This script, unlike the original Felix check_stage_release.sh, is > specific > > to the new Dependency Manager release process (see FELIX-4818) and will > > download staging from https://dist.apache.org/repos/dist/dev/felix > instead > > of http://repository.apache.org/content/repositories. > > > > To rebuild the DM binaries from the source, you can then refer to > > https://svn.apache.org/repos/asf/felix/trunk/dependencymanag > er/release/resources/src/README.src > > > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] -1 Veto the release (please provide specific comments) > > The verification of the signatures had a small hiccup: there’s a > `index.html.tmp` file > present in the staging directory which breaks the signature check. > Updating the script > to also exclude `.tmp` files causes the verification to be successful. > > Did try the new DM bundles in a local project, which works, apart from the > shell: you > need to upgrade to the latest Gogo shell in order to make use of it. Not > sure why this > is needed yet. > > Building the release from sources is successful on the 2nd run after a > clean: the first > time, the build fails with the exception that the annotation processor > cannot be found. > The build is successful after re-running the build again. > I’ve created FELIX-5660 for that. > > No showstoppers for me, so +1 on the release. > > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > > My world is something with Amdatu and Apache > > Luminis Technologies > John F. Kennedylaan 32 > 7314 PS Apeldoorn > +31 88 586 46 25 > > https://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8170.94.441.B.01 > >
