Re: iPojo 1.13.0
IIUC, there's the runtime and the manipulator (used at build time). AFAIK, the runtime already has no problems with JDK > 8, but the manipulator was using an old ASM and could not run on JDK > 8. With the new release of the manipulator, you need to use iPojo runtime 1.12.1 and manipulator 1.13.0 as you indicate. And it seems to work as you said... :-) Le mer. 31 janv. 2024 à 15:51, Bengt Rodehav a écrit : > > I tried to use the new (1.13.0) versions in combination with the 1.12.1 > version of the above mentioned bundle. It seems to work (using openjdk 17) > but I'm very unsure of what is happening. > > In build time I use the following artifacts (version 1.13.0): > > - maven-ipojo-plugin > - org.apache.felix.ipojo.manipulator (as a dependency of maven-ipojo-plugin) > - org.apache.felix.ipojo.annotations > > In runtime I use: > > - org.apache.felix.ipojo (version 1.12.1) > - org.apache.felix.ipojo.webconsole (version 1.7.0) > > Is this the way I should use iPojo? Since iPojo 1.12.1 does not support > Java > 8, this surprises me. Am I missing something? > > /Bengt > > > Den tis 30 jan. 2024 kl 17:29 skrev Bengt Rodehav : > > > I am trying to use the new iPojo version that was released a couple of > > months ago (for which I'm very thankful) but I seem to miss an artifact. I > > have had the following line in my Karaf feature descriptor: > > > > mvn:org.apache.felix/org.apache.felix.ipojo/1.12.1 > > > > But when I now try to switch to iPojo 1.13.0, this artifact does not exist > > in version 1.13.0. > > > > Have I misunderstood this? Don't I need this artifact in the Karaf runtime? > > > > /Bengt > > -- Guillaume Nodet
[jira] [Closed] (FELIX-6660) osgicheck-maven-plugin:0.1.0:check fails with "Unable to scan annotations null" with Java 11+ bytecode
[
https://issues.apache.org/jira/browse/FELIX-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed FELIX-6660.
--
Resolution: Fixed
> osgicheck-maven-plugin:0.1.0:check fails with "Unable to scan annotations
> null" with Java 11+ bytecode
> --
>
> Key: FELIX-6660
> URL: https://issues.apache.org/jira/browse/FELIX-6660
> Project: Felix
> Issue Type: Improvement
> Components: Tooling
>Affects Versions: osgicheck-maven-plugin 0.1.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: osgicheck-maven-plugin 0.2.0
>
>
> Due to using an outdated ASM library in
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/tools/osgicheck-maven-plugin/pom.xml#L93
> the following error is emitted when scanning classes with java 10+ bytecode:
> {code}
> [ERROR] Unable to scan annotations null
> {code}
> which leads to a build error
> {code}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:osgicheck-maven-plugin:0.1.0:check (check-bundle) on
> project ...: Check detected errors. See log output for error messages.
> {code}.
> Both ASM should be updated and the error handling be improved to emit a
> better error message when classes cannot be scanned (including the filename).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (FELIX-6502) IPOJO Java 11+ support
[ https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed FELIX-6502. -- Resolution: Fixed > IPOJO Java 11+ support > -- > > Key: FELIX-6502 > URL: https://issues.apache.org/jira/browse/FELIX-6502 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Alexander Shaklein > Assignee: Guillaume Nodet >Priority: Minor > Fix For: ipojo-manipulator-1.13.0 > > > I have made some changes in ipojo projects to work in java 11+. > The were successfully tested on java 11, 16. Should i make a PR or i can work > with fork alone? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FELIX-6502) IPOJO Java 11+ support
[ https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-6502: --- Fix Version/s: ipojo-manipulator-1.13.0 > IPOJO Java 11+ support > -- > > Key: FELIX-6502 > URL: https://issues.apache.org/jira/browse/FELIX-6502 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Alexander Shaklein > Assignee: Guillaume Nodet >Priority: Minor > Fix For: ipojo-manipulator-1.13.0 > > > I have made some changes in ipojo projects to work in java 11+. > The were successfully tested on java 11, 16. Should i make a PR or i can work > with fork alone? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FELIX-6502) IPOJO Java 11+ support
[ https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-6502: -- Assignee: Guillaume Nodet > IPOJO Java 11+ support > -- > > Key: FELIX-6502 > URL: https://issues.apache.org/jira/browse/FELIX-6502 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Alexander Shaklein > Assignee: Guillaume Nodet >Priority: Minor > > I have made some changes in ipojo projects to work in java 11+. > The were successfully tested on java 11, 16. Should i make a PR or i can work > with fork alone? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release iPojo Manipulator 1.13.0
Closing this vote with 5 +1s and no other votes. I'll publish the binaries asap. Thx ! Guillaume Le jeu. 30 nov. 2023 à 14:55, Guillaume Nodet a écrit : > I've staged a release candidate for iPojo Manipulator 1.13.0. > It mainly brings support for recent JDK which was problematic because of > the old version of ASM used. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachefelix-1482 > > Github tag: > > https://github.com/apache/felix-dev/releases/tag/org.apache.felix.ipojo.manipulator-project-1.13.0 > > Please review and vote, > > Cheers > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release iPojo Manipulator 1.13.0
+1 Le jeu. 30 nov. 2023 à 14:55, Guillaume Nodet a écrit : > I've staged a release candidate for iPojo Manipulator 1.13.0. > It mainly brings support for recent JDK which was problematic because of > the old version of ASM used. > > Staging repository: >https://repository.apache.org/content/repositories/orgapachefelix-1482 > > Github tag: > > https://github.com/apache/felix-dev/releases/tag/org.apache.felix.ipojo.manipulator-project-1.13.0 > > Please review and vote, > > Cheers > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Release iPojo Manipulator 1.13.0
I've staged a release candidate for iPojo Manipulator 1.13.0. It mainly brings support for recent JDK which was problematic because of the old version of ASM used. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1482 Github tag: https://github.com/apache/felix-dev/releases/tag/org.apache.felix.ipojo.manipulator-project-1.13.0 Please review and vote, Cheers Guillaume Nodet
Re: [jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
I'm using the following: ➜ manipulator git:(migrate-11-jdk) mvn -v Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: /Users/gnodet/.sdkman/candidates/maven/3.9.5 Java version: 1.8.0_362, vendor: BellSoft, runtime: /Users/gnodet/.sdkman/candidates/java/8.0.362-librca/jre Default locale: en_FR, platform encoding: UTF-8 OS name: "mac os x", version: "14.1.1", arch: "aarch64", family: "mac" Le mar. 28 nov. 2023 à 17:38, Bengt Rodehav a écrit : > > I had problems building. What java version should I use when I build? > > /Bengt > > Den tis 28 nov. 2023 kl 16:16 skrev Guillaume Nodet : > > > @Bengt Rodehav, @Александр Шаклеин > > I've pushed a few updates. Could you check the branch and test it in > > your environment ? > > If that's ok, I'll do a release asap. > > > > Le mar. 28 nov. 2023 à 08:13, Александр Шаклеин > > a écrit : > > > > > > There is no conflicts now > > > > > > вт, 28 нояб. 2023 г. в 16:59, Guillaume Nodet : > > > > > > > I've reverted the removal of ipojo. > > > > > > > > Le mar. 28 nov. 2023 à 07:20, Александр Шаклеин > > > > a écrit : > > > > > > > > > > Well. Ipojo was deleted from felix directory at all. So fixing is > > > > > impossible. Only if i restore package > > > > > > > > > > вт, 28 нояб. 2023 г. в 00:42, Guillaume Nodet : > > > > > > > > > > > The PR has lots of conflicts... please fix those. > > > > > > > > > > > > Le lun. 27 nov. 2023 à 12:01, Александр Шаклеин > > > > > > a écrit : > > > > > > > > > > > > > > PR was already provided > > https://github.com/apache/felix-dev/pull/129 > > > > > > > > > > > > > > пн, 27 нояб. 2023 г. в 19:26, Guillaume Nodet < gno...@apache.org > > >: > > > > > > > > > > > > > > > If there's a need, I think we could try to release a fixed > > version > > > > of > > > > > > > > ipojo. > > > > > > > > If you provide a PR that makes the project buildable and fixes > > the > > > > ASM > > > > > > > > problem, I'm willing to start an official release... > > > > > > > > > > > > > > > > Le lun. 27 nov. 2023 à 09:12, Bengt Rodehav < be...@rodehav.com> > > a > > > > > > écrit : > > > > > > > > > > > > > > > > > > Ok - I'll see if I can figure out how to do that as well. > > > > > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > > > > > On Fri, 24 Nov 2023, 20:30 Александр Шаклеин, < > > > > cheester...@gmail.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > I'm using my own release version. > > > > > > > > > > > > > > > > > > > > пт, 24 нояб. 2023 г., 19:40 Bengt Rodehav < > > be...@rodehav.com>: > > > > > > > > > > > > > > > > > > > > > I managed to build this branch but I had to comment away > > the > > > > > > > > integration > > > > > > > > > > > test projects. > > > > > > > > > > > > > > > > > > > > > > It seems like this pull request will never make it into > > iPojo > > > > > > since > > > > > > > > it is > > > > > > > > > > > not being maintained anymore. Is that correct? If not, > > when > > > > you > > > > > > use > > > > > > > > it in > > > > > > > > > > > production systems, do you create your own release of > > iPojo > > > > or > > > > > > do you > > > > > > > > > > > simply use a snapshot version? > > > > > > > > > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > > > > > > > > > Den fre 24 nov. 2023 kl 12:44 skrev
Re: [jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
@Bengt Rodehav, @Александр Шаклеин I've pushed a few updates. Could you check the branch and test it in your environment ? If that's ok, I'll do a release asap. Le mar. 28 nov. 2023 à 08:13, Александр Шаклеин a écrit : > > There is no conflicts now > > вт, 28 нояб. 2023 г. в 16:59, Guillaume Nodet : > > > I've reverted the removal of ipojo. > > > > Le mar. 28 nov. 2023 à 07:20, Александр Шаклеин > > a écrit : > > > > > > Well. Ipojo was deleted from felix directory at all. So fixing is > > > impossible. Only if i restore package > > > > > > вт, 28 нояб. 2023 г. в 00:42, Guillaume Nodet : > > > > > > > The PR has lots of conflicts... please fix those. > > > > > > > > Le lun. 27 nov. 2023 à 12:01, Александр Шаклеин > > > > a écrit : > > > > > > > > > > PR was already provided https://github.com/apache/felix-dev/pull/129 > > > > > > > > > > пн, 27 нояб. 2023 г. в 19:26, Guillaume Nodet : > > > > > > > > > > > If there's a need, I think we could try to release a fixed version > > of > > > > > > ipojo. > > > > > > If you provide a PR that makes the project buildable and fixes the > > ASM > > > > > > problem, I'm willing to start an official release... > > > > > > > > > > > > Le lun. 27 nov. 2023 à 09:12, Bengt Rodehav a > > > > écrit : > > > > > > > > > > > > > > Ok - I'll see if I can figure out how to do that as well. > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > On Fri, 24 Nov 2023, 20:30 Александр Шаклеин, < > > cheester...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > I'm using my own release version. > > > > > > > > > > > > > > > > пт, 24 нояб. 2023 г., 19:40 Bengt Rodehav : > > > > > > > > > > > > > > > > > I managed to build this branch but I had to comment away the > > > > > > integration > > > > > > > > > test projects. > > > > > > > > > > > > > > > > > > It seems like this pull request will never make it into iPojo > > > > since > > > > > > it is > > > > > > > > > not being maintained anymore. Is that correct? If not, when > > you > > > > use > > > > > > it in > > > > > > > > > production systems, do you create your own release of iPojo > > or > > > > do you > > > > > > > > > simply use a snapshot version? > > > > > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > > > > > Den fre 24 nov. 2023 kl 12:44 skrev Bengt Rodehav < > > > > be...@rodehav.com > > > > > > >: > > > > > > > > > > > > > > > > > > > OK - thanks! > > > > > > > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > > > > > > > Den fre 24 nov. 2023 kl 11:57 skrev Александр Шаклеин < > > > > > > > > > > cheester...@gmail.com>: > > > > > > > > > > > > > > > > > > > >> No. This one > > > > > > > > > >> https://github.com/apache/felix-dev/pull/129 > > > > > > > > > >> > > > > > > > > > >> пт, 24 нояб. 2023 г. в 19:55, Bengt Rodehav < > > > > be...@rodehav.com>: > > > > > > > > > >> > > > > > > > > > >> > Is this the commit I should be using? > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/kwin/felix-dev/commit/93b773b29d41e625bdca52f200f8171824ad9ae9 > > > > > > > >
Re: [jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
I've reverted the removal of ipojo. Le mar. 28 nov. 2023 à 07:20, Александр Шаклеин a écrit : > > Well. Ipojo was deleted from felix directory at all. So fixing is > impossible. Only if i restore package > > вт, 28 нояб. 2023 г. в 00:42, Guillaume Nodet : > > > The PR has lots of conflicts... please fix those. > > > > Le lun. 27 nov. 2023 à 12:01, Александр Шаклеин > > a écrit : > > > > > > PR was already provided https://github.com/apache/felix-dev/pull/129 > > > > > > пн, 27 нояб. 2023 г. в 19:26, Guillaume Nodet : > > > > > > > If there's a need, I think we could try to release a fixed version of > > > > ipojo. > > > > If you provide a PR that makes the project buildable and fixes the ASM > > > > problem, I'm willing to start an official release... > > > > > > > > Le lun. 27 nov. 2023 à 09:12, Bengt Rodehav a > > écrit : > > > > > > > > > > Ok - I'll see if I can figure out how to do that as well. > > > > > > > > > > /Bengt > > > > > > > > > > On Fri, 24 Nov 2023, 20:30 Александр Шаклеин, > > > > > > wrote: > > > > > > > > > > > I'm using my own release version. > > > > > > > > > > > > пт, 24 нояб. 2023 г., 19:40 Bengt Rodehav : > > > > > > > > > > > > > I managed to build this branch but I had to comment away the > > > > integration > > > > > > > test projects. > > > > > > > > > > > > > > It seems like this pull request will never make it into iPojo > > since > > > > it is > > > > > > > not being maintained anymore. Is that correct? If not, when you > > use > > > > it in > > > > > > > production systems, do you create your own release of iPojo or > > do you > > > > > > > simply use a snapshot version? > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > Den fre 24 nov. 2023 kl 12:44 skrev Bengt Rodehav < > > be...@rodehav.com > > > > >: > > > > > > > > > > > > > > > OK - thanks! > > > > > > > > > > > > > > > > /Bengt > > > > > > > > > > > > > > > > Den fre 24 nov. 2023 kl 11:57 skrev Александр Шаклеин < > > > > > > > > cheester...@gmail.com>: > > > > > > > > > > > > > > > >> No. This one > > > > > > > >> https://github.com/apache/felix-dev/pull/129 > > > > > > > >> > > > > > > > >> пт, 24 нояб. 2023 г. в 19:55, Bengt Rodehav < > > be...@rodehav.com>: > > > > > > > >> > > > > > > > >> > Is this the commit I should be using? > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > https://github.com/kwin/felix-dev/commit/93b773b29d41e625bdca52f200f8171824ad9ae9 > > > > > > > >> > > > > > > > > >> > /Bengt > > > > > > > >> > > > > > > > > >> > Den tors 23 nov. 2023 kl 21:08 skrev Bengt Rodehav < > > > > > > be...@rodehav.com > > > > > > > >: > > > > > > > >> > > > > > > > > >> > > That sounds great! > > > > > > > >> > > > > > > > > > >> > > Is there a release that I can download? I would really > > like > > > > to try > > > > > > > it. > > > > > > > >> > > > > > > > > > >> > > /Bengt > > > > > > > >> > > > > > > > > > >> > > On Thu, 23 Nov 2023, 18:37 Александр Шаклеин, < > > > > > > > cheester...@gmail.com> > > > > > > > >> > > wrote: > > > > > > > >> > > > > > > > > > >> > >> I have tested it with chan
Re: [jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
The PR has lots of conflicts... please fix those. Le lun. 27 nov. 2023 à 12:01, Александр Шаклеин a écrit : > > PR was already provided https://github.com/apache/felix-dev/pull/129 > > пн, 27 нояб. 2023 г. в 19:26, Guillaume Nodet : > > > If there's a need, I think we could try to release a fixed version of > > ipojo. > > If you provide a PR that makes the project buildable and fixes the ASM > > problem, I'm willing to start an official release... > > > > Le lun. 27 nov. 2023 à 09:12, Bengt Rodehav a écrit : > > > > > > Ok - I'll see if I can figure out how to do that as well. > > > > > > /Bengt > > > > > > On Fri, 24 Nov 2023, 20:30 Александр Шаклеин, > > wrote: > > > > > > > I'm using my own release version. > > > > > > > > пт, 24 нояб. 2023 г., 19:40 Bengt Rodehav : > > > > > > > > > I managed to build this branch but I had to comment away the > > integration > > > > > test projects. > > > > > > > > > > It seems like this pull request will never make it into iPojo since > > it is > > > > > not being maintained anymore. Is that correct? If not, when you use > > it in > > > > > production systems, do you create your own release of iPojo or do you > > > > > simply use a snapshot version? > > > > > > > > > > /Bengt > > > > > > > > > > Den fre 24 nov. 2023 kl 12:44 skrev Bengt Rodehav > >: > > > > > > > > > > > OK - thanks! > > > > > > > > > > > > /Bengt > > > > > > > > > > > > Den fre 24 nov. 2023 kl 11:57 skrev Александр Шаклеин < > > > > > > cheester...@gmail.com>: > > > > > > > > > > > >> No. This one > > > > > >> https://github.com/apache/felix-dev/pull/129 > > > > > >> > > > > > >> пт, 24 нояб. 2023 г. в 19:55, Bengt Rodehav : > > > > > >> > > > > > >> > Is this the commit I should be using? > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > https://github.com/kwin/felix-dev/commit/93b773b29d41e625bdca52f200f8171824ad9ae9 > > > > > >> > > > > > > >> > /Bengt > > > > > >> > > > > > > >> > Den tors 23 nov. 2023 kl 21:08 skrev Bengt Rodehav < > > > > be...@rodehav.com > > > > > >: > > > > > >> > > > > > > >> > > That sounds great! > > > > > >> > > > > > > > >> > > Is there a release that I can download? I would really like > > to try > > > > > it. > > > > > >> > > > > > > > >> > > /Bengt > > > > > >> > > > > > > > >> > > On Thu, 23 Nov 2023, 18:37 Александр Шаклеин, < > > > > > cheester...@gmail.com> > > > > > >> > > wrote: > > > > > >> > > > > > > > >> > >> I have tested it with changes in suggested PR with jdk21. It > > > > works > > > > > >> well. > > > > > >> > >> > > > > > >> > >> чт, 23 нояб. 2023 г., 19:08 Bengt Rodehav > >: > > > > > >> > >> > > > > > >> > >> > I am revisiting this issue. Looking to start using iPojo in > > > > Karaf > > > > > >> > 4.4.4 > > > > > >> > >> > which supports JDK20. Did anyone create (and release) a new > > > > > >> version of > > > > > >> > >> > iPojo that works with JDK20? As I understood it, it was > > mainly > > > > > >> about > > > > > >> > >> using > > > > > >> > >> > new version of ASM. > > > > > >> > >> > > > > > > >> > >> > /Bengt > > > > > >> > >> > > > > > > >> > >> > Den tis 22 mars 2022 kl 17:31 skrev Bengt Rodehav < > > > > > >> be...@rodehav.com > >
Re: [jira] [Commented] (FELIX-6502) IPOJO Java 11+ support
If there's a need, I think we could try to release a fixed version of ipojo. If you provide a PR that makes the project buildable and fixes the ASM problem, I'm willing to start an official release... Le lun. 27 nov. 2023 à 09:12, Bengt Rodehav a écrit : > > Ok - I'll see if I can figure out how to do that as well. > > /Bengt > > On Fri, 24 Nov 2023, 20:30 Александр Шаклеин, wrote: > > > I'm using my own release version. > > > > пт, 24 нояб. 2023 г., 19:40 Bengt Rodehav : > > > > > I managed to build this branch but I had to comment away the integration > > > test projects. > > > > > > It seems like this pull request will never make it into iPojo since it is > > > not being maintained anymore. Is that correct? If not, when you use it in > > > production systems, do you create your own release of iPojo or do you > > > simply use a snapshot version? > > > > > > /Bengt > > > > > > Den fre 24 nov. 2023 kl 12:44 skrev Bengt Rodehav : > > > > > > > OK - thanks! > > > > > > > > /Bengt > > > > > > > > Den fre 24 nov. 2023 kl 11:57 skrev Александр Шаклеин < > > > > cheester...@gmail.com>: > > > > > > > >> No. This one > > > >> https://github.com/apache/felix-dev/pull/129 > > > >> > > > >> пт, 24 нояб. 2023 г. в 19:55, Bengt Rodehav : > > > >> > > > >> > Is this the commit I should be using? > > > >> > > > > >> > > > > >> > > > > >> > > > > > https://github.com/kwin/felix-dev/commit/93b773b29d41e625bdca52f200f8171824ad9ae9 > > > >> > > > > >> > /Bengt > > > >> > > > > >> > Den tors 23 nov. 2023 kl 21:08 skrev Bengt Rodehav < > > be...@rodehav.com > > > >: > > > >> > > > > >> > > That sounds great! > > > >> > > > > > >> > > Is there a release that I can download? I would really like to try > > > it. > > > >> > > > > > >> > > /Bengt > > > >> > > > > > >> > > On Thu, 23 Nov 2023, 18:37 Александр Шаклеин, < > > > cheester...@gmail.com> > > > >> > > wrote: > > > >> > > > > > >> > >> I have tested it with changes in suggested PR with jdk21. It > > works > > > >> well. > > > >> > >> > > > >> > >> чт, 23 нояб. 2023 г., 19:08 Bengt Rodehav : > > > >> > >> > > > >> > >> > I am revisiting this issue. Looking to start using iPojo in > > Karaf > > > >> > 4.4.4 > > > >> > >> > which supports JDK20. Did anyone create (and release) a new > > > >> version of > > > >> > >> > iPojo that works with JDK20? As I understood it, it was mainly > > > >> about > > > >> > >> using > > > >> > >> > new version of ASM. > > > >> > >> > > > > >> > >> > /Bengt > > > >> > >> > > > > >> > >> > Den tis 22 mars 2022 kl 17:31 skrev Bengt Rodehav < > > > >> be...@rodehav.com > > > >> > >: > > > >> > >> > > > > >> > >> > > Not sure how or by whom a new release of iPojo could be > > > created. > > > >> > Does > > > >> > >> > > anyone know? > > > >> > >> > > > > > >> > >> > > /Bengt > > > >> > >> > > > > > >> > >> > > Den tis 15 mars 2022 kl 17:25 skrev Bengt Rodehav (Jira) < > > > >> > >> > j...@apache.org > > > >> > >> > > >: > > > >> > >> > > > > > >> > >> > >> > > > >> > >> > >> [ > > > >> > >> > >> > > > >> > >> > > > > >> > >> > > > >> > > > > >> > > > > > https://issues.apache.org/jira/browse/FELIX-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507040#comment-17507040 > > > >> > >> > >> ] > > > >> > >> > >> > > > >> > >> > >> Bengt Rodehav commented on FELIX-6502: > > > >> > >> > >> -- > > > >> > >> > >> > > > >> > >> > >> I have done some testing regarding this fix and after > > updating > > > >> to > > > >> > Asm > > > >> > >> > 9.2 > > > >> > >> > >> iPojo now works with OpenJDK 17. I would really like for a > > new > > > >> > >> release > > > >> > >> > of > > > >> > >> > >> iPojo including this fix to be made. > > > >> > >> > >> > > > >> > >> > >> > IPOJO Java 11+ support > > > >> > >> > >> > -- > > > >> > >> > >> > > > > >> > >> > >> > Key: FELIX-6502 > > > >> > >> > >> > URL: > > > >> > >> https://issues.apache.org/jira/browse/FELIX-6502 > > > >> > >> > >> > Project: Felix > > > >> > >> > >> > Issue Type: Improvement > > > >> > >> > >> > Components: iPOJO > > > >> > >> > >> >Reporter: Alexander Shaklein > > > >> > >> > >> >Priority: Minor > > > >> > >> > >> > > > > >> > >> > >> > I have made some changes in ipojo projects to work in java > > > >> 11+. > > > >> > >> > >> > The were successfully tested on java 11, 16. Should i > > make a > > > >> PR > > > >> > or > > > >> > >> i > > > >> > >> > >> can work with fork alone? > > > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> -- > > > >> > >> > >> This message was sent by Atlassian Jira > > > >> > >> > >> (v8.20.1#820001) > > > >> > >> > >> > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > > > > > >> > > > > >> > > > > > > > > > -- Guillaume Nodet
Re: [VOTE] Release Apache Felix Parent Pom 8
+1 Le jeu. 23 nov. 2023 à 07:17, Carsten Ziegeler a écrit : > > Hi, > > We updated our parent pom to the latest Apache parent 31 and adjusted it > to allow building projects with Java 17. > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1481 > > You can use this UNIX script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1481 /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. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe > cziege...@apache.org -- Guillaume Nodet
Re: [VOTE] Apache Felix maven-bundle-plugin 5.1.9 release
+1 Le lun. 15 mai 2023 à 10:45, Jean-Baptiste Onofré a écrit : > Hi, > > I submit maven-bundle-plugin 5.1.9 release to your vote. > > This release includes: > - fix a bug producing non-reproducible build > - minor warning fixes with maven 3.9.2 (still work to do to fix all) > - add skip parameter on the bundle goal (and inherited like manifest goal) > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12353241 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachefelix-1460/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/felix/maven-bundle-plugin-5.1.9/ > > Git tag: > maven-bundle-plugin-5.1.9 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB > -- Guillaume Nodet
Re: [VOTE] Apache Felix Log 1.3.0 release
+1 Le lun. 15 mai 2023 à 09:00, Jean-Baptiste Onofré a écrit : > Hi all, > > As discussed on the mailing list, I submit Apache Felix Log 1.3.0 > release to your vote. > > This release upgrades to OSGi Log 1.5.0 spec. > > You can take a look on the Release Notes for details: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12353242 > > Maven Staging Repository: > https://repository.apache.org/content/repositories/orgapachefelix-1459/ > > Dist Staging Repository: > https://dist.apache.org/repos/dist/dev/felix/ > > Git tag: > org.apache.felix.log-1.3.0 > > Please vote to approve this release: > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Regards > JB > -- Guillaume Nodet
[jira] [Resolved] (FELIX-6597) IllegalAccess when using reflection on public methods
[
https://issues.apache.org/jira/browse/FELIX-6597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-6597.
Fix Version/s: gogo.runtime-1.1.6
Resolution: Fixed
> IllegalAccess when using reflection on public methods
> -
>
> Key: FELIX-6597
> URL: https://issues.apache.org/jira/browse/FELIX-6597
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.runtime-1.1.6
>
>
> When using reflection to invoke a method on an object, the {{Reflective}}
> object only considers the method on the class. If the class is a non public
> class (such as a private implementation of a public interface), the new
> access rules make it impossible to use.
> The proposal is to go through methods of public interfaces / classes first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FELIX-6597) IllegalAccess when using reflection on public methods
Guillaume Nodet created FELIX-6597:
--
Summary: IllegalAccess when using reflection on public methods
Key: FELIX-6597
URL: https://issues.apache.org/jira/browse/FELIX-6597
Project: Felix
Issue Type: Bug
Components: Gogo Runtime
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
When using reflection to invoke a method on an object, the {{Reflective}}
object only considers the method on the class. If the class is a non public
class (such as a private implementation of a public interface), the new access
rules make it impossible to use.
The proposal is to go through methods of public interfaces / classes first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[
https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538036#comment-17538036
]
Guillaume Nodet edited comment on FELIX-6529 at 5/17/22 8:57 AM:
-
Wouldn't it be easier to just use {{String.intern()}} instead ?
was (Author: gnt):
Wouldn't it be easier to just use `String.intern()` instead ?
> Improve memory usage ManifestParser using String deduplication
> --
>
> Key: FELIX-6529
> URL: https://issues.apache.org/jira/browse/FELIX-6529
> Project: Felix
> Issue Type: Improvement
>Reporter: Johannes Edmeier
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-7.0.4
>
> Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png,
> image-2022-05-13-14-17-55-965.png
>
>
> In my heap dump I've seen a lot of duplicate Strings produced by the
> ManifestParser.
> It creates a lot of equal strings for the keys in the manifest but doesn't
> deduplicate them and they're hold forever producing a lot on retained heap.
> I've patched the ManifestParser to deduplicate just the keys and could save
> ~8 Megs of heap.
> Total usage before: 38MB after: 30MB
> Duplicated Strings before:
> !image-2022-05-13-14-16-39-509.png|width=658,height=203!
> Duplicated Strings after:
> !image-2022-05-13-14-17-55-965.png|width=793,height=200!
> See patch attached.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (FELIX-6529) Improve memory usage ManifestParser using String deduplication
[ https://issues.apache.org/jira/browse/FELIX-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538036#comment-17538036 ] Guillaume Nodet commented on FELIX-6529: Wouldn't it be easier to just use `String.intern()` instead ? > Improve memory usage ManifestParser using String deduplication > -- > > Key: FELIX-6529 > URL: https://issues.apache.org/jira/browse/FELIX-6529 > Project: Felix > Issue Type: Improvement >Reporter: Johannes Edmeier >Assignee: Karl Pauls >Priority: Major > Fix For: framework-7.0.4 > > Attachments: ManifestParser.patch, image-2022-05-13-14-16-39-509.png, > image-2022-05-13-14-17-55-965.png > > > In my heap dump I've seen a lot of duplicate Strings produced by the > ManifestParser. > It creates a lot of equal strings for the keys in the manifest but doesn't > deduplicate them and they're hold forever producing a lot on retained heap. > I've patched the ManifestParser to deduplicate just the keys and could save > ~8 Megs of heap. > Total usage before: 38MB after: 30MB > Duplicated Strings before: > !image-2022-05-13-14-16-39-509.png|width=658,height=203! > Duplicated Strings after: > !image-2022-05-13-14-17-55-965.png|width=793,height=200! > See patch attached. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[RESULT] [VOTE] Release Felix Gogo Runtime 1.1.6
Closing this vote 7 +1s and no other votes. Thx ! Guillaume Le ven. 18 mars 2022 à 10:44, Guillaume Nodet a écrit : > Hi, > > WE solved 1 issue in this release: > - [FELIX-6509] - Evaluation of subshell String results are wrong on > Windows > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1421 > > You can use this unix script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1418 /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. > > Guillaume Nodet > -- Guillaume Nodet
[VOTE] Release Felix Gogo Runtime 1.1.6
Hi, WE solved 1 issue in this release: - [FELIX-6509] - Evaluation of subshell String results are wrong on Windows Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1421 You can use this unix script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1418 /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. Guillaume Nodet
[jira] [Resolved] (FELIX-6509) Evaluation of subshell String results are wrong on Windows
[
https://issues.apache.org/jira/browse/FELIX-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-6509.
Fix Version/s: gogo.runtime-1.1.6
Resolution: Fixed
> Evaluation of subshell String results are wrong on Windows
> --
>
> Key: FELIX-6509
> URL: https://issues.apache.org/jira/browse/FELIX-6509
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Grzegorz Grzybek
> Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.runtime-1.1.6
>
>
> I'm trying this use case (gogo-runtime 1.1.4):
> {noformat}
> karaf@root()> "MyTest" toCharArray
> [M, y, T, e, s, t]
> {noformat}
> and it's fine. However, trying this:
> {noformat}
> karaf@root()> config:property-set -p test test "MyTest"
> karaf@root()> config:property-get -p test test
> MyTest
> karaf@root()> ((config:property-get -p test test)) toCharArray
> ]M, y, T, e, s, t,
> {noformat}
> produces weird result. Actually understandable - the {{\r}} is not trimmed
> from the result, so it moves cursor to the beginning of the line, and {{]}}
> overwrites initial {{[}}.
> the reason [is this
> loop|https://github.com/apache/felix-dev/blob/org.apache.felix.gogo.runtime-1.1.4/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Closure.java#L388-L390]:
> {code:java}
> String s = baos.toString();
> while (!s.isEmpty() && s.charAt(s.length() - 1) == '\n') {
> s = s.substring(0, s.length() - 1);
> }
> {code}
> it isn't OS aware. {{\r}} should also be removed (probably affects Mac too).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (FELIX-6509) Evaluation of subshell String results are wrong on Windows
[
https://issues.apache.org/jira/browse/FELIX-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502187#comment-17502187
]
Guillaume Nodet commented on FELIX-6509:
[~ggrzybek] I don't think the code is related to the snippet you gave.
I've debugged the problem and traced it down to
https://github.com/apache/felix-dev/blob/master/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/CommandSessionImpl.java#L333
> Evaluation of subshell String results are wrong on Windows
> --
>
> Key: FELIX-6509
> URL: https://issues.apache.org/jira/browse/FELIX-6509
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
>
> I'm trying this use case (gogo-runtime 1.1.4):
> {noformat}
> karaf@root()> "MyTest" toCharArray
> [M, y, T, e, s, t]
> {noformat}
> and it's fine. However, trying this:
> {noformat}
> karaf@root()> config:property-set -p test test "MyTest"
> karaf@root()> config:property-get -p test test
> MyTest
> karaf@root()> ((config:property-get -p test test)) toCharArray
> ]M, y, T, e, s, t,
> {noformat}
> produces weird result. Actually understandable - the {{\r}} is not trimmed
> from the result, so it moves cursor to the beginning of the line, and {{]}}
> overwrites initial {{[}}.
> the reason [is this
> loop|https://github.com/apache/felix-dev/blob/org.apache.felix.gogo.runtime-1.1.4/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Closure.java#L388-L390]:
> {code:java}
> String s = baos.toString();
> while (!s.isEmpty() && s.charAt(s.length() - 1) == '\n') {
> s = s.substring(0, s.length() - 1);
> }
> {code}
> it isn't OS aware. {{\r}} should also be removed (probably affects Mac too).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (FELIX-6509) Evaluation of subshell String results are wrong on Windows
[
https://issues.apache.org/jira/browse/FELIX-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502008#comment-17502008
]
Guillaume Nodet commented on FELIX-6509:
@reporter the problem is located here, at least for the plain gogo shell:
[https://github.com/apache/felix-dev/blob/master/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/CommandSessionImpl.java#L333]
One possible way would be to use a custom function that would support printing
as unicode non printable characters 0x00 -> 0x1f). A better alternative may be
found in Karaf by leveraging the jline wcwidth method
([https://github.com/jline/jline3/blob/master/terminal/src/main/java/org/jline/utils/WCWidth.java#L47)]
: if the wcwidth of the character is less than 1, print the unicode hex value.
> Evaluation of subshell String results are wrong on Windows
> --
>
> Key: FELIX-6509
> URL: https://issues.apache.org/jira/browse/FELIX-6509
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
>
> I'm trying this use case (gogo-runtime 1.1.4):
> {noformat}
> karaf@root()> "MyTest" toCharArray
> [M, y, T, e, s, t]
> {noformat}
> and it's fine. However, trying this:
> {noformat}
> karaf@root()> config:property-set -p test test "MyTest"
> karaf@root()> config:property-get -p test test
> MyTest
> karaf@root()> ((config:property-get -p test test)) toCharArray
> ]M, y, T, e, s, t,
> {noformat}
> produces weird result. Actually understandable - the {{\r}} is not trimmed
> from the result, so it moves cursor to the beginning of the line, and {{]}}
> overwrites initial {{[}}.
> the reason [is this
> loop|https://github.com/apache/felix-dev/blob/org.apache.felix.gogo.runtime-1.1.4/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Closure.java#L388-L390]:
> {code:java}
> String s = baos.toString();
> while (!s.isEmpty() && s.charAt(s.length() - 1) == '\n') {
> s = s.substring(0, s.length() - 1);
> }
> {code}
> it isn't OS aware. {{\r}} should also be removed (probably affects Mac too).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (FELIX-6509) Evaluation of subshell String results are wrong on Windows
[
https://issues.apache.org/jira/browse/FELIX-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502008#comment-17502008
]
Guillaume Nodet edited comment on FELIX-6509 at 3/6/22, 8:28 PM:
-
[~ggrzybek] the problem is located here, at least for the plain gogo shell:
[https://github.com/apache/felix-dev/blob/master/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/CommandSessionImpl.java#L333]
One possible way would be to use a custom function that would support printing
as unicode non printable characters 0x00 -> 0x1f). A better alternative may be
found in Karaf by leveraging the jline wcwidth method
([https://github.com/jline/jline3/blob/master/terminal/src/main/java/org/jline/utils/WCWidth.java#L47)]
: if the wcwidth of the character is less than 1, print the unicode hex value.
was (Author: gnt):
@reporter the problem is located here, at least for the plain gogo shell:
[https://github.com/apache/felix-dev/blob/master/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/CommandSessionImpl.java#L333]
One possible way would be to use a custom function that would support printing
as unicode non printable characters 0x00 -> 0x1f). A better alternative may be
found in Karaf by leveraging the jline wcwidth method
([https://github.com/jline/jline3/blob/master/terminal/src/main/java/org/jline/utils/WCWidth.java#L47)]
: if the wcwidth of the character is less than 1, print the unicode hex value.
> Evaluation of subshell String results are wrong on Windows
> --
>
> Key: FELIX-6509
> URL: https://issues.apache.org/jira/browse/FELIX-6509
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Grzegorz Grzybek
>Assignee: Guillaume Nodet
>Priority: Major
>
> I'm trying this use case (gogo-runtime 1.1.4):
> {noformat}
> karaf@root()> "MyTest" toCharArray
> [M, y, T, e, s, t]
> {noformat}
> and it's fine. However, trying this:
> {noformat}
> karaf@root()> config:property-set -p test test "MyTest"
> karaf@root()> config:property-get -p test test
> MyTest
> karaf@root()> ((config:property-get -p test test)) toCharArray
> ]M, y, T, e, s, t,
> {noformat}
> produces weird result. Actually understandable - the {{\r}} is not trimmed
> from the result, so it moves cursor to the beginning of the line, and {{]}}
> overwrites initial {{[}}.
> the reason [is this
> loop|https://github.com/apache/felix-dev/blob/org.apache.felix.gogo.runtime-1.1.4/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Closure.java#L388-L390]:
> {code:java}
> String s = baos.toString();
> while (!s.isEmpty() && s.charAt(s.length() - 1) == '\n') {
> s = s.substring(0, s.length() - 1);
> }
> {code}
> it isn't OS aware. {{\r}} should also be removed (probably affects Mac too).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (FELIX-6509) Evaluation of subshell String results are wrong on Windows
[
https://issues.apache.org/jira/browse/FELIX-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-6509:
--
Assignee: Guillaume Nodet
> Evaluation of subshell String results are wrong on Windows
> --
>
> Key: FELIX-6509
> URL: https://issues.apache.org/jira/browse/FELIX-6509
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Grzegorz Grzybek
> Assignee: Guillaume Nodet
>Priority: Major
>
> I'm trying this use case (gogo-runtime 1.1.4):
> {noformat}
> karaf@root()> "MyTest" toCharArray
> [M, y, T, e, s, t]
> {noformat}
> and it's fine. However, trying this:
> {noformat}
> karaf@root()> config:property-set -p test test "MyTest"
> karaf@root()> config:property-get -p test test
> MyTest
> karaf@root()> ((config:property-get -p test test)) toCharArray
> ]M, y, T, e, s, t,
> {noformat}
> produces weird result. Actually understandable - the {{\r}} is not trimmed
> from the result, so it moves cursor to the beginning of the line, and {{]}}
> overwrites initial {{[}}.
> the reason [is this
> loop|https://github.com/apache/felix-dev/blob/org.apache.felix.gogo.runtime-1.1.4/gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Closure.java#L388-L390]:
> {code:java}
> String s = baos.toString();
> while (!s.isEmpty() && s.charAt(s.length() - 1) == '\n') {
> s = s.substring(0, s.length() - 1);
> }
> {code}
> it isn't OS aware. {{\r}} should also be removed (probably affects Mac too).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (FELIX-5383) Support parallel bundle starting
[
https://issues.apache.org/jira/browse/FELIX-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-5383:
--
Assignee: (was: Guillaume Nodet)
> Support parallel bundle starting
>
>
> Key: FELIX-5383
> URL: https://issues.apache.org/jira/browse/FELIX-5383
> Project: Felix
> Issue Type: Improvement
> Components: File Install
>Affects Versions: fileinstall-3.5.4
>Reporter: Matt Magoffin
>Priority: Major
> Fix For: fileinstall-3.7.0
>
>
> I have an application that uses Felix File Install to start a set of bundles
> that use Blueprint configuration extensively, but with the poll time disabled
> ({{felix.fileinstall.poll = 0}}) because I only want the bundles started at
> application startup time. Sometimes one bundle might have a Blueprint service
> dependency provided by another bundle such that when started and that other
> bundle has not been started yet causes a service timeout. The ordering File
> Install uses to start bundles is indeterminate (a {{HashSet}} is passed to
> {{startBundles(Collection bundles)}}) so I thought a good solution
> would be to start bundles in parallel, so if one bundle gets stuck when
> starting, waiting for a Blueprint service to become available, other bundles
> can continue to be started under the assumption one of them will be providing
> that service "soon".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-4577) Setting multiple directories in felix.fileinstall.dir doesn't work
[
https://issues.apache.org/jira/browse/FELIX-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-4577:
--
Assignee: (was: Guillaume Nodet)
> Setting multiple directories in felix.fileinstall.dir doesn't work
> --
>
> Key: FELIX-4577
> URL: https://issues.apache.org/jira/browse/FELIX-4577
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.2.8
>Reporter: Krzysztof Sobkowiak
>Priority: Major
>
> In the File Install documentation
> (http://felix.apache.org/site/apache-felix-file-install.html) you can read:
> bq. Starting with version 3.1.0 it is possible to specify several directories
> to watch with the system property {{felix.fileinstall.dir}}; this property
> can either point to a single directory or a comma separated list of
> directories.
> This method with comma separated list of directories seems not to work.
> Cfr.
> http://servicemix.396122.n5.nabble.com/sub-directories-in-deploy-td5721238.html
> Could you please check it and eventually correct the documentation?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6103) ConfigInstaller, when using NotCachablePersistenceManager, can restore cached stale properties
[
https://issues.apache.org/jira/browse/FELIX-6103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17158567#comment-17158567
]
Guillaume Nodet commented on FELIX-6103:
Yes, the 1-arg {{getConfiguration(pid)}} method call should only be used from
the bundle which is using the configuration directly. Any other usage, such as
the one here, should use either {{getConfiguration(pid, "?")}} or
{{getConfiguration(pid, null)}}.
> ConfigInstaller, when using NotCachablePersistenceManager, can restore cached
> stale properties
> --
>
> Key: FELIX-6103
> URL: https://issues.apache.org/jira/browse/FELIX-6103
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: Mariano Alvaro
>Assignee: Raymond Augé
>Priority: Major
> Fix For: fileinstall-3.6.6
>
> Attachments: diffs.txt
>
>
> When using a NotCachablePersistenceManager the following steps occur when
> changing .config file values:
>
> # ConfigInstaller.setConfig gets called.
> # Configuration gets retrieved from ConfigInstaller.getConfiguration method
> # getConfigurationAdmin().listConfigurations(filter) returns a new
> configuration each time because NotCacheablePersitenceManger is used.
> # Changes are performed in the new Configuration.
> # ConfigInstaller.doConfigurationEvent gets called back and retrieves
> configuration from configurationAdmin.
> # ConfigurationAdmin.getConfiguration retrieves cached value (hasn't been
> updated in step 4 because a new differente configuration was returned)
> # config file gets updated with cached values
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-5694) maven-scr-plugin use service name property as filename.xml
[
https://issues.apache.org/jira/browse/FELIX-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-5694:
---
Component/s: (was: Maven Bundle Plugin)
SCR Tooling
> maven-scr-plugin use service name property as filename.xml
> --
>
> Key: FELIX-5694
> URL: https://issues.apache.org/jira/browse/FELIX-5694
> Project: Felix
> Issue Type: New Feature
> Components: SCR Tooling
>Reporter: Stefan Triller
>Priority: Major
> Labels: features, maven
>
> Hi,
> the current maven-scr-plugin uses the fully qualified class name as a name
> for the xml file that will contain the generated service description.
> Unfortunately the Eclipse IDE uses the service name as the name for the xml
> file, i.e. for
> {code:java}
> package org.mycompany;
> @Component(name = "org.topic.myservice")
> public class MyClassName {
> {code}
> it would create "org.topic.myservice.xml" inside the OSGI-INF directory.
> At the moment your maven-scr-plugin would create
> "org.mycompany.MyClassName.xml".
> if you use both, maven and the Eclipse IDE on the same workspace this will
> result in duplicate service descriptions.
> Would it be possible for you to implement a new option that allows for using
> the service name (if set) as a name for the generated xml file?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-5699) baseline check behaves weirdly for jackrabbit-webdav under Java 9
[ https://issues.apache.org/jira/browse/FELIX-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-5699. Resolution: Cannot Reproduce > baseline check behaves weirdly for jackrabbit-webdav under Java 9 > - > > Key: FELIX-5699 > URL: https://issues.apache.org/jira/browse/FELIX-5699 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.3.0 >Reporter: Julian Reschke >Priority: Major > > See https://issues.apache.org/jira/browse/JCR-4191 -- it seems that the > bundle plugin's baseline check behaves strangely when run with Java 9. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-5757) Consolidate maven-bundle-plugin FAQ pages
[ https://issues.apache.org/jira/browse/FELIX-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-5757. Resolution: Fixed > Consolidate maven-bundle-plugin FAQ pages > - > > Key: FELIX-5757 > URL: https://issues.apache.org/jira/browse/FELIX-5757 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Konrad Windszus >Priority: Major > > Currently there are two different FAQ pages related to the maven-bundle-plugin > # > https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Bundle+Plugin+FAQ > (also linked from the Maven site at > http://felix.apache.org/components/bundle-plugin/index.html) > # > http://felix.apache.org/documentation/faqs/apache-felix-bundle-plugin-faq.html > Please consolidate both into one single page and make sure that this single > page is properly linked from the generated Maven site. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-5890) NoClassDefFoundError aQute/bnd/osgi/Analyzer
[ https://issues.apache.org/jira/browse/FELIX-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-5890. Resolution: Cannot Reproduce > NoClassDefFoundError aQute/bnd/osgi/Analyzer > > > Key: FELIX-5890 > URL: https://issues.apache.org/jira/browse/FELIX-5890 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin > Environment: See the build logs >Reporter: Joel Costigliola >Priority: Major > Attachments: failed-build.txt > > > The [AssertJ > Core|http://joel-costigliola.github.io/assertj/assertj-core.html] project > Travis CI Build failed using the oracle JDK 10 with a NoClassDefFoundError > (see the logs) the plugin version was 3.5.1. > Note that the build succeeds for the other jdk so I'm not sure if the issue > is in the maven-bundle-plugin or the oracle jdk 10. > The link to the failed build is > https://travis-ci.org/joel-costigliola/assertj-core/jobs/406535117 which is a > part of https://travis-ci.org/joel-costigliola/assertj-core/builds/406535111. > I also have attached the logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-5840) Occasional NPE when build multiple bundle modules in parallel
[
https://issues.apache.org/jira/browse/FELIX-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-5840:
---
Description:
{code}
[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle (default-bundle) on project
mme-emulator: Execution default-bundle of goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed. NullPointerException
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle (default-bundle) on project
mme-emulator: Execution default-bundle of goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-bundle of goal org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:60)
at
org.apache.felix.bundleplugin.BundlePlugin.buildDependencyGraph(BundlePlugin.java:350)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
{code}
was:
[ERROR] Failed to execute goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle (default-bundle) on project
mme-emulator: Execution default-bundle of goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed. NullPointerException
-> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle (default-bundle) on project
mme-emulator: Execution default-bundle of goal
org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-bundle of goal org.apache.felix:maven-bundle-plugin:3.5.0:bundle failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:60)
at
org.apache.felix.bundleplugin.BundlePlugin.buildDependencyGraph(BundlePlugin.java:350)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
> Occasional NPE w
[jira] [Updated] (FELIX-6198) Problem with embeding elasticsearch dependency
[
https://issues.apache.org/jira/browse/FELIX-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-6198:
---
Summary: Problem with embeding elasticsearch dependency (was: Problem with
ebmeding elasticsearch dependency)
> Problem with embeding elasticsearch dependency
> --
>
> Key: FELIX-6198
> URL: https://issues.apache.org/jira/browse/FELIX-6198
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-4.2.1
> Environment: Adobe Experience Manager 6.4, Java 1.8 (tried on 9 and
> 11 as well), elasticsearch version 7.4.1
>Reporter: Tadija
>Priority: Major
> Labels: newbie
> Attachments: Screenshot 2019-10-30 at 09.54.56.png, Screenshot
> 2019-11-01 at 20.36.09.png
>
>
> I am trying to embed the following dependency and it's transitive
> dependencies:
>
> {code:java}
>
> org.elasticsearch.client
> elasticsearch-rest-high-level-client
>
>
> org.elasticsearch
> elasticsearch
>
>
> org.elasticsearch.client
> elasticsearch-rest-client
> {code}
>
> I am working with AEM 6.4v and tried maven-bundle-plugin versions 2.1.0 and
> 4.2.1.
> With first version, I can not build project due to the following error:
> Classes found in the wrong directory:
> elasticsearch/META-INF/versions/9/org/elasticsearch/monitor/jvm
> I've also tried two options of maven-bundle plugin which are showed bellow:
> With maven hade plugin:
>
> {code:java}
>
> org.apache.maven.plugins
> maven-shade-plugin
> 1.1
>
>
> package
>
> shade
>
>
>
>
>
> org.elasticsearch.client:elasticsearch-rest-high-level-client
> org.elasticsearch:elasticsearch
>
> org.elasticsearch.client:elasticsearch-rest-client
>
>
>
>
>
> org.elasticsearch.client:elasticsearch-rest-high-level-client
>
> **
>
>
>
> org.elasticsearch:elasticsearch
>
> **
>
>
>
>
> org.elasticsearch.client:elasticsearch-rest-client
>
> **
>
>
>
>
> true
> true
>
>
>
>
>
> org.apache.felix
> maven-bundle-plugin
> 4.2.1
> true
>
>
> ${project.artifactId}
> we.retail.core.model*
> *;resolution:=optional
> we.retail.core*
>
> we.retail.core.model
>
>
>
>
> <_removeheaders>Ignore-Package,Include-Resource,Private-Package,Embed-Dependency
>
> true
>
> {code}
>
> Second without maven shade plugin:
>
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
> true
>
>
>
> org.apache.servicemix.bundles.solr-solrj, noggit,
> *elasticsearch*, rank-eval-client, lang-mustache-client,
> httpasyncclient, mapper-extras-client, parent-join-client,
> aggs-matrix-stats-client
>
> true
> OSGI-INF/lib
> we.retail.core.model*
>
> *;resolution:=optional
>
>
> we.retail.core*
>
>
> we.retail.core.model
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> *.impl
>
>
>
> {code}
> Dependencies:
> {code:java}
>
>
> org.elasticsearch.client
> elasticsearch-rest-high-level-client
> 7.4.1
>
>
> org.elasticsearch
> elasticsearch
>
[jira] [Resolved] (FELIX-6235) Disallow DTDs when reading OBR repository files
[ https://issues.apache.org/jira/browse/FELIX-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6235. Assignee: Guillaume Nodet Resolution: Fixed > Disallow DTDs when reading OBR repository files > --- > > Key: FELIX-6235 > URL: https://issues.apache.org/jira/browse/FELIX-6235 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Colm O hEigeartaigh > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Disallow DTDs when reading OBR repository files, as it could lead to security > issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6269) bundle:manifest generates non-reproducible entries in MANIFEST.MF
[
https://issues.apache.org/jira/browse/FELIX-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-6269.
Fix Version/s: maven-bundle-plugin-4.2.2
Resolution: Fixed
> bundle:manifest generates non-reproducible entries in MANIFEST.MF
> -
>
> Key: FELIX-6269
> URL: https://issues.apache.org/jira/browse/FELIX-6269
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.5.0, maven-bundle-plugin-4.2.1
>Reporter: Herve Boutemy
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: maven-bundle-plugin-4.2.2
>
>
> trying to rebuild maven-resolver 1.4.2 release that only uses bundle:manifest
> goal, and already configured
> {{<_removeheaders>Bnd-LastModified}} to avoid some
> reproducibility issues, I still get following differences:
> - with "Built-By: "
> - with "Build-Jdk: "
> - and "Private-Package: ..." value seems not reproducible
> see the result of diffoscope:
> {noformat}$ diffoscope target/reference/maven-resolver-util-1.4.2.jar
> maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> --- target/reference/maven-resolver-util-1.4.2.jar
> +++ maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> [...]
> ├── META-INF/MANIFEST.MF
> │ @@ -1,11 +1,11 @@
> │ Manifest-Version: 1.0
> │ Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt
> │ Bundle-SymbolicName: org.apache.maven.resolver.util
> │ -Built-By: mosipov
> │ +Built-By: herve
> │ Specification-Title: Maven Artifact Resolver Utilities
> │ Implementation-Vendor-Id: org.apache.maven.resolver
> │ Bundle-DocURL: https://maven.apache.org/resolver/maven-resolver-util/
> │ Import-Package: javax.net.ssl,org.eclipse.aether;version="[1.4,2)",org
> │ .eclipse.aether.artifact;version="[1.4,2)",org.eclipse.aether.collect
> │ ion;version="[1.4,2)",org.eclipse.aether.graph;version="[1.4,2)",org.
> │ eclipse.aether.metadata;version="[1.4,2)",org.eclipse.aether.reposito
> │ @@ -44,20 +44,20 @@
> │ Implementation-Version: 1.4.2
> │ Specification-Vendor: The Apache Software Foundation
> │ Bundle-ManifestVersion: 2
> │ Bundle-Vendor: The Apache Software Foundation
> │ Tool: Bnd-3.5.0.201709291849
> │ Implementation-Vendor: The Apache Software Foundation
> │ Bundle-Version: 1.4.2
> │ -Private-Package: org.eclipse.aether.util.artifact,org.eclipse.aether.u
> │ - til,org.eclipse.aether.util.concurrency,org.eclipse.aether.util.filte
> │ - r,org.eclipse.aether.util.graph.manager,org.eclipse.aether.util.graph
> │ - .selector,org.eclipse.aether.util.graph.transformer,org.eclipse.aethe
> │ - r.util.graph.traverser,org.eclipse.aether.util.graph.version,org.ecli
> │ - pse.aether.util.graph.visitor,org.eclipse.aether.util.listener,org.ec
> │ - lipse.aether.util.repository,org.eclipse.aether.util.version
> │ +Private-Package: org.eclipse.aether.util.filter,org.eclipse.aether.uti
> │ + l.repository,org.eclipse.aether.util.artifact,org.eclipse.aether.util
> │ + .listener,org.eclipse.aether.util.version,org.eclipse.aether.util.gra
> │ + ph.transformer,org.eclipse.aether.util.graph.manager,org.eclipse.aeth
> │ + er.util.graph.version,org.eclipse.aether.util.graph.selector,org.ecli
> │ + pse.aether.util.graph.visitor,org.eclipse.aether.util.graph.traverser
> │ + ,org.eclipse.aether.util,org.eclipse.aether.util.concurrency
> │ Created-By: Apache Maven Bundle Plugin
> │ Specification-Version: 1.4.2
> │ -Build-Jdk: 1.8.0_232
> │ +Build-Jdk: 1.8.0_202
> │ Implementation-URL: https://maven.apache.org/resolver/maven-resolver-u
> │ til/{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6269) bundle:manifest generates non-reproducible entries in MANIFEST.MF
[
https://issues.apache.org/jira/browse/FELIX-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104461#comment-17104461
]
Guillaume Nodet commented on FELIX-6269:
I have pushed a patch that reformats the osgi clauses so that the order is
predictable :
[https://github.com/apache/felix-dev/commit/76dba132d4abbab75f20dc5096649842c52e4810]
> bundle:manifest generates non-reproducible entries in MANIFEST.MF
> -
>
> Key: FELIX-6269
> URL: https://issues.apache.org/jira/browse/FELIX-6269
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.5.0, maven-bundle-plugin-4.2.1
>Reporter: Herve Boutemy
>Assignee: Guillaume Nodet
>Priority: Major
>
> trying to rebuild maven-resolver 1.4.2 release that only uses bundle:manifest
> goal, and already configured
> {{<_removeheaders>Bnd-LastModified}} to avoid some
> reproducibility issues, I still get following differences:
> - with "Built-By: "
> - with "Build-Jdk: "
> - and "Private-Package: ..." value seems not reproducible
> see the result of diffoscope:
> {noformat}$ diffoscope target/reference/maven-resolver-util-1.4.2.jar
> maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> --- target/reference/maven-resolver-util-1.4.2.jar
> +++ maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> [...]
> ├── META-INF/MANIFEST.MF
> │ @@ -1,11 +1,11 @@
> │ Manifest-Version: 1.0
> │ Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt
> │ Bundle-SymbolicName: org.apache.maven.resolver.util
> │ -Built-By: mosipov
> │ +Built-By: herve
> │ Specification-Title: Maven Artifact Resolver Utilities
> │ Implementation-Vendor-Id: org.apache.maven.resolver
> │ Bundle-DocURL: https://maven.apache.org/resolver/maven-resolver-util/
> │ Import-Package: javax.net.ssl,org.eclipse.aether;version="[1.4,2)",org
> │ .eclipse.aether.artifact;version="[1.4,2)",org.eclipse.aether.collect
> │ ion;version="[1.4,2)",org.eclipse.aether.graph;version="[1.4,2)",org.
> │ eclipse.aether.metadata;version="[1.4,2)",org.eclipse.aether.reposito
> │ @@ -44,20 +44,20 @@
> │ Implementation-Version: 1.4.2
> │ Specification-Vendor: The Apache Software Foundation
> │ Bundle-ManifestVersion: 2
> │ Bundle-Vendor: The Apache Software Foundation
> │ Tool: Bnd-3.5.0.201709291849
> │ Implementation-Vendor: The Apache Software Foundation
> │ Bundle-Version: 1.4.2
> │ -Private-Package: org.eclipse.aether.util.artifact,org.eclipse.aether.u
> │ - til,org.eclipse.aether.util.concurrency,org.eclipse.aether.util.filte
> │ - r,org.eclipse.aether.util.graph.manager,org.eclipse.aether.util.graph
> │ - .selector,org.eclipse.aether.util.graph.transformer,org.eclipse.aethe
> │ - r.util.graph.traverser,org.eclipse.aether.util.graph.version,org.ecli
> │ - pse.aether.util.graph.visitor,org.eclipse.aether.util.listener,org.ec
> │ - lipse.aether.util.repository,org.eclipse.aether.util.version
> │ +Private-Package: org.eclipse.aether.util.filter,org.eclipse.aether.uti
> │ + l.repository,org.eclipse.aether.util.artifact,org.eclipse.aether.util
> │ + .listener,org.eclipse.aether.util.version,org.eclipse.aether.util.gra
> │ + ph.transformer,org.eclipse.aether.util.graph.manager,org.eclipse.aeth
> │ + er.util.graph.version,org.eclipse.aether.util.graph.selector,org.ecli
> │ + pse.aether.util.graph.visitor,org.eclipse.aether.util.graph.traverser
> │ + ,org.eclipse.aether.util,org.eclipse.aether.util.concurrency
> │ Created-By: Apache Maven Bundle Plugin
> │ Specification-Version: 1.4.2
> │ -Build-Jdk: 1.8.0_232
> │ +Build-Jdk: 1.8.0_202
> │ Implementation-URL: https://maven.apache.org/resolver/maven-resolver-u
> │ til/{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6269) bundle:manifest generates non-reproducible entries in MANIFEST.MF
[
https://issues.apache.org/jira/browse/FELIX-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098993#comment-17098993
]
Guillaume Nodet commented on FELIX-6269:
I've upgraded the plugin the maven-archiver 3.5.0 to get rid of the
{{Built-By}} and {{Build-Jdk}} headers, see
https://github.com/apache/felix-dev/commit/3c491299920b5e450edf0a0fb47fcb56837c1200
> bundle:manifest generates non-reproducible entries in MANIFEST.MF
> -
>
> Key: FELIX-6269
> URL: https://issues.apache.org/jira/browse/FELIX-6269
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.5.0, maven-bundle-plugin-4.2.1
>Reporter: Herve Boutemy
>Priority: Major
>
> trying to rebuild maven-resolver 1.4.2 release that only uses bundle:manifest
> goal, and already configured
> {{<_removeheaders>Bnd-LastModified}} to avoid some
> reproducibility issues, I still get following differences:
> - with "Built-By: "
> - with "Build-Jdk: "
> - and "Private-Package: ..." value seems not reproducible
> see the result of diffoscope:
> {noformat}$ diffoscope target/reference/maven-resolver-util-1.4.2.jar
> maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> --- target/reference/maven-resolver-util-1.4.2.jar
> +++ maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> [...]
> ├── META-INF/MANIFEST.MF
> │ @@ -1,11 +1,11 @@
> │ Manifest-Version: 1.0
> │ Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt
> │ Bundle-SymbolicName: org.apache.maven.resolver.util
> │ -Built-By: mosipov
> │ +Built-By: herve
> │ Specification-Title: Maven Artifact Resolver Utilities
> │ Implementation-Vendor-Id: org.apache.maven.resolver
> │ Bundle-DocURL: https://maven.apache.org/resolver/maven-resolver-util/
> │ Import-Package: javax.net.ssl,org.eclipse.aether;version="[1.4,2)",org
> │ .eclipse.aether.artifact;version="[1.4,2)",org.eclipse.aether.collect
> │ ion;version="[1.4,2)",org.eclipse.aether.graph;version="[1.4,2)",org.
> │ eclipse.aether.metadata;version="[1.4,2)",org.eclipse.aether.reposito
> │ @@ -44,20 +44,20 @@
> │ Implementation-Version: 1.4.2
> │ Specification-Vendor: The Apache Software Foundation
> │ Bundle-ManifestVersion: 2
> │ Bundle-Vendor: The Apache Software Foundation
> │ Tool: Bnd-3.5.0.201709291849
> │ Implementation-Vendor: The Apache Software Foundation
> │ Bundle-Version: 1.4.2
> │ -Private-Package: org.eclipse.aether.util.artifact,org.eclipse.aether.u
> │ - til,org.eclipse.aether.util.concurrency,org.eclipse.aether.util.filte
> │ - r,org.eclipse.aether.util.graph.manager,org.eclipse.aether.util.graph
> │ - .selector,org.eclipse.aether.util.graph.transformer,org.eclipse.aethe
> │ - r.util.graph.traverser,org.eclipse.aether.util.graph.version,org.ecli
> │ - pse.aether.util.graph.visitor,org.eclipse.aether.util.listener,org.ec
> │ - lipse.aether.util.repository,org.eclipse.aether.util.version
> │ +Private-Package: org.eclipse.aether.util.filter,org.eclipse.aether.uti
> │ + l.repository,org.eclipse.aether.util.artifact,org.eclipse.aether.util
> │ + .listener,org.eclipse.aether.util.version,org.eclipse.aether.util.gra
> │ + ph.transformer,org.eclipse.aether.util.graph.manager,org.eclipse.aeth
> │ + er.util.graph.version,org.eclipse.aether.util.graph.selector,org.ecli
> │ + pse.aether.util.graph.visitor,org.eclipse.aether.util.graph.traverser
> │ + ,org.eclipse.aether.util,org.eclipse.aether.util.concurrency
> │ Created-By: Apache Maven Bundle Plugin
> │ Specification-Version: 1.4.2
> │ -Build-Jdk: 1.8.0_232
> │ +Build-Jdk: 1.8.0_202
> │ Implementation-URL: https://maven.apache.org/resolver/maven-resolver-u
> │ til/{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6269) bundle:manifest generates non-reproducible entries in MANIFEST.MF
[
https://issues.apache.org/jira/browse/FELIX-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-6269:
--
Assignee: Guillaume Nodet
> bundle:manifest generates non-reproducible entries in MANIFEST.MF
> -
>
> Key: FELIX-6269
> URL: https://issues.apache.org/jira/browse/FELIX-6269
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.5.0, maven-bundle-plugin-4.2.1
>Reporter: Herve Boutemy
>Assignee: Guillaume Nodet
>Priority: Major
>
> trying to rebuild maven-resolver 1.4.2 release that only uses bundle:manifest
> goal, and already configured
> {{<_removeheaders>Bnd-LastModified}} to avoid some
> reproducibility issues, I still get following differences:
> - with "Built-By: "
> - with "Build-Jdk: "
> - and "Private-Package: ..." value seems not reproducible
> see the result of diffoscope:
> {noformat}$ diffoscope target/reference/maven-resolver-util-1.4.2.jar
> maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> --- target/reference/maven-resolver-util-1.4.2.jar
> +++ maven-resolver-util/target/maven-resolver-util-1.4.2.jar
> [...]
> ├── META-INF/MANIFEST.MF
> │ @@ -1,11 +1,11 @@
> │ Manifest-Version: 1.0
> │ Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt
> │ Bundle-SymbolicName: org.apache.maven.resolver.util
> │ -Built-By: mosipov
> │ +Built-By: herve
> │ Specification-Title: Maven Artifact Resolver Utilities
> │ Implementation-Vendor-Id: org.apache.maven.resolver
> │ Bundle-DocURL: https://maven.apache.org/resolver/maven-resolver-util/
> │ Import-Package: javax.net.ssl,org.eclipse.aether;version="[1.4,2)",org
> │ .eclipse.aether.artifact;version="[1.4,2)",org.eclipse.aether.collect
> │ ion;version="[1.4,2)",org.eclipse.aether.graph;version="[1.4,2)",org.
> │ eclipse.aether.metadata;version="[1.4,2)",org.eclipse.aether.reposito
> │ @@ -44,20 +44,20 @@
> │ Implementation-Version: 1.4.2
> │ Specification-Vendor: The Apache Software Foundation
> │ Bundle-ManifestVersion: 2
> │ Bundle-Vendor: The Apache Software Foundation
> │ Tool: Bnd-3.5.0.201709291849
> │ Implementation-Vendor: The Apache Software Foundation
> │ Bundle-Version: 1.4.2
> │ -Private-Package: org.eclipse.aether.util.artifact,org.eclipse.aether.u
> │ - til,org.eclipse.aether.util.concurrency,org.eclipse.aether.util.filte
> │ - r,org.eclipse.aether.util.graph.manager,org.eclipse.aether.util.graph
> │ - .selector,org.eclipse.aether.util.graph.transformer,org.eclipse.aethe
> │ - r.util.graph.traverser,org.eclipse.aether.util.graph.version,org.ecli
> │ - pse.aether.util.graph.visitor,org.eclipse.aether.util.listener,org.ec
> │ - lipse.aether.util.repository,org.eclipse.aether.util.version
> │ +Private-Package: org.eclipse.aether.util.filter,org.eclipse.aether.uti
> │ + l.repository,org.eclipse.aether.util.artifact,org.eclipse.aether.util
> │ + .listener,org.eclipse.aether.util.version,org.eclipse.aether.util.gra
> │ + ph.transformer,org.eclipse.aether.util.graph.manager,org.eclipse.aeth
> │ + er.util.graph.version,org.eclipse.aether.util.graph.selector,org.ecli
> │ + pse.aether.util.graph.visitor,org.eclipse.aether.util.graph.traverser
> │ + ,org.eclipse.aether.util,org.eclipse.aether.util.concurrency
> │ Created-By: Apache Maven Bundle Plugin
> │ Specification-Version: 1.4.2
> │ -Build-Jdk: 1.8.0_232
> │ +Build-Jdk: 1.8.0_202
> │ Implementation-URL: https://maven.apache.org/resolver/maven-resolver-u
> │ til/{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6203) Make bundleplugin pom.proterties reproducible
[ https://issues.apache.org/jira/browse/FELIX-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6203. Fix Version/s: maven-bundle-plugin-4.2.2 Assignee: Guillaume Nodet Resolution: Fixed > Make bundleplugin pom.proterties reproducible > - > > Key: FELIX-6203 > URL: https://issues.apache.org/jira/browse/FELIX-6203 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Bernhard M. Wiedemann > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.2 > > Time Spent: 10m > Remaining Estimate: 0h > > For reproducible builds, we want to be able to produce the same results from > the same inputs. > However the pom.properties file generted by maven-plugin-bundle varied across > builds, because it contains a timestamp. > [https://github.com/apache/felix/pull/209] fixes this for us. > The alternative approach would be to drop the timestamp, if it is not needed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6203) Make bundleplugin pom.proterties reproducible
[ https://issues.apache.org/jira/browse/FELIX-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088377#comment-17088377 ] Guillaume Nodet commented on FELIX-6203: [~markov] I can't find any PR > Make bundleplugin pom.proterties reproducible > - > > Key: FELIX-6203 > URL: https://issues.apache.org/jira/browse/FELIX-6203 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Bernhard M. Wiedemann >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For reproducible builds, we want to be able to produce the same results from > the same inputs. > However the pom.properties file generted by maven-plugin-bundle varied across > builds, because it contains a timestamp. > [https://github.com/apache/felix/pull/209] fixes this for us. > The alternative approach would be to drop the timestamp, if it is not needed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release FileInstall 3.6.6
Closing this vote with 9 +1s and no other votes. I'll publish the release asap. Le mer. 1 avr. 2020 à 15:34, Guillaume Nodet a écrit : > I'm calling a vote to release the following 4 bugs in FileInstall: > * [FELIX-5832] - ConfigInstaller should only handle events for > configurations it manages > * [FELIX-6103] - ConfigInstaller, when using > NotCachablePersistenceManager, can restore cached stale properties > * [FELIX-6109] - NPE from null listener in > DirectoryWatcher.findListener > * [FELIX-6211] - fileinstall filter out subdirectories even though > felix.fileinstall.subdir.mode property is set to 'recurse' > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1326/ > > > You can use this UNIX script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1326 /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. > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release FileInstall 3.6.6
+1 Le mer. 1 avr. 2020 à 15:34, Guillaume Nodet a écrit : > I'm calling a vote to release the following 4 bugs in FileInstall: > * [FELIX-5832] - ConfigInstaller should only handle events for > configurations it manages > * [FELIX-6103] - ConfigInstaller, when using > NotCachablePersistenceManager, can restore cached stale properties > * [FELIX-6109] - NPE from null listener in > DirectoryWatcher.findListener > * [FELIX-6211] - fileinstall filter out subdirectories even though > felix.fileinstall.subdir.mode property is set to 'recurse' > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1326/ > > > You can use this UNIX script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1326 /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. > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Apache Felix Gogo Parent 6 & Gogo JLine 1.1.6 releases
+1 Le dim. 5 avr. 2020 à 07:54, Jean-Baptiste Onofre a écrit : > Hi everyone, > > I’m calling a vote to release Gogo Parent 6 (just to update scm section) > and Gogo JLine 1.1.6 containing: > > * [FELIX-6214] - Gogo JLine range import/upgrade > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1328/ < > https://repository.apache.org/content/repositories/orgapachefelix-1328/> > > Please vote to approve this release: > > [ ] + 1 Approve the release > [ ] -1 Don’t approve the release (please provide specific comments) > > This vote will be open for 72 hours. > > Regards > JB -- Guillaume Nodet
[VOTE] Release FileInstall 3.6.6
I'm calling a vote to release the following 4 bugs in FileInstall: * [FELIX-5832] - ConfigInstaller should only handle events for configurations it manages * [FELIX-6103] - ConfigInstaller, when using NotCachablePersistenceManager, can restore cached stale properties * [FELIX-6109] - NPE from null listener in DirectoryWatcher.findListener * [FELIX-6211] - fileinstall filter out subdirectories even though felix.fileinstall.subdir.mode property is set to 'recurse' Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1326/ You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1326 /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. -- ---- Guillaume Nodet
[jira] [Updated] (FELIX-6145) Avoid escaping when no property is involved
[
https://issues.apache.org/jira/browse/FELIX-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-6145:
---
Fix Version/s: (was: fileinstall-3.6.6)
fileinstall-3.7.0
> Avoid escaping when no property is involved
> ---
>
> Key: FELIX-6145
> URL: https://issues.apache.org/jira/browse/FELIX-6145
> Project: Felix
> Issue Type: Improvement
> Components: File Install
>Reporter: Mariano Alvaro
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: fileinstall-3.7.0
>
> Attachments: diffs.txt
>
>
> Due to FELIX-2366 escape character ('\') is removed in order to be able to
> escape properties. However when what's escaped is something not related to a
> property, like a literal 's\{0,2}' the escape character gets also removed.
> For example, in the previous case:
> a=s\{0,2}
> The same value should be expected for a, but 's\{0,2}' is obtained.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-5986) FielInstall logs ClosedWatchServiceException on Windows
[
https://issues.apache.org/jira/browse/FELIX-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-5986:
---
Description:
The following exception stack appears repeatedly/continuously in the log file.
The effect seems to be that temporary bundles starting with C__ that are
associated with directories within a recursive directory scan remain.after
startup.
This is relatively recent behavior that seems to have resulted from a reinstall
of 4.2.1.
{code}
2018-11-21T09:05:29,288 | ERROR | fileinstall-C:/BAM | fileinstall | 10 -
org.apache.felix.fileinstall - 3.6.4 | In main loop, we have serious trouble
java.nio.file.ClosedWatchServiceException: null
at sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80)
~[?:?]
at sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
at
org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163)
~[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
~[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
[10:org.apache.felix.fileinstall:3.6.4]
{code}
was:
The following exception stack appears repeatedly/continuously in the log file.
The effect seems to be that temporary bundles starting with C__ that are
associated with directories within a recursive directory scan remain.after
startup.
This is relatively recent behavior that seems to have resulted from a reinstall
of 4.2.1.
2018-11-21T09:05:29,288 | ERROR | fileinstall-C:/BAM | fileinstall | 10 -
org.apache.felix.fileinstall - 3.6.4 | In main loop, we have serious trouble
java.nio.file.ClosedWatchServiceException: null
at sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80)
~[?:?]
at sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
at
org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163)
~[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
~[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
[10:org.apache.felix.fileinstall:3.6.4]
> FielInstall logs ClosedWatchServiceException on Windows
> ---
>
> Key: FELIX-5986
> URL: https://issues.apache.org/jira/browse/FELIX-5986
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: Scott Leschke
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: windows
>
> The following exception stack appears repeatedly/continuously in the log
> file. The effect seems to be that temporary bundles starting with C__ that
> are associated with directories within a recursive directory scan
> remain.after startup.
> This is relatively recent behavior that seems to have resulted from a
> reinstall of 4.2.1.
> {code}
> 2018-11-21T09:05:29,288 | ERROR | fileinstall-C:/BAM | fileinstall | 10 -
> org.apache.felix.fileinstall - 3.6.4 | In main loop, we have serious trouble
> java.nio.file.ClosedWatchServiceException: null
> at sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80)
> ~[?:?]
> at sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
> at
> org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163)
> ~[10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
> ~[10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6145) Avoid escaping when no property is involved
[
https://issues.apache.org/jira/browse/FELIX-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-6145:
---
Issue Type: Improvement (was: Bug)
> Avoid escaping when no property is involved
> ---
>
> Key: FELIX-6145
> URL: https://issues.apache.org/jira/browse/FELIX-6145
> Project: Felix
> Issue Type: Improvement
> Components: File Install
>Reporter: Mariano Alvaro
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: fileinstall-3.6.6
>
> Attachments: diffs.txt
>
>
> Due to FELIX-2366 escape character ('\') is removed in order to be able to
> escape properties. However when what's escaped is something not related to a
> property, like a literal 's\{0,2}' the escape character gets also removed.
> For example, in the previous case:
> a=s\{0,2}
> The same value should be expected for a, but 's\{0,2}' is obtained.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (FELIX-6109) NPE from null listener in DirectoryWatcher.findListener
[
https://issues.apache.org/jira/browse/FELIX-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-6109.
Resolution: Fixed
> NPE from null listener in DirectoryWatcher.findListener
> ---
>
> Key: FELIX-6109
> URL: https://issues.apache.org/jira/browse/FELIX-6109
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.6.4
>Reporter: Stephen Marquard
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: fileinstall-3.6.6
>
>
> This error shows up intermittently in an OSGI application:
>
> {code}
> *ERROR* [org.osgi.service.cm.ManagedServiceFactory, id=13,
> bundle=6/file:/opt/ls/bundles/system/org.apache.felix.fileinstall-3.6.4.jar]:
> Unexpected problem updating configuration
> org.apache.felix.fileinstall.06a753e4-56fc-42fa-8a5b-c2b0b374581f
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.findListener(DirectoryWatcher.java:533)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:460)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:247)
> at
> org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:254)
> at
> org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:378)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1400)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> The NPE seems to imply that there is a null listener in the list of
> listeners here:
>
> {code:java}
> ArtifactListener findListener(File artifact, List
> listeners)
> {
> for (ArtifactListener listener : listeners) {
> if (listener.canHandle(artifact)) {
> return listener;
> }
> }
> return null;
> {code}
>
> I don't know how that situation arises (some type of race condition, given
> that it's unpredictable), but seems like it should be easy enough to check
> for and ignore.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FELIX-6109) NPE from null listener in DirectoryWatcher.findListener
[
https://issues.apache.org/jira/browse/FELIX-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned FELIX-6109:
--
Assignee: Guillaume Nodet (was: Jean-Baptiste Onofré)
> NPE from null listener in DirectoryWatcher.findListener
> ---
>
> Key: FELIX-6109
> URL: https://issues.apache.org/jira/browse/FELIX-6109
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.6.4
>Reporter: Stephen Marquard
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: fileinstall-3.6.6
>
>
> This error shows up intermittently in an OSGI application:
>
> {code}
> *ERROR* [org.osgi.service.cm.ManagedServiceFactory, id=13,
> bundle=6/file:/opt/ls/bundles/system/org.apache.felix.fileinstall-3.6.4.jar]:
> Unexpected problem updating configuration
> org.apache.felix.fileinstall.06a753e4-56fc-42fa-8a5b-c2b0b374581f
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.findListener(DirectoryWatcher.java:533)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:460)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:247)
> at
> org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:254)
> at
> org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:378)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
> at
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
> at
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1400)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> The NPE seems to imply that there is a null listener in the list of
> listeners here:
>
> {code:java}
> ArtifactListener findListener(File artifact, List
> listeners)
> {
> for (ArtifactListener listener : listeners) {
> if (listener.canHandle(artifact)) {
> return listener;
> }
> }
> return null;
> {code}
>
> I don't know how that situation arises (some type of race condition, given
> that it's unpredictable), but seems like it should be easy enough to check
> for and ignore.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6109) NPE from null listener in DirectoryWatcher.findListener
[
https://issues.apache.org/jira/browse/FELIX-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-6109:
---
Description:
This error shows up intermittently in an OSGI application:
{code}
*ERROR* [org.osgi.service.cm.ManagedServiceFactory, id=13,
bundle=6/file:/opt/ls/bundles/system/org.apache.felix.fileinstall-3.6.4.jar]:
Unexpected problem updating configuration
org.apache.felix.fileinstall.06a753e4-56fc-42fa-8a5b-c2b0b374581f
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.findListener(DirectoryWatcher.java:533)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:460)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:247)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:254)
at
org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:378)
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1400)
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105)
at java.lang.Thread.run(Thread.java:748)
{code}
The NPE seems to imply that there is a null listener in the list of listeners
here:
{code:java}
ArtifactListener findListener(File artifact, List listeners)
{
for (ArtifactListener listener : listeners) {
if (listener.canHandle(artifact)) {
return listener;
}
}
return null;
{code}
I don't know how that situation arises (some type of race condition, given that
it's unpredictable), but seems like it should be easy enough to check for and
ignore.
was:
This error shows up intermittently in an OSGI application:
*ERROR* [org.osgi.service.cm.ManagedServiceFactory, id=13,
bundle=6/file:/opt/ls/bundles/system/org.apache.felix.fileinstall-3.6.4.jar]:
Unexpected problem updating configuration
org.apache.felix.fileinstall.06a753e4-56fc-42fa-8a5b-c2b0b374581f
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.findListener(DirectoryWatcher.java:533)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:460)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:247)
at
org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:254)
at
org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:378)
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
at
org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
at
org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1400)
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105)
at java.lang.Thread.run(Thread.java:748)
The NPE seems to imply that there is a null listener in the list of listeners
here:
{code:java}
ArtifactListener findListener(File artifact, List listeners)
{
for (ArtifactListener listener : listeners) {
if (listener.canHandle(artifact)) {
return listener;
}
}
return null;
{code}
I don't know how that situation arises (some type of race condition, given that
it's unpredictable), but seems like it should be easy enough to check for and
ignore.
> NPE from null listener in DirectoryWatcher.findListener
> ---
>
> Key: FELIX-6109
> URL: https://issues.apache.org/jira/browse/FELIX-6109
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-3.6.4
>Reporter: Stephen Marquard
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: fileinstall-3.6.6
>
>
> This error shows up intermittently in an OSGI application:
>
> {code}
> *ERROR* [org.osgi.service.cm.ManagedServiceFactory, id=13,
> bundle=6/file:/opt/ls/bundle
[jira] [Commented] (FELIX-6236) ssh / telnet gogojline
[ https://issues.apache.org/jira/browse/FELIX-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052178#comment-17052178 ] Guillaume Nodet commented on FELIX-6236: The main classes to support telnet / ssh have been moved to jline in the [jline-remote-ssh]([https://github.com/jline/jline3/tree/master/remote-ssh]) and [jline-remote-telnet]([https://github.com/jline/jline3/tree/master/remote-telnet]) with the help of [jline-builtins]([https://github.com/jline/jline3/tree/master/builtins]) modules as they much more tied to jline than gogo. The required gogo definitions can be defined in a script if needed, see [https://github.com/jline/jline3/blob/master/demo/etc/gosh_profile#L119-L144] > ssh / telnet gogojline > -- > > Key: FELIX-6236 > URL: https://issues.apache.org/jira/browse/FELIX-6236 > Project: Felix > Issue Type: New Feature > Components: Gogo JLine >Reporter: Stefan Bischof >Priority: Major > > It would be nice to have ssh and telnet support for gogo-jline > With this commit the ssh / telnet support of gogo jline moved from /src to > /test > > [https://github.com/apache/felix-dev/commit/ad2d6481f58126130aefb01cdcf7b11eacb1c567] > What are the reasons? Could we add the support back? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FELIX-5743) Allow environment variable substitution in fileinstall
[
https://issues.apache.org/jira/browse/FELIX-5743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed FELIX-5743.
--
Assignee: Guillaume Nodet (was: Jean-Baptiste Onofré)
Resolution: Duplicate
> Allow environment variable substitution in fileinstall
> --
>
> Key: FELIX-5743
> URL: https://issues.apache.org/jira/browse/FELIX-5743
> Project: Felix
> Issue Type: Improvement
> Components: File Install
>Reporter: Christoph Läubrich
> Assignee: Guillaume Nodet
>Priority: Major
>
> It is already possible to substitute System.Properties with
> ${systemproperty}, it would be cool to allow the same for env-variables, eg.
> like this ${ENV:env variable}, this would make it more easy to use e.g.
> docker that uses envs for parameterize a run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6211) fileinstall filter out subdirectories even though felix.fileinstall.subdir.mode property is set to 'recurse'
[ https://issues.apache.org/jira/browse/FELIX-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015129#comment-17015129 ] Guillaume Nodet commented on FELIX-6211: [~ldemasi] thx for the patch ! > fileinstall filter out subdirectories even though > felix.fileinstall.subdir.mode property is set to 'recurse' > - > > Key: FELIX-6211 > URL: https://issues.apache.org/jira/browse/FELIX-6211 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.5.6 >Reporter: Luigi De Masi >Assignee: Guillaume Nodet >Priority: Major > Fix For: fileinstall-3.6.6 > > > when felix.fileinstall.subdir.mode is set to 'recurse' and the > felix.fileinstall.filter is enabled, > filter is applied also to subdirectory making recurse mode uneffective. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-6211) fileinstall filter out subdirectories even though felix.fileinstall.subdir.mode property is set to 'recurse'
[ https://issues.apache.org/jira/browse/FELIX-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6211. Fix Version/s: fileinstall-3.6.6 Resolution: Fixed Committing to https://svn.apache.org/repos/asf/felix/trunk ... A fileinstall/src/test/java/org/apache/felix/fileinstall/internal/ScannerSubDirTest.java M fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Scanner.java Committed r1872782 > fileinstall filter out subdirectories even though > felix.fileinstall.subdir.mode property is set to 'recurse' > - > > Key: FELIX-6211 > URL: https://issues.apache.org/jira/browse/FELIX-6211 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.5.6 >Reporter: Luigi De Masi >Assignee: Guillaume Nodet >Priority: Major > Fix For: fileinstall-3.6.6 > > > when felix.fileinstall.subdir.mode is set to 'recurse' and the > felix.fileinstall.filter is enabled, > filter is applied also to subdirectory making recurse mode uneffective. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FELIX-6211) fileinstall filter out subdirectories even though felix.fileinstall.subdir.mode property is set to 'recurse'
[ https://issues.apache.org/jira/browse/FELIX-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-6211: -- Assignee: Guillaume Nodet > fileinstall filter out subdirectories even though > felix.fileinstall.subdir.mode property is set to 'recurse' > - > > Key: FELIX-6211 > URL: https://issues.apache.org/jira/browse/FELIX-6211 > Project: Felix > Issue Type: Bug > Components: File Install >Affects Versions: fileinstall-3.5.6 >Reporter: Luigi De Masi >Assignee: Guillaume Nodet >Priority: Major > > when felix.fileinstall.subdir.mode is set to 'recurse' and the > felix.fileinstall.filter is enabled, > filter is applied also to subdirectory making recurse mode uneffective. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Move Felix to git(box)
+1 Le mar. 19 nov. 2019 à 10:11, Karl Pauls a écrit : > Following up on the discussion about moving Felix to git I'd like to > call for a vote now. > > The idea is to ask Infra to move the current svn to gitbox > (https://gitbox.apache.org) which will give us a two-master setup of > git repositories, allowing committers to utilize two different avenues > of committing code; through GitHub or through the ASF (gitbox) - > including the ability to work with pull requests on github directly. > > Please vote to approve this move: > > [ ] +1 Move source control to gitbox > [ ] 0 Don't care > [ ] -1 Don't, because ... > -- Guillaume Nodet
[jira] [Closed] (FELIX-6187) Avoid overwriting the manifest if it has not changed
[ https://issues.apache.org/jira/browse/FELIX-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed FELIX-6187. -- Resolution: Fixed > Avoid overwriting the manifest if it has not changed > > > Key: FELIX-6187 > URL: https://issues.apache.org/jira/browse/FELIX-6187 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-4.2.0 > Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Minor > Fix For: maven-bundle-plugin-4.2.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FELIX-2322) Configurable JAR compression level
[
https://issues.apache.org/jira/browse/FELIX-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16974111#comment-16974111
]
Guillaume Nodet edited comment on FELIX-2322 at 11/18/19 12:55 PM:
---
The bundle plugin does not reuse the {{maven-archiver}}. Actually, the writing
of the jar is done by {{bnd}} which supports storing/compressing the jar, but
does not allow the compression level to be configured:
[https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/osgi/Jar.java#L519-L528]
was (Author: gnt):
The bundle plugin does not reuse the `maven-archiver`. Actually, the writing
of the jar is done by `bnd` which supports storing/compressing the jar, but
does not allow the compression level to be configured:
[https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/osgi/Jar.java#L519-L528]
> Configurable JAR compression level
> --
>
> Key: FELIX-2322
> URL: https://issues.apache.org/jira/browse/FELIX-2322
> Project: Felix
> Issue Type: New Feature
> Components: Maven Bundle Plugin
>Reporter: Trustin Lee
>Priority: Major
> Fix For: maven-bundle-plugin-future
>
>
> It seems like there is no way to specify the compression level of the bundle
> JAR file generated by maven-bundle-plugin. To reduce the bandwidth, I'd like
> to compress the JAR as much as possible. It would be nice if there is a
> configurable property in the plugin's section in the pom.xml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6203) Make bundleplugin pom.proterties reproducible
[ https://issues.apache.org/jira/browse/FELIX-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-6203: --- Component/s: Maven Bundle Plugin > Make bundleplugin pom.proterties reproducible > - > > Key: FELIX-6203 > URL: https://issues.apache.org/jira/browse/FELIX-6203 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Bernhard M. Wiedemann >Priority: Major > > For reproducible builds, we want to be able to produce the same results from > the same inputs. > However the pom.properties file generted by maven-plugin-bundle varied across > builds, because it contains a timestamp. > [https://github.com/apache/felix/pull/209] fixes this for us. > The alternative approach would be to drop the timestamp, if it is not needed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (FELIX-6203) Make bundleplugin pom.proterties reproducible
[
https://issues.apache.org/jira/browse/FELIX-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976509#comment-16976509
]
Guillaume Nodet edited comment on FELIX-6203 at 11/18/19 12:51 PM:
---
I think it may be preferable to use a plugin configuration property and have it
default to {{${env.SOURCE_DATE_EPOCH}}} instead of referring to the environment
variable in the code directly.
was (Author: gnt):
I think it may be preferable to use a plugin configuration property and have it
default to `${env.SOURCE_DATE_EPOCH}` instead of referring to the environment
variable in the code directly.
> Make bundleplugin pom.proterties reproducible
> -
>
> Key: FELIX-6203
> URL: https://issues.apache.org/jira/browse/FELIX-6203
> Project: Felix
> Issue Type: Improvement
>Reporter: Bernhard M. Wiedemann
>Priority: Major
>
> For reproducible builds, we want to be able to produce the same results from
> the same inputs.
> However the pom.properties file generted by maven-plugin-bundle varied across
> builds, because it contains a timestamp.
> [https://github.com/apache/felix/pull/209] fixes this for us.
> The alternative approach would be to drop the timestamp, if it is not needed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6203) Make bundleplugin pom.proterties reproducible
[
https://issues.apache.org/jira/browse/FELIX-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976509#comment-16976509
]
Guillaume Nodet commented on FELIX-6203:
I think it may be preferable to use a plugin configuration property and have it
default to `${env.SOURCE_DATE_EPOCH}` instead of referring to the environment
variable in the code directly.
> Make bundleplugin pom.proterties reproducible
> -
>
> Key: FELIX-6203
> URL: https://issues.apache.org/jira/browse/FELIX-6203
> Project: Felix
> Issue Type: Improvement
>Reporter: Bernhard M. Wiedemann
>Priority: Major
>
> For reproducible builds, we want to be able to produce the same results from
> the same inputs.
> However the pom.properties file generted by maven-plugin-bundle varied across
> builds, because it contains a timestamp.
> [https://github.com/apache/felix/pull/209] fixes this for us.
> The alternative approach would be to drop the timestamp, if it is not needed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-5280) transitive dependencies get ignored when building jar
[ https://issues.apache.org/jira/browse/FELIX-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-5280: --- Description: We have the following situation: * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the instruction to embed projects with scope=(compile|runtime) * we have project A having the Maven bundle plugin and following dependency tree to other projects: ** Project B [scope Compile] *** Project X [scope Compile] ** Project C [scope Test] *** Project X [scope Compile] Expectation: * when building a jar for the main code, the content of Project X gets embedded. (No matter whether it is included by test scope additionally to the scope compile) Actual: * As long as there is a transitive dependency to Project X with Test scope, the project is not embedded. Other observations: * Direct dependencies are always included * if in project C an exclusion to project X would be added, then the jar for project A would contain X as there are no test dependencies to it This happens since version 3.0.0 so we have to downgrade the maven plugin version to 2.5.4 (and thus miss other important features) just to make the transitive dependency work. We would be very thankful to know a rough estimation when we can expect an release that fixes this issue. was: We have the following situation: * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the instruction to embed projects with scope=(compile|runtime) * we have project A having the Maven bundle plugin and following dependency tree to other projects: ** Project B [scope Compile] *** Project X [scope Compile] ** Project C [scope Test] *** Project X [scope Compile] Expectation: * when building a jar for the main code, the content of Project X gets embedded. (No matter whether it is included by test scope additionally to the scope compile) Actual: * As long as there is a transitive dependency to Project X with Test scope, the project is not embedded. Other observations: * Direct dependencies are always included * if in project C an exclusion to project X would be added, then the jar for project A would contain X as there are no test dependencies to it This happens since version 3.0.0 so we have to downgrade the maven plugin version to 2.5.4 (and thus miss other important features) just to make the transitive dependency work. We would be very thankful to know a rough estimation when we can expect an release that fixes this issue. > transitive dependencies get ignored when building jar > - > > Key: FELIX-5280 > URL: https://issues.apache.org/jira/browse/FELIX-5280 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.0.0, maven-bundle-plugin-3.0.1 > Environment: Windows 7 > Maven 3.3.3 > JRE ORACLE 1.7.0_45 >Reporter: Michael Krein >Priority: Critical > Labels: bug, maven > Original Estimate: 8h > Remaining Estimate: 8h > > We have the following situation: > * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the > instruction to embed projects with scope=(compile|runtime) > * we have project A having the Maven bundle plugin and following dependency > tree to other projects: > ** Project B [scope Compile] > *** Project X [scope Compile] > ** Project C [scope Test] > *** Project X [scope Compile] > Expectation: > * when building a jar for the main code, the content of Project X gets > embedded. (No matter whether it is included by test scope additionally to the > scope compile) > Actual: > * As long as there is a transitive dependency to Project X with Test scope, > the project is not embedded. > Other observations: > * Direct dependencies are always included > * if in project C an exclusion to project X would be added, then the jar for > project A would contain X as there are no test dependencies to it > This happens since version 3.0.0 so we have to downgrade the maven plugin > version to 2.5.4 (and thus miss other important features) just to make the > transitive dependency work. > We would be very thankful to know a rough estimation when we can expect an > release that fixes this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-5280) transitive dependencies get ignored when building jar
[ https://issues.apache.org/jira/browse/FELIX-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-5280: --- Description: We have the following situation: * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the instruction to embed projects with scope=(compile|runtime) * we have project A having the Maven bundle plugin and following dependency tree to other projects: ** Project B [scope Compile] *** Project X [scope Compile] ** Project C [scope Test] *** Project X [scope Compile] Expectation: * when building a jar for the main code, the content of Project X gets embedded. (No matter whether it is included by test scope additionally to the scope compile) Actual: * As long as there is a transitive dependency to Project X with Test scope, the project is not embedded. Other observations: * Direct dependencies are always included * if in project C an exclusion to project X would be added, then the jar for project A would contain X as there are no test dependencies to it This happens since version 3.0.0 so we have to downgrade the maven plugin version to 2.5.4 (and thus miss other important features) just to make the transitive dependency work. We would be very thankful to know a rough estimation when we can expect an release that fixes this issue. was: We have the following situation: * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the instruction to embed projects with scope=(compile|runtime) * we have project A having the Maven bundle plugin and following dependency tree to other projects: ** Project B [scope Compile] *** Project X [scope Compile] ** Project C [scope Test] *** Project X [scope Compile] Expectation: * when building a jar for the main code, the content of Project X gets embedded. (No matter whether it is included by test scope additionally to the scope compile) Actual: * As long as there is a transitive dependency to Project X with Test scope, the project is not embedded. Other observations: * Direct dependencies are always included * if in project C an exclusion to project X would be added, then the jar for project A would contain X as there are no test dependencies to it This happens since version 3.0.0 so we have to downgrade the maven plugin version to 2.5.4 (and thus miss other important features) just to make the transitive dependency work. We would be very thankful to know a rough estimation when we can expect an release that fixes this issue. > transitive dependencies get ignored when building jar > - > > Key: FELIX-5280 > URL: https://issues.apache.org/jira/browse/FELIX-5280 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.0.0, maven-bundle-plugin-3.0.1 > Environment: Windows 7 > Maven 3.3.3 > JRE ORACLE 1.7.0_45 >Reporter: Michael Krein >Priority: Critical > Labels: bug, maven > Original Estimate: 8h > Remaining Estimate: 8h > > We have the following situation: > * Maven bundle plugin has version 3.0.1 (or 3.0.0) and contains the > instruction to embed projects with scope=(compile|runtime) > * we have project A having the Maven bundle plugin and following dependency > tree to other projects: > ** Project B [scope Compile] > *** Project X [scope Compile] > ** Project C [scope Test] > *** Project X [scope Compile] > Expectation: > * when building a jar for the main code, the content of Project X gets > embedded. (No matter whether it is included by test scope additionally to the > scope compile) > Actual: > * As long as there is a transitive dependency to Project X with Test scope, > the project is not embedded. > Other observations: > * Direct dependencies are always included > * if in project C an exclusion to project X would be added, then the jar for > project A would contain X as there are no test dependencies to it > This happens since version 3.0.0 so we have to downgrade the maven plugin > version to 2.5.4 (and thus miss other important features) just to make the > transitive dependency work. > We would be very thankful to know a rough estimation when we can expect an > release that fixes this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-5980) Maven Bundle Plugin Regression: incorrect filtering
[
https://issues.apache.org/jira/browse/FELIX-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5980.
Assignee: Guillaume Nodet
Resolution: Cannot Reproduce
I've tried to reproduce the issue but was unsuccessful. The project you've
attached works fine for me, whatever version of the maven bundle plugin I
configure.
I suspect this is not related to the maven-bundle-plugin, as it is not supposed
to modify resources at all.
> Maven Bundle Plugin Regression: incorrect filtering
> ---
>
> Key: FELIX-5980
> URL: https://issues.apache.org/jira/browse/FELIX-5980
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-4.1.0
>Reporter: Florian Brunner
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: bundle-plugin-filtering-issue.tar.gz
>
>
> With Maven resource filtering enabled, the following Maven Bunde Plugin
> configuration
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
> true
>
>
>
> ${project.version}
>
>
>
>
> generate-sources
>
> cleanVersions
>
>
>
>
> {code}
> filters the following file:
> {code:java}
> org.osgi.framework.system.packages.extra=${module-a.packages}
> module-a.packages=${module-b.packages}, \
> issue.bundleplugin.filtering;version="${module-a.osgi.version.clean}", \
> ${foo-${foo.specification.version}}
> foo-1=org.foo
> {code}
> correctly to target/classes:
> {code:java}
> org.osgi.framework.system.packages.extra=${module-a.packages}
> module-a.packages=${module-b.packages}, \
> issue.bundleplugin.filtering;version="0.1.0.SNAPSHOT", \
> ${foo-${foo.specification.version}}
> foo-1=org.foo{code}
> but the bundle goal then adds the following properties file to the bundle JAR:
> {code:java}
> org.osgi.framework.system.packages.extra=${module-a.packages}
> module-a.packages=${module-b.packages}, \
> issue.bundleplugin.filtering;version="0.1.0.SNAPSHOT", \
> foo-1=org.foo
> {code}
> ${foo-${foo.specification.version}} got stripped to empty string!
> Affected version: 4.1.0
> It used to work with version 3.5.0 -> regression
> I see two issues:
> # ${foo-${foo.specification.version}} got stripped to empty string
> # The bunde goal should just be about packaging. It should not change files
> from target/classes at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-2322) Configurable JAR compression level
[ https://issues.apache.org/jira/browse/FELIX-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16974111#comment-16974111 ] Guillaume Nodet commented on FELIX-2322: The bundle plugin does not reuse the `maven-archiver`. Actually, the writing of the jar is done by `bnd` which supports storing/compressing the jar, but does not allow the compression level to be configured: [https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/osgi/Jar.java#L519-L528] > Configurable JAR compression level > -- > > Key: FELIX-2322 > URL: https://issues.apache.org/jira/browse/FELIX-2322 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Trustin Lee >Priority: Major > Fix For: maven-bundle-plugin-future > > > It seems like there is no way to specify the compression level of the bundle > JAR file generated by maven-bundle-plugin. To reduce the bandwidth, I'd like > to compress the JAR as much as possible. It would be nice if there is a > configurable property in the plugin's section in the pom.xml. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (FELIX-5795) Maven Bundle Plugin Should Upgrade to Use Maven Dependency Tree 3.x
[ https://issues.apache.org/jira/browse/FELIX-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-5795. Fix Version/s: (was: maven-bundle-plugin-future) maven-bundle-plugin-4.2.2 Resolution: Fixed > Maven Bundle Plugin Should Upgrade to Use Maven Dependency Tree 3.x > --- > > Key: FELIX-5795 > URL: https://issues.apache.org/jira/browse/FELIX-5795 > Project: Felix > Issue Type: Wish > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-3.5.0 >Reporter: Kai-Chung Yan >Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.2 > > > Currently Maven Bundle Plugin uses > [DependencyTree|https://github.com/apache/maven-dependency-tree/blob/maven-dependency-tree-2.1/src/main/java/org/apache/maven/shared/dependency/tree/DependencyTreeBuilder.java] > API which is removed in the latest Maven Dependency Tree (3.0.1). The usage > is in > [BundleAllPlugin.java|https://github.com/apache/felix/blob/maven-bundle-plugin-3.5.0/src/main/java/org/apache/felix/bundleplugin/BundleAllPlugin.java#L57]. > Would be great if the plugin take an update. As of Buster, Debian already > updated Maven Dependency Tree to 3.x, which renders Maven Bundle Plugin > [FTBFS|https://bugs.debian.org/880886] (fail to build from source). > -This won't be a trivial fix as quite a few APIs are removed.- The > maintainers in Fedora has written a > [patch|https://src.fedoraproject.org/rpms/maven-plugin-bundle/blob/master/f/0001-Port-to-current-maven-dependency-tree.patch] > to fix this, please consider adopting it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [Discuss] Another try.. move to git
+1 Le sam. 2 nov. 2019 à 10:06, Christian Schneider a écrit : > In the past we discussed a few times about moving felix to git. > > A while ago we did this step for Aries and it was simpler than anticipated. > The problem in Aries were the remaining small bundles and subprojects that > were released by bundle. The larger sub projects were already moved out to > separate git repos a while ago. > > So the situation was very similar to felix. In the end we opted for the > simple solution of just migrating the full repo to git with the help of the > infra team. > This works quite fine since then. So I propose we do the same for felix. > > WDYT? > > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > -- Guillaume Nodet
[jira] [Resolved] (FELIX-6191) [gogo][jline] The cd command should normalize the directory
[ https://issues.apache.org/jira/browse/FELIX-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6191. Resolution: Fixed Committing to https://svn.apache.org/repos/asf/felix/trunk ... M gogo/jline/src/main/java/org/apache/felix/gogo/jline/Posix.java Committed r1868510 > [gogo][jline] The cd command should normalize the directory > --- > > Key: FELIX-6191 > URL: https://issues.apache.org/jira/browse/FELIX-6191 > Project: Felix > Issue Type: Improvement > Components: Gogo JLine > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: gogo.jline-1.1.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6191) [gogo][jline] The cd command should normalize the directory
Guillaume Nodet created FELIX-6191: -- Summary: [gogo][jline] The cd command should normalize the directory Key: FELIX-6191 URL: https://issues.apache.org/jira/browse/FELIX-6191 Project: Felix Issue Type: Improvement Components: Gogo JLine Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: gogo.jline-1.1.6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6187) Avoid overwriting the manifest if it has not changed
Guillaume Nodet created FELIX-6187: -- Summary: Avoid overwriting the manifest if it has not changed Key: FELIX-6187 URL: https://issues.apache.org/jira/browse/FELIX-6187 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-4.2.0 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-4.2.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[RESULT] [VOTE] Release maven-bundle-plugin 4.2.0 (2nd try)
Closing this vote with 8 +1s (4 binding) and no other votes. I'll go ahead and release the plugin, thx to everyone ! Cheers, Guillaume Nodet Le mer. 3 avr. 2019 à 16:14, Guillaume Nodet a écrit : > I've staged another RC for a 4.2.0 release of the maven-bundle-plugin > which includes the following changes: > > e1236412f2 Fix typo in scope > > 54d0740058 [FELIX-6081] Upgrade bndlib to 4.2.0 in order to properly > calculate osgi.ee for embedded dependencies > > fbfdb2985d [FELIX-6078] Add an option to silently ignore some project > types instead of displaying a warning > > 2d559f601b [FELIX-6074] Do not write all stale files at info level > > 9487647dc2 [FELIX-6074] Do not analyze dependencies before the upToDate > check > > e12e94cb84 [FELIX-6073] Upgrade to Maven 3 > > 4857cb9616 [FELIX-6075] Upgrade to JDK 8 > > e971b02f67 [FELIX-6074][FELIX-6075] Support plain incremental manifest > build, upgrade to jdk 8 > > The staging repository is available at: > https://repository.apache.org/content/repositories/orgapachefelix-1296 > > Please review and vote ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
Re: [VOTE] Release maven-bundle-plugin 4.2.0 (2nd try)
+1 Le mer. 3 avr. 2019 à 16:14, Guillaume Nodet a écrit : > I've staged another RC for a 4.2.0 release of the maven-bundle-plugin > which includes the following changes: > > e1236412f2 Fix typo in scope > > 54d0740058 [FELIX-6081] Upgrade bndlib to 4.2.0 in order to properly > calculate osgi.ee for embedded dependencies > > fbfdb2985d [FELIX-6078] Add an option to silently ignore some project > types instead of displaying a warning > > 2d559f601b [FELIX-6074] Do not write all stale files at info level > > 9487647dc2 [FELIX-6074] Do not analyze dependencies before the upToDate > check > > e12e94cb84 [FELIX-6073] Upgrade to Maven 3 > > 4857cb9616 [FELIX-6075] Upgrade to JDK 8 > > e971b02f67 [FELIX-6074][FELIX-6075] Support plain incremental manifest > build, upgrade to jdk 8 > > The staging repository is available at: > https://repository.apache.org/content/repositories/orgapachefelix-1296 > > Please review and vote ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Release maven-bundle-plugin 4.2.0 (2nd try)
I've staged another RC for a 4.2.0 release of the maven-bundle-plugin which includes the following changes: e1236412f2 Fix typo in scope 54d0740058 [FELIX-6081] Upgrade bndlib to 4.2.0 in order to properly calculate osgi.ee for embedded dependencies fbfdb2985d [FELIX-6078] Add an option to silently ignore some project types instead of displaying a warning 2d559f601b [FELIX-6074] Do not write all stale files at info level 9487647dc2 [FELIX-6074] Do not analyze dependencies before the upToDate check e12e94cb84 [FELIX-6073] Upgrade to Maven 3 4857cb9616 [FELIX-6075] Upgrade to JDK 8 e971b02f67 [FELIX-6074][FELIX-6075] Support plain incremental manifest build, upgrade to jdk 8 The staging repository is available at: https://repository.apache.org/content/repositories/orgapachefelix-1296 Please review and vote ! -- Guillaume Nodet
[CANCEL][VOTE] Release maven-bundle-plugin 4.2.0
Cancelling this vote, I'll fix the pom and recut the release. Le mer. 3 avr. 2019 à 13:04, Guillaume Nodet a écrit : > I've staged a 4.2.0 release of the maven-bundle-plugin which includes the > following changes: > > 54d0740058 [FELIX-6081] Upgrade bndlib to 4.2.0 in order to properly > calculate osgi.ee for embedded dependencies > > fbfdb2985d [FELIX-6078] Add an option to silently ignore some project > types instead of displaying a warning > > 2d559f601b [FELIX-6074] Do not write all stale files at info level > > 9487647dc2 [FELIX-6074] Do not analyze dependencies before the upToDate > check > > e12e94cb84 [FELIX-6073] Upgrade to Maven 3 > > 4857cb9616 [FELIX-6075] Upgrade to JDK 8 > > e971b02f67 [FELIX-6074][FELIX-6075] Support plain incremental manifest > build, upgrade to jdk 8 > > The staging repository is available at: > https://repository.apache.org/content/repositories/orgapachefelix-1295 > > Please review and vote ! > > -- > > Guillaume Nodet > > -- Guillaume Nodet
[VOTE] Release maven-bundle-plugin 4.2.0
I've staged a 4.2.0 release of the maven-bundle-plugin which includes the following changes: 54d0740058 [FELIX-6081] Upgrade bndlib to 4.2.0 in order to properly calculate osgi.ee for embedded dependencies fbfdb2985d [FELIX-6078] Add an option to silently ignore some project types instead of displaying a warning 2d559f601b [FELIX-6074] Do not write all stale files at info level 9487647dc2 [FELIX-6074] Do not analyze dependencies before the upToDate check e12e94cb84 [FELIX-6073] Upgrade to Maven 3 4857cb9616 [FELIX-6075] Upgrade to JDK 8 e971b02f67 [FELIX-6074][FELIX-6075] Support plain incremental manifest build, upgrade to jdk 8 The staging repository is available at: https://repository.apache.org/content/repositories/orgapachefelix-1295 Please review and vote ! -- Guillaume Nodet
[jira] [Resolved] (FELIX-6081) Upgrade bndlib to 4.2.0 in order to properly calculate osgi.ee for embedded dependencies
[ https://issues.apache.org/jira/browse/FELIX-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6081. Resolution: Fixed Assignee: Guillaume Nodet Fix Version/s: maven-bundle-plugin-4.2.0 Thx for the reporting and fixing the issue. > Upgrade bndlib to 4.2.0 in order to properly calculate osgi.ee for embedded > dependencies > > > Key: FELIX-6081 > URL: https://issues.apache.org/jira/browse/FELIX-6081 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-4.1.0 >Reporter: Krystian Nowak > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > > The *_bndlib_* dependency > [https://github.com/apache/felix/blob/e12e94cb84d99e4613a4a57c3655bc7c6095140c/tools/maven-bundle-plugin/pom.xml#L172-L176] > needs to be upgraded from _4.1.0_ to *_4.2.0_* > ([http://repo1.maven.org/maven2/biz/aQute/bnd/biz.aQute.bndlib/4.2.0/]) as in > _4.2.0_ the following issue is fixed > [https://github.com/bndtools/bnd/issues/3010] by > [https://github.com/bndtools/bnd/pull/3015] excluding _module-info_ class > from class version in use calculation for _Require-Capability_ *_osgi.ee_* > for embedded dependencies. > This will allow to properly use a dependency where its code is compiled for > e.g. _Java SE 5.0_ but the whole build performed on (and also module-info > class compiled against) _Java SE 7_ as in > [https://gitlab.ow2.org/asm/asm/issues/317870]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6078) Add an option to silently ignore some project types instead of displaying a warning
[ https://issues.apache.org/jira/browse/FELIX-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6078. Resolution: Fixed Committing to https://svn.apache.org/repos/asf/felix/trunk ... M tools/maven-bundle-plugin/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java Committed r1854760 > Add an option to silently ignore some project types instead of displaying a > warning > --- > > Key: FELIX-6078 > URL: https://issues.apache.org/jira/browse/FELIX-6078 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > > When using multiple levels of reactors, it's not possible to avoid some > warnings on parent poms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6078) Add an option to silently ignore some project types instead of displaying a warning
Guillaume Nodet created FELIX-6078: -- Summary: Add an option to silently ignore some project types instead of displaying a warning Key: FELIX-6078 URL: https://issues.apache.org/jira/browse/FELIX-6078 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-4.2.0 When using multiple levels of reactors, it's not possible to avoid some warnings on parent poms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6074) Check for stale input and avoid recomputing the manifest if no changes
[ https://issues.apache.org/jira/browse/FELIX-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6074. Resolution: Fixed https://github.com/apache/felix/commit/e971b02f672144311eb80f479156bee412f5920b https://github.com/apache/felix/commit/9487647dc2fa8734a0ab4a113b0b93ec281a2594 https://github.com/apache/felix/commit/2d559f601b2d077f34d83e924f9db37cc079b9c9 > Check for stale input and avoid recomputing the manifest if no changes > -- > > Key: FELIX-6074 > URL: https://issues.apache.org/jira/browse/FELIX-6074 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6075) Upgrade to JDK 8
[ https://issues.apache.org/jira/browse/FELIX-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6075. Resolution: Fixed https://github.com/apache/felix/commit/e971b02f672144311eb80f479156bee412f5920b https://github.com/apache/felix/commit/4857cb96163632db1e411787e54ce95e74ea6033 > Upgrade to JDK 8 > > > Key: FELIX-6075 > URL: https://issues.apache.org/jira/browse/FELIX-6075 > Project: Felix > Issue Type: Improvement > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-6073) Upgrade to Maven 3
[ https://issues.apache.org/jira/browse/FELIX-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-6073. Resolution: Fixed https://github.com/apache/felix/commit/e12e94cb84d99e4613a4a57c3655bc7c6095140c > Upgrade to Maven 3 > -- > > Key: FELIX-6073 > URL: https://issues.apache.org/jira/browse/FELIX-6073 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6075) Upgrade to JDK 8
Guillaume Nodet created FELIX-6075: -- Summary: Upgrade to JDK 8 Key: FELIX-6075 URL: https://issues.apache.org/jira/browse/FELIX-6075 Project: Felix Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: maven-bundle-plugin-4.2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FELIX-6073) Upgrade to Maven 3
[ https://issues.apache.org/jira/browse/FELIX-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned FELIX-6073: -- Assignee: Guillaume Nodet > Upgrade to Maven 3 > -- > > Key: FELIX-6073 > URL: https://issues.apache.org/jira/browse/FELIX-6073 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-6073) Upgrade to Maven 3
[ https://issues.apache.org/jira/browse/FELIX-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-6073: --- Fix Version/s: maven-bundle-plugin-4.2.0 > Upgrade to Maven 3 > -- > > Key: FELIX-6073 > URL: https://issues.apache.org/jira/browse/FELIX-6073 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-6074) Check for stale input and avoid recomputing the manifest if no changes
[ https://issues.apache.org/jira/browse/FELIX-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-6074: --- Fix Version/s: maven-bundle-plugin-4.2.0 > Check for stale input and avoid recomputing the manifest if no changes > -- > > Key: FELIX-6074 > URL: https://issues.apache.org/jira/browse/FELIX-6074 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin > Reporter: Guillaume Nodet > Assignee: Guillaume Nodet >Priority: Major > Fix For: maven-bundle-plugin-4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6074) Check for stale input and avoid recomputing the manifest if no changes
Guillaume Nodet created FELIX-6074: -- Summary: Check for stale input and avoid recomputing the manifest if no changes Key: FELIX-6074 URL: https://issues.apache.org/jira/browse/FELIX-6074 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6073) Upgrade to Maven 3
Guillaume Nodet created FELIX-6073: -- Summary: Upgrade to Maven 3 Key: FELIX-6073 URL: https://issues.apache.org/jira/browse/FELIX-6073 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Guillaume Nodet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750728#comment-16750728
]
Guillaume Nodet commented on FELIX-6034:
Right, but the other questions remain. What's the purpose of this requirement
if no one is using it ? I don't see the need for this additional and very
specific requirement. In addition to not break compatibility, they should be
semantically correct.
In the case of gogo, the jline and shell bundles to require the runtime, but
that should actually be specified using a service requirement on the
{{CommandProcessor}} which is missing. In a similar way, the commands to
require a shell, but the shell does not require the command bundle.
Those bi-directional links are way too strict and do not represent the reality,
just a possible deployment option.
If you keep the uni-directional link, then, if you want to resolve the command
bundle, you'll end up with the shell and the runtime, which is fine. But if
you want the runtime and use it in a different way, you should not be tied to
the other parts of gogo.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750728#comment-16750728
]
Guillaume Nodet edited comment on FELIX-6034 at 1/24/19 5:06 AM:
-
Right, but the other questions remain. What's the purpose of this requirement
if no one is using it ? I don't see the need for this additional and very
specific requirement. In addition to not break compatibility, they should be
semantically correct.
In the case of gogo, the jline and shell bundles to require the runtime, but
that should actually be specified using a service requirement on the
{{CommandProcessor}} which is missing. In a similar way, the commands to
require a shell, but the shell does not require the command bundle.
Those bi-directional links are way too strict and do not represent the reality,
just a possible deployment option.
If you keep the uni-directional link, then, if you want to resolve the command
bundle, you'll end up with the shell and the runtime, which is fine. But if
you want the runtime and use it in a different way, you should not be tied to
the other parts of gogo.
was (Author: gnt):
Right, but the other questions remain. What's the purpose of this requirement
if no one is using it ? I don't see the need for this additional and very
specific requirement. In addition to not break compatibility, they should be
semantically correct.
In the case of gogo, the jline and shell bundles to require the runtime, but
that should actually be specified using a service requirement on the
{{CommandProcessor}} which is missing. In a similar way, the commands to
require a shell, but the shell does not require the command bundle.
Those bi-directional links are way too strict and do not represent the reality,
just a possible deployment option.
If you keep the uni-directional link, then, if you want to resolve the command
bundle, you'll end up with the shell and the runtime, which is fine. But if
you want the runtime and use it in a different way, you should not be tied to
the other parts of gogo.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750716#comment-16750716
]
Guillaume Nodet edited comment on FELIX-6034 at 1/24/19 4:46 AM:
-
The effectiveness is controlled by the {{ResolveContext#isEffective}} method.
What you describe is only the default implementation of the osgi framework at
runtime, not the resolver spec.
If this requirement is _literally disabled for all intents and purposes,_ then
simply removing it should not affect anyone either, but it will allow Karaf to
upgrade until a minor version includes this breaking change.
If the plan is to include more requirements like this one in the future, that's
ok, but not in micro releases to avoid such compatibility break.
was (Author: gnt):
The effectiveness is controlled by the {{ResolveContext#isEffective}} method.
What you describe is only the default implementation of the osgi framework at
runtime, not the resolver spec.
If this requirement is _literally disabled for all intents and purposes,_ then
simply removing it should not affect anyone either, but it will allow Karaf to
upgrade until a minor version includes this breaking change.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750716#comment-16750716
]
Guillaume Nodet commented on FELIX-6034:
The effectiveness is controlled by the {{ResolveContext#isEffective}} method.
What you describe is only the default implementation of the osgi framework at
runtime, not the resolver spec.
If this requirement is _literally disabled for all intents and purposes,_ then
simply removing it should not affect anyone either, but it will allow Karaf to
upgrade until a minor version includes this breaking change.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750703#comment-16750703
]
Guillaume Nodet commented on FELIX-6034:
The service requirements are not really used at runtime per se, it's used while
the deployment agent computes the list of required bundles using the osgi
resolver / resources / etc...
>From a versioning pov, the felix bundles should not add new requirements in
>micro releases, even is that's not caught by any semantic versioning check. I
>suggest to revert the change, release a compatible version and add the change
>in new version with at least a minor version increase.
>From a gogo pov, I'm not sure why this requirement has been added. The gogo
>bundles can work independantly, the proof being that Karaf does not use them
>all. Commands are discovered by gogo, so there are not strong requirements to
>be added here. If there is a requirement to be added, it should be a
>requirement on services with a 0..N cardinality, not a mandatory requirement
>on a capability that only the gogo command provides. This really sounds like
>some magic requirements in order to tie bundles together in a usable piece.
>This goes against the reusability of the osgi manifest imho.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (FELIX-6034) Gogo JLine requirement doesn't allow to embed gogo.jline
[
https://issues.apache.org/jira/browse/FELIX-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750703#comment-16750703
]
Guillaume Nodet edited comment on FELIX-6034 at 1/24/19 4:22 AM:
-
The service requirements are not really used at runtime per se, it's used while
the deployment agent computes the list of required bundles using the osgi
resolver / resources / etc...
>From a versioning pov, the felix bundles should not add new requirements in
>micro releases, even is that's not caught by any semantic versioning check. I
>suggest to revert the change, release a compatible version and add the change
>in new version with at least a minor version increase.
>From a gogo pov, I'm not sure why this requirement has been added. The gogo
>bundles can work independantly, the proof being that Karaf does not use them
>all. Commands are discovered by gogo, so there are not strong requirements to
>be added here. If there is a requirement to be added, it should be a
>requirement on services with a 0..N cardinality, not a mandatory requirement
>on a capability that only the gogo command provides. This really sounds like
>some magic requirements in order to tie bundles together in a usable piece.
>This goes against the reusability of the osgi manifest imho.
>From a karaf pov, once a minor release of those bundles is out, it should be
>able to tweak the feature descriptors to provide the required capability from
>one of the bundle if needed.
was (Author: gnt):
The service requirements are not really used at runtime per se, it's used while
the deployment agent computes the list of required bundles using the osgi
resolver / resources / etc...
>From a versioning pov, the felix bundles should not add new requirements in
>micro releases, even is that's not caught by any semantic versioning check. I
>suggest to revert the change, release a compatible version and add the change
>in new version with at least a minor version increase.
>From a gogo pov, I'm not sure why this requirement has been added. The gogo
>bundles can work independantly, the proof being that Karaf does not use them
>all. Commands are discovered by gogo, so there are not strong requirements to
>be added here. If there is a requirement to be added, it should be a
>requirement on services with a 0..N cardinality, not a mandatory requirement
>on a capability that only the gogo command provides. This really sounds like
>some magic requirements in order to tie bundles together in a usable piece.
>This goes against the reusability of the osgi manifest imho.
> Gogo JLine requirement doesn't allow to embed gogo.jline
>
>
> Key: FELIX-6034
> URL: https://issues.apache.org/jira/browse/FELIX-6034
> Project: Felix
> Issue Type: Bug
> Components: Gogo JLine
>Affects Versions: gogo.jline-1.1.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: gogo.jline-1.1.3
>
>
> Felix Gogo Jline 1.1.2 introduced a Requirement:
> {code}
> @Requirement(
> effective = "active",
> namespace = "org.apache.felix.gogo",
> name = "command.implementation",
> version = "1.0.0"
> )
> {code}
> This requirement is a contract to find concrete command. However, in the case
> of Gogo JLine embedded as a standalone bundle, waiting for commands
> implementation (later on), this requirement doesn't allow to start. That's
> the case in Apache Karaf shell.
> [~rotty3000] do you mind if I remove this requirement (as I did other fixes
> like in {{Posix}} commands) ? We could add this Requirement in gogo.jline 2.x
> and then, I will have to find a bypass or at least a fake command providing a
> capability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: modelling gogo command descriptions
Afaik, gogo supports overriden methods, so you can have multiple methods for a single command (for example the "cd" command). I'm not sure that adding this metadata to the function name will be very easy. Maybe a possible way would be to have a json file containing the metadata in a know location so that the "help" command could load them on demand and have them generated by a maven plugin at build time ? Le lun. 22 oct. 2018 à 05:59, Raymond Auge a écrit : > Hey all, > > In a recent conversation with Thomas Watson we touched on moving some > commands into their implementation bundles. For instance, log commands > should be in the log service impl, etc. > > However we don't want to lose the @Descriptor & @Parameter features to > describe the commands. On the other hand, we should not be coupled to the > `org.apache.felix.service.command` package. > > My first notion was to use Bundle annotations, but obviously those are not > visible at runtime when the command processor handles the commands. > > Then I was thinking of encoding the information as either an additional > service property on the command service. However the alignment, > particularly, with the property `osgi.command.function`, which is an array, > makes this a little weird. > > Then I thought maybe we could extend the encoding of > `osgi.command.function` to use the OSGi package syntax which would continue > to make any existing values compatible (since they would be just keys, > while allowing for additional "attributes", such as description and > parameters to be added. It's certainly not perfect. > > Anyone have thoughts on ways of encoding this? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > -- Guillaume Nodet
Re: modelling gogo command descriptions
Le lun. 22 oct. 2018 à 05:59, Raymond Auge a écrit : > Hey all, > > In a recent conversation with Thomas Watson we touched on moving some > commands into their implementation bundles. For instance, log commands > should be in the log service impl, etc. > > However we don't want to lose the @Descriptor & @Parameter features to > describe the commands. On the other hand, we should not be coupled to the > `org.apache.felix.service.command` package. > Using an optional import should be fine. This should not prevent loading the classes even if the annotations are not present at runtime. This looks the easiest option to me. Could you explain what problems you see in it ? I don't really understand. > > My first notion was to use Bundle annotations, but obviously those are not > visible at runtime when the command processor handles the commands. > > Then I was thinking of encoding the information as either an additional > service property on the command service. However the alignment, > particularly, with the property `osgi.command.function`, which is an array, > makes this a little weird. > > Then I thought maybe we could extend the encoding of > `osgi.command.function` to use the OSGi package syntax which would continue > to make any existing values compatible (since they would be just keys, > while allowing for additional "attributes", such as description and > parameters to be added. It's certainly not perfect. > > Anyone have thoughts on ways of encoding this? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > -- Guillaume Nodet
Re: [RESULT] [VOTE] Release Maven Bundle Plugin 3.5.1
You're right, sorry about that. I tend to stop the release process when I click on the "release" button in the nexus repo. Le ven. 6 juil. 2018 à 15:40, Karl Pauls a écrit : > Looks like you forgot to add the artifacts to the dist area (and > update the side). I just did it for you but it would be nice if you > remember next time. > > Technically, artifacts are not officially released if they are not in > the dist... > > regards, > > Karl > On Tue, Jun 19, 2018 at 6:23 PM Guillaume Nodet wrote: > > > > Closing this vote wih 7 +1s > > I'll publish the release asap. > > > > Cheers, > > Guillaume Nodet > > > > Le jeu. 14 juin 2018 à 22:27, Guillaume Nodet a > écrit : > > > > > I've staged a release at the following location: > > > https://repository.apache.org/content/repositories/orgapachefelix-1231 > > > > > > Changes: > > > > > > 0f47585a98 [FELIX-5794] maven-bundle-plugin fails to parse > > > meta-persistence > > > > > > Please review and vote ! > > > > > > Guillaume > > > > > > > > > -- > > > > Guillaume Nodet > > > > -- > Karl Pauls > karlpa...@gmail.com > -- Guillaume Nodet
Re: [VOTE] Apache Felix Framework 6.0.0 and related subproject releases
+1 I've tested the binaries in Karaf with success. Le mar. 3 juil. 2018 à 17:03, Karl Pauls a écrit : > I would like to call a vote on the following subproject releases: > > resolver 2.0.0 > framework 6.0.0 > main 6.0.0 > main.distribution 6.0.0 > > The main changelogs are in jira and at: > > https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.resolver-2.0.0/doc/changelog.txt > > https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-6.0.0/doc/changelog.txt > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-1234/ > > 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 1234 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > -- Guillaume Nodet
