[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)
[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=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=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)
[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=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=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=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=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 when build
[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
> 7.4.1
>
>
> org.elasticsearch.client
> elasticsearch-rest-client
> 7.4.1
>
> {code}
> Also I got this warning all the time in IntelliJ - *The package
> org.elasticsearch.client is inside a non-bundle dependency* on this code:
> try (RestHighLevelClient client = new
> RestHighLevelClient(RestClient.builder(new HttpHost(server, port, protocol),//
> new HttpHost(server, secondPort, protocol))); ResourceResolver
> resourceResolver = request.getResourceResolver())
> {
> if
[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=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=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=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)
[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/bundles/system/org.apache.felix.fileinstall-3.6.4.jar]:
> Unexpected problem updating
[jira] [Commented] (FELIX-6236) ssh / telnet gogojline
[ https://issues.apache.org/jira/browse/FELIX-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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)
[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=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=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=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=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)
[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)
[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=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=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=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=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=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=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)
[jira] [Commented] (FELIX-5306) User friendly syntax for floats and doubles in FileInstall
[
https://issues.apache.org/jira/browse/FELIX-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526093#comment-16526093
]
Guillaume Nodet commented on FELIX-5306:
It's a fork.
The usage is slightly different, because FileInstall exposes those files while
ConfigAdmin keep them internal.
Please raise a new JIRA issue for ConfigAdmin if you want to have some changes
there.
> User friendly syntax for floats and doubles in FileInstall
> --
>
> Key: FELIX-5306
> URL: https://issues.apache.org/jira/browse/FELIX-5306
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Reporter: munene kiruja
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: utils-1.10.2, fileinstall-3.6.2
>
>
> The format for specifying a float in the .config format is =F" value> and similarly for doubles but with the type character D.
> When the floats and doubles are encountered in the config,
> java.lang.NumberFormatException is thrown with the message like:
> {code}
> java.lang.NumberFormatException: For input string: "400.333"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.parseInt(Integer.java:615)
> {code}
> The code is actually parsing using Integer and Long classes!!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (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 reopened FELIX-4577:
> 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
>Assignee: Guillaume Nodet
>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
(v7.6.3#76005)
[jira] [Updated] (FELIX-5698) Bundle plugin cannot cope with Java 9 module-info.java
[
https://issues.apache.org/jira/browse/FELIX-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-5698:
---
Fix Version/s: maven-bundle-plugin-3.5.0
> Bundle plugin cannot cope with Java 9 module-info.java
> --
>
> Key: FELIX-5698
> URL: https://issues.apache.org/jira/browse/FELIX-5698
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.3.0
> Environment: java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Mark Raynsford
>Priority: Major
> Fix For: maven-bundle-plugin-3.5.0
>
>
> Please see the trivial repro case at:
> [maven-bundle-plugin-20170923|https://github.com/io7m/maven-bundle-plugin-20170923]
> The plugin fails with:
> {noformat}
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 :
> Exception: java.lang.ArrayIndexOutOfBoundsException: 19
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 :
> Invalid class file module-info.class
> (java.lang.ArrayIndexOutOfBoundsException: 19)
> {noformat}
> There doesn't appear to be a way to exclude the module-info.java files from
> BND's class file analysis. An easy fix for this bug would be to simple ignore
> module-info.java files as they're irrelevant for OSGi (but will be present in
> projects that aim to support both OSGi and Jigsaw).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5698) Bundle plugin cannot cope with Java 9 module-info.java
[
https://issues.apache.org/jira/browse/FELIX-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5698.
Resolution: Fixed
> Bundle plugin cannot cope with Java 9 module-info.java
> --
>
> Key: FELIX-5698
> URL: https://issues.apache.org/jira/browse/FELIX-5698
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.3.0
> Environment: java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Mark Raynsford
>Priority: Major
> Fix For: maven-bundle-plugin-3.5.0
>
>
> Please see the trivial repro case at:
> [maven-bundle-plugin-20170923|https://github.com/io7m/maven-bundle-plugin-20170923]
> The plugin fails with:
> {noformat}
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 :
> Exception: java.lang.ArrayIndexOutOfBoundsException: 19
> [ERROR] Bundle com.io7m.bugs:maven-bundle-plugin-20170923:bundle:0.1.0 :
> Invalid class file module-info.class
> (java.lang.ArrayIndexOutOfBoundsException: 19)
> {noformat}
> There doesn't appear to be a way to exclude the module-info.java files from
> BND's class file analysis. An easy fix for this bug would be to simple ignore
> module-info.java files as they're irrelevant for OSGi (but will be present in
> projects that aim to support both OSGi and Jigsaw).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-4193) make maven bundle plugin generate indexes compliant with the R5 Repository Service Specification
[ https://issues.apache.org/jira/browse/FELIX-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513754#comment-16513754 ] Guillaume Nodet commented on FELIX-4193: Nice try, but even though bundlerepository 2.x supports reading the OSGi Xml repository, I don't think there's any code that can write those. I would suggest using the newer code in felix utils instead as a basis, it's a clean room implementation and as a writer : https://github.com/apache/felix/blob/trunk/utils/src/main/java/org/apache/felix/utils/repository/StaxParser.java#L90 > make maven bundle plugin generate indexes compliant with the R5 Repository > Service Specification > > > Key: FELIX-4193 > URL: https://issues.apache.org/jira/browse/FELIX-4193 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Cristiano Gavião >Priority: Major > Fix For: maven-bundle-plugin-4.0.0 > > > Currently the index generated by maven-bundle-plugin cannot be used by a > Repository Service. > So I would like to generate a repository indexes compliant with the > Repository Service Specification version 1.0, as defined in the OSGi Service > Platform Service Compendium, Release 5. > BND or Bindex could be used since they already are compliant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-4193) make maven bundle plugin generate indexes compliant with the R5 Repository Service Specification
[ https://issues.apache.org/jira/browse/FELIX-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-4193: --- Fix Version/s: maven-bundle-plugin-4.0.0 > make maven bundle plugin generate indexes compliant with the R5 Repository > Service Specification > > > Key: FELIX-4193 > URL: https://issues.apache.org/jira/browse/FELIX-4193 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Cristiano Gavião >Priority: Major > Fix For: maven-bundle-plugin-4.0.0 > > > Currently the index generated by maven-bundle-plugin cannot be used by a > Repository Service. > So I would like to generate a repository indexes compliant with the > Repository Service Specification version 1.0, as defined in the OSGi Service > Platform Service Compendium, Release 5. > BND or Bindex could be used since they already are compliant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (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 reassigned FELIX-5795: -- Assignee: Guillaume Nodet > 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.0.0 > > > 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 (v7.6.3#76005)
[jira] [Updated] (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 updated FELIX-5795: --- Fix Version/s: maven-bundle-plugin-4.0.0 > 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 >Priority: Major > Fix For: maven-bundle-plugin-4.0.0 > > > 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 (v7.6.3#76005)
[jira] [Closed] (FELIX-1765) Add framework, org.osgi and gogo bundles to felix obr index
[ https://issues.apache.org/jira/browse/FELIX-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed FELIX-1765. -- Resolution: Won't Fix > Add framework, org.osgi and gogo bundles to felix obr index > --- > > Key: FELIX-1765 > URL: https://issues.apache.org/jira/browse/FELIX-1765 > Project: Felix > Issue Type: Improvement > Components: Bundle Repository (OBR), Framework, Gogo Runtime >Reporter: David Savage >Priority: Major > > A while ago we had a discussion on the mailing list [1] about adding the > felix framework to the felix obr index. I'm happy to take a shot at this if > someone can point me in the right direction? > It would also be useful, even though we've removed the org.osgi bundles from > the maven dependencies to list them in the felix repository. The reason for > this is that it is a much smaller set of dependencies compared with the uber > list at osgi.org which is therefore quicker to index and search for > dependencies. > Finally whilst doing some related development work I noticed that the gogo > bundles are not yet included in the felix index which may just be an > oversight? > [1] http://www.mail-archive.com/dev@felix.apache.org/msg11009.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (FELIX-5790) Improve procedural function syntax
[
https://issues.apache.org/jira/browse/FELIX-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed FELIX-5790.
--
Resolution: Duplicate
> Improve procedural function syntax
> --
>
> Key: FELIX-5790
> URL: https://issues.apache.org/jira/browse/FELIX-5790
> Project: Felix
> Issue Type: Improvement
> Components: Gogo JLine
>Reporter: Guillaume Nodet
>Priority: Major
>
> The procedural functions can be made more user friendly:
> {code}
> each {1..10} do { xxx }
> if { condition } then { action } elif { another action } else { else action }
> try { code } catch { catch-action } finally { finally-action }
> while { condition } do { action }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5869) [goto][jline] Weird error if the script contains unicode characters
[
https://issues.apache.org/jira/browse/FELIX-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5869.
Resolution: Fixed
Fix Version/s: gogo.jline-1.1.0
{code}
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M gogo/jline/src/main/java/org/apache/felix/gogo/jline/Shell.java
Committed r1833507
{code}
> [goto][jline] Weird error if the script contains unicode characters
> ---
>
> Key: FELIX-5869
> URL: https://issues.apache.org/jira/browse/FELIX-5869
> Project: Felix
> Issue Type: Improvement
> Components: Gogo JLine
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.jline-1.1.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5869) [goto][jline] Weird error if the script contains unicode characters
[ https://issues.apache.org/jira/browse/FELIX-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512518#comment-16512518 ] Guillaume Nodet commented on FELIX-5869: This has been fixed a long time ago on the gogo-shell bundle in FELIX-4375. We simply need to backport the fix. > [goto][jline] Weird error if the script contains unicode characters > --- > > Key: FELIX-5869 > URL: https://issues.apache.org/jira/browse/FELIX-5869 > Project: Felix > Issue Type: Improvement > Components: Gogo JLine >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5869) [goto][runtime] Weird error if the script contains unicode characters
[ https://issues.apache.org/jira/browse/FELIX-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-5869: --- Component/s: (was: Gogo Runtime) Gogo JLine > [goto][runtime] Weird error if the script contains unicode characters > - > > Key: FELIX-5869 > URL: https://issues.apache.org/jira/browse/FELIX-5869 > Project: Felix > Issue Type: Improvement > Components: Gogo JLine >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5869) [goto][jline] Weird error if the script contains unicode characters
[ https://issues.apache.org/jira/browse/FELIX-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-5869: --- Summary: [goto][jline] Weird error if the script contains unicode characters (was: [goto][runtime] Weird error if the script contains unicode characters) > [goto][jline] Weird error if the script contains unicode characters > --- > > Key: FELIX-5869 > URL: https://issues.apache.org/jira/browse/FELIX-5869 > Project: Felix > Issue Type: Improvement > Components: Gogo JLine >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5869) [goto][jline] Weird error if the script contains unicode characters
[
https://issues.apache.org/jira/browse/FELIX-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512077#comment-16512077
]
Guillaume Nodet commented on FELIX-5869:
The {{Shell#readScript}} method assumes the input length is the string length.
https://github.com/apache/felix/blob/trunk/gogo/jline/src/main/java/org/apache/felix/gogo/jline/Shell.java#L202-L219
> [goto][jline] Weird error if the script contains unicode characters
> ---
>
> Key: FELIX-5869
> URL: https://issues.apache.org/jira/browse/FELIX-5869
> Project: Felix
> Issue Type: Improvement
> Components: Gogo JLine
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5869) [goto][runtime] Weird error if the script contains unicode characters
Guillaume Nodet created FELIX-5869: -- Summary: [goto][runtime] Weird error if the script contains unicode characters Key: FELIX-5869 URL: https://issues.apache.org/jira/browse/FELIX-5869 Project: Felix Issue Type: Improvement Components: Gogo Runtime Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5794) maven-bundle-plugin fails to parse meta-persistence
[
https://issues.apache.org/jira/browse/FELIX-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506140#comment-16506140
]
Guillaume Nodet commented on FELIX-5794:
{code}
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M
tools/maven-bundle-plugin/src/main/java/org/apache/felix/bundleplugin/JpaPlugin.java
M
tools/maven-bundle-plugin/src/main/resources/org/apache/felix/bundleplugin/jpa.xsl
M
tools/maven-bundle-plugin/src/test/java/org/apache/felix/bundleplugin/JpaPluginTest.java
Committed r1833192
{code}
> maven-bundle-plugin fails to parse meta-persistence
> ---
>
> Key: FELIX-5794
> URL: https://issues.apache.org/jira/browse/FELIX-5794
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.4.0, maven-bundle-plugin-3.5.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: maven-bundle-plugin-3.5.2
>
>
> Since {{maven-bundle-plugin}} 3.4.0 (and the update to bnd 3.4.0), the plugin
> fails to build bundle containing {{}}. NB: the same bundle
> builds fine with {{maven-bundle-plugin}} 3.3.0.
> The cause is:
> {code}
> [INFO] --- maven-bundle-plugin:3.5.0:bundle (default-bundle) @
> karaf-jpa-example-provider ---
> Output: [Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name="booking",
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",
> DynamicImport-Package: org.hibernate.proxy;javassist.util.proxy,
> Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name="booking",
> Import-Package:
> org.hibernate.proxy;javassist.util.proxy;resolution:=optional,
> Require-Capability: osgi.extender;osgi.extender=aries.jpa,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;]
> [ERROR] Bundle
> org.apache.karaf.examples:karaf-jpa-example-provider:bundle:4.2.0-SNAPSHOT :
> Header contains name field after attribute or directive: null from
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",osgi.extender;osgi.extender=aries.jpa,osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;.
> Name fields must be consecutive, separated by a ';' like a;b;c;x=3;y=4
> [ERROR] Error(s) found in bundle configuration
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5794) maven-bundle-plugin fails to parse meta-persistence
[
https://issues.apache.org/jira/browse/FELIX-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5794.
Resolution: Fixed
Fix Version/s: maven-bundle-plugin-3.5.2
> maven-bundle-plugin fails to parse meta-persistence
> ---
>
> Key: FELIX-5794
> URL: https://issues.apache.org/jira/browse/FELIX-5794
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.4.0, maven-bundle-plugin-3.5.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: maven-bundle-plugin-3.5.2
>
>
> Since {{maven-bundle-plugin}} 3.4.0 (and the update to bnd 3.4.0), the plugin
> fails to build bundle containing {{}}. NB: the same bundle
> builds fine with {{maven-bundle-plugin}} 3.3.0.
> The cause is:
> {code}
> [INFO] --- maven-bundle-plugin:3.5.0:bundle (default-bundle) @
> karaf-jpa-example-provider ---
> Output: [Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name="booking",
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",
> DynamicImport-Package: org.hibernate.proxy;javassist.util.proxy,
> Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name="booking",
> Import-Package:
> org.hibernate.proxy;javassist.util.proxy;resolution:=optional,
> Require-Capability: osgi.extender;osgi.extender=aries.jpa,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;]
> [ERROR] Bundle
> org.apache.karaf.examples:karaf-jpa-example-provider:bundle:4.2.0-SNAPSHOT :
> Header contains name field after attribute or directive: null from
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",osgi.extender;osgi.extender=aries.jpa,osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;.
> Name fields must be consecutive, separated by a ';' like a;b;c;x=3;y=4
> [ERROR] Error(s) found in bundle configuration
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (FELIX-5794) maven-bundle-plugin fails to parse meta-persistence
[
https://issues.apache.org/jira/browse/FELIX-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5794 started by Guillaume Nodet.
--
> maven-bundle-plugin fails to parse meta-persistence
> ---
>
> Key: FELIX-5794
> URL: https://issues.apache.org/jira/browse/FELIX-5794
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-3.4.0, maven-bundle-plugin-3.5.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
>Priority: Major
>
> Since {{maven-bundle-plugin}} 3.4.0 (and the update to bnd 3.4.0), the plugin
> fails to build bundle containing {{}}. NB: the same bundle
> builds fine with {{maven-bundle-plugin}} 3.3.0.
> The cause is:
> {code}
> [INFO] --- maven-bundle-plugin:3.5.0:bundle (default-bundle) @
> karaf-jpa-example-provider ---
> Output: [Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManager;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.template.JpaTemplate;osgi.unit.name="booking",
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",
> DynamicImport-Package: org.hibernate.proxy;javassist.util.proxy,
> Provide-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.EntityManagerFactory;osgi.unit.name="booking",
> Provide-Capability:
> osgi.service;effective:=active;objectClass=org.apache.aries.jpa.supplier.EmSupplier;osgi.unit.name="booking",
> Import-Package:
> org.hibernate.proxy;javassist.util.proxy;resolution:=optional,
> Require-Capability: osgi.extender;osgi.extender=aries.jpa,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,
> Require-Capability:
> osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;]
> [ERROR] Bundle
> org.apache.karaf.examples:karaf-jpa-example-provider:bundle:4.2.0-SNAPSHOT :
> Header contains name field after attribute or directive: null from
> osgi.service;effective:=active;objectClass=javax.sql.DataSource;filter:="(osgi.jndi.service.name=booking)",osgi.extender;osgi.extender=aries.jpa,osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider,osgi.service;effective:=active;objectClass=javax.transaction.TransactionManager;.
> Name fields must be consecutive, separated by a ';' like a;b;c;x=3;y=4
> [ERROR] Error(s) found in bundle configuration
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16488634#comment-16488634 ] Guillaume Nodet commented on FELIX-5860: I've just reverted. I think we should release a R6 compatible version first. > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated FELIX-5860: --- Fix Version/s: (was: connect-0.2.0) > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (FELIX-5860) Upgrade to OSGi R7
[ https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened FELIX-5860: > Upgrade to OSGi R7 > -- > > Key: FELIX-5860 > URL: https://issues.apache.org/jira/browse/FELIX-5860 > Project: Felix > Issue Type: Improvement > Components: Connect >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5860) Upgrade to OSGi R7
[
https://issues.apache.org/jira/browse/FELIX-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5860.
Resolution: Fixed
{code:sh}
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M connect/pom.xml
M
connect/src/main/java/org/apache/felix/connect/felix/framework/ServiceRegistrationImpl.java
Committed r1832138
{code}
> Upgrade to OSGi R7
> --
>
> Key: FELIX-5860
> URL: https://issues.apache.org/jira/browse/FELIX-5860
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: connect-0.2.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (FELIX-5857) Provide a context classloader on the session to help with class loading
[ https://issues.apache.org/jira/browse/FELIX-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved FELIX-5857. Resolution: Fixed https://github.com/apache/felix/commit/56ba0acf8e24c4d9bd1b4fb1a8e295c0f3084ae2 > Provide a context classloader on the session to help with class loading > --- > > Key: FELIX-5857 > URL: https://issues.apache.org/jira/browse/FELIX-5857 > Project: Felix > Issue Type: Improvement > Components: Gogo JLine, Gogo Runtime, Gogo Shell >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: gogo.jline-1.1.0, gogo.runtime-1.1.0, gogo.shell-1.1.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5857) Provide a context classloader on the session to help with class loading
Guillaume Nodet created FELIX-5857: -- Summary: Provide a context classloader on the session to help with class loading Key: FELIX-5857 URL: https://issues.apache.org/jira/browse/FELIX-5857 Project: Felix Issue Type: Improvement Components: Gogo JLine, Gogo Runtime, Gogo Shell Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: gogo.jline-1.1.0, gogo.runtime-1.1.0, gogo.shell-1.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5856) Coercion between Object[] and List
[
https://issues.apache.org/jira/browse/FELIX-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5856.
Resolution: Fixed
{code:java}
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Reflective.java
M
gogo/runtime/src/test/java/org/apache/felix/gogo/runtime/TestCoercion.java
Committed r1831780{code}
> Coercion between Object[] and List
> --
>
> Key: FELIX-5856
> URL: https://issues.apache.org/jira/browse/FELIX-5856
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Runtime
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.runtime-1.1.0
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-5856) Coercion between Object[] and List
Guillaume Nodet created FELIX-5856: -- Summary: Coercion between Object[] and List Key: FELIX-5856 URL: https://issues.apache.org/jira/browse/FELIX-5856 Project: Felix Issue Type: Improvement Components: Gogo Runtime Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: gogo.runtime-1.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5855) Support array subscript in expander
[
https://issues.apache.org/jira/browse/FELIX-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5855.
Resolution: Fixed
{code:java}
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M gogo/runtime/src/main/java/org/apache/felix/gogo/runtime/Expander.java
M
gogo/runtime/src/test/java/org/apache/felix/gogo/runtime/ExpanderTest.java
Committed r1831770{code}
> Support array subscript in expander
> ---
>
> Key: FELIX-5855
> URL: https://issues.apache.org/jira/browse/FELIX-5855
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Runtime
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.runtime-1.1.0
>
>
> Expression such as {{$\{a[1]}}} do work on {{List}} but not an arrays.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (FELIX-5855) Support array subscript in expander
[
https://issues.apache.org/jira/browse/FELIX-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-5855:
---
Description: Expression such as {{$\{a[1]}}} do work on {{List}} but not an
arrays.
> Support array subscript in expander
> ---
>
> Key: FELIX-5855
> URL: https://issues.apache.org/jira/browse/FELIX-5855
> Project: Felix
> Issue Type: Improvement
> Components: Gogo Runtime
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: gogo.runtime-1.1.0
>
>
> Expression such as {{$\{a[1]}}} do work on {{List}} but not an arrays.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
