[PR] [IO-832] fix package links [commons-io]
elharo opened a new pull request, #588: URL: https://github.com/apache/commons-io/pull/588 @garydgregory -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-832) Update first section of home page
[ https://issues.apache.org/jira/browse/IO-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817581#comment-17817581 ] Elliotte Rusty Harold commented on IO-832: -- Links go to https://commons.apache.org/proper/commons-io/apidocs/index.html?org/apache/commons/io/serialization/package-summary.html but should go to https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/serialization/package-summary.html Might be incorrect relative links > Update first section of home page > - > > Key: IO-832 > URL: https://issues.apache.org/jira/browse/IO-832 > Project: Commons IO > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > Attachments: image-2023-12-29-13-43-31-816.png > > > !image-2023-12-29-13-43-31-816.png! > 1. There are more than six areas. > 2. All the links for sub-packages end up on the > https://commons.apache.org/proper/commons-io/apidocs/index.html page even > though the link tries to go deeper -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817498#comment-17817498
]
Gary D. Gregory edited comment on TEXT-233 at 2/14/24 10:23 PM:
See also
* [https://github.com/bndtools/bnd/issues/544]
* https://issues.apache.org/jira/browse/FELIX-4626
Reproducer:
{noformat}
git clone https://gitbox.apache.org/repos/asf/commons-text.git
git checkout 1001fb35902e52f1c19442a197a5ff914f7d8432
mvn clean verify
unzip -p target/commons-text-1.11.1-SNAPSHOT.jar META-INF/MANIFEST.MF
{noformat}
was (Author: garydgregory):
See also
* [https://github.com/bndtools/bnd/issues/544]
* https://issues.apache.org/jira/browse/FELIX-4626
Reproducer:
{noformat}
git clone [https://gitbox.apache.org/repos/asf/commons-text.git]
git checkout 1001fb35902e52f1c19442a197a5ff914f7d8432
mvn clean verify
unzip -p target/commons-text-1.11.1-SNAPSHOT.jar META-INF/MANIFEST.MF
{noformat}
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
> satisfied by that package and resolve and link its import-package requirement
> against the 3.12.0 version.
> So when loading these OSGi bundles, all will look fine. The OSGi will nicely
> resolve everything without complaining at this point.
> However in the above example environment, maybe much much later, when at a
> given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g.
> some of the StringEscapeUtils method being called by user code) is invoked,
> then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0
> version of the Range class in its classpath. It will try to invoke the method
> Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
> the Range class.
> Which will fail with a NoSuchMethodError:
>
> {noformat}
> java.lang.NoSuchMethodError:
> org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
> at
> org.apache.commons.text.translate.NumericEntityEscaper.(NumericEntityEscaper.java:97)
> ~[?:?]{noformat}
>
> To avoid this, it is +required+ that
[jira] [Comment Edited] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817498#comment-17817498
]
Gary D. Gregory edited comment on TEXT-233 at 2/14/24 10:23 PM:
See also
* [https://github.com/bndtools/bnd/issues/544]
* https://issues.apache.org/jira/browse/FELIX-4626
Reproducer:
{noformat}
git clone [https://gitbox.apache.org/repos/asf/commons-text.git]
git checkout 1001fb35902e52f1c19442a197a5ff914f7d8432
mvn clean verify
unzip -p target/commons-text-1.11.1-SNAPSHOT.jar META-INF/MANIFEST.MF
{noformat}
was (Author: garydgregory):
See also
* https://github.com/bndtools/bnd/issues/544
* https://issues.apache.org/jira/browse/FELIX-4626
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
> satisfied by that package and resolve and link its import-package requirement
> against the 3.12.0 version.
> So when loading these OSGi bundles, all will look fine. The OSGi will nicely
> resolve everything without complaining at this point.
> However in the above example environment, maybe much much later, when at a
> given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g.
> some of the StringEscapeUtils method being called by user code) is invoked,
> then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0
> version of the Range class in its classpath. It will try to invoke the method
> Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
> the Range class.
> Which will fail with a NoSuchMethodError:
>
> {noformat}
> java.lang.NoSuchMethodError:
> org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
> at
> org.apache.commons.text.translate.NumericEntityEscaper.(NumericEntityEscaper.java:97)
> ~[?:?]{noformat}
>
> To avoid this, it is +required+ that the commons-text 1.11.0 *MANIFEST.MF*
> correctly specifies the minimally required version of the commons-lang3
> package in its Import-Package:
> E.g. by adding a version directive: *{{;version="3.13"}}* : in OSGi, 1 single
> version
[jira] [Commented] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817498#comment-17817498
]
Gary D. Gregory commented on TEXT-233:
--
See also
* https://github.com/bndtools/bnd/issues/544
* https://issues.apache.org/jira/browse/FELIX-4626
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
> satisfied by that package and resolve and link its import-package requirement
> against the 3.12.0 version.
> So when loading these OSGi bundles, all will look fine. The OSGi will nicely
> resolve everything without complaining at this point.
> However in the above example environment, maybe much much later, when at a
> given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g.
> some of the StringEscapeUtils method being called by user code) is invoked,
> then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0
> version of the Range class in its classpath. It will try to invoke the method
> Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
> the Range class.
> Which will fail with a NoSuchMethodError:
>
> {noformat}
> java.lang.NoSuchMethodError:
> org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
> at
> org.apache.commons.text.translate.NumericEntityEscaper.(NumericEntityEscaper.java:97)
> ~[?:?]{noformat}
>
> To avoid this, it is +required+ that the commons-text 1.11.0 *MANIFEST.MF*
> correctly specifies the minimally required version of the commons-lang3
> package in its Import-Package:
> E.g. by adding a version directive: *{{;version="3.13"}}* : in OSGi, 1 single
> version number means a minimal version number, i.e. an open range 3.13.0 or
> higher.
> Example:
> {code:java}
> Import-Package:
> javax.script,javax.xml.xpath,org.apache.commons.lang3;version="3.13",or
> g.apache.commons.lang3.time;version="3.13",org.xml.sax{code}
> That way, when OSGi resolves commons-text 1.11.0, it will now only be
> satisifed by version 3.13 of those package, or higher, and therefore be
> guaranteed to link its
[jira] [Comment Edited] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817445#comment-17817445
]
K P edited comment on TEXT-233 at 2/14/24 4:40 PM:
---
I've been searching around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property? (I couldn't verify this yet...)
was (Author: belpk):
I've been search around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property?
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
>
[jira] [Commented] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
[
https://issues.apache.org/jira/browse/TEXT-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817445#comment-17817445
]
K P commented on TEXT-233:
--
I've been search around a bit more:
[https://cwiki.apache.org/confluence/display/commons/commonsosgi]
The above page explains the possibility for a component (e.g. commons-text, I
guess) to override certain directives, by overruling the Maven pom property
"commons.osgi.import" (which default to *)
I've found an override example in commons-configuration2,
[https://github.com/apache/commons-configuration/blob/master/pom.xml,] where
the pom.xml overrides the wildcard with some explicit manual imports (in the
case of configuration2 with the intention to add an optional resolution
directive to some imports, not to add a version number), but I think it would
be a similar approach to fix commons-text3, specifying something like:
{code:java}
org.apache.commons.lang3;version="3.13",
org.apache.commons.lang3.time;version="3.13",
*{code}
as customized commons.osgi.import property?
> Missing OSGi import-package commons-lang3 version can make commons-text
> unusable in OSGi
>
>
> Key: TEXT-233
> URL: https://issues.apache.org/jira/browse/TEXT-233
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.11.0
>Reporter: K P
>Priority: Major
>
> Since commons-text 1.11.0, there's commons-text codes that requires the
> presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
> this requirement is not enforced due to shortcoming an the commons-text
> 1.11.0 MANIFEST.MF, which may lead to unpredictable, uncontrollable failure
> when trying to use commons-text 1.11.0.
> Some more detail:
> Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
> *Range.{_}+of+{_}(...)* in commons-lang3 :
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.of(below, above);
> this.between = between;
> }{code}
>
> Method Range.of(...) was added in *commons-lang3 3.13.0* :
>
> {code:java}
> * @since 3.13.0
> */
> public static > Range of(final T
> fromInclusive, final T toInclusive) {{code}
>
> Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use
> of the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now
> marked as deprecated since commons-lang3 3.13.0)
>
> {code:java}
> private NumericEntityEscaper(final int below, final int above, final boolean
> between) {
> this.range = Range.between(below, above);
> this.between = between;
> }{code}
>
> This is all fine in a non-OSGi environment.
>
> However, to always resolve this correctly in an OSGi environment, some
> essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
> The commons-text 1.11.0 declares the following *Import-Package* in its
> manifest:
>
> {noformat}
> Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
> g.apache.commons.lang3.time,org.xml.sax
> {noformat}
> Notice how this indeed imports the required package
> "{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
> version number{+}.
> When an OSGi package is not qualified by a version number or version range,
> then during package resolution, OSGi may resolve this import against whatever
> version of commons-lang3 it can find and that exports this package.
> In other words, because there's no version restriction in this import as far
> as OSGi is concerned : if you have an OSGi environment where also an older
> version older version of commons-lang3 is already present, e.g. commons-lang
> "3.12.0", then the import-package of commons-text 1.11.0 will happily be
> satisfied by that package and resolve and link its import-package requirement
> against the 3.12.0 version.
> So when loading these OSGi bundles, all will look fine. The OSGi will nicely
> resolve everything without complaining at this point.
> However in the above example environment, maybe much much later, when at a
> given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g.
> some of the StringEscapeUtils method being called by user code) is invoked,
> then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0
> version of the Range class in its classpath. It will try to invoke the method
> Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
> the Range class.
> Which will fail with a NoSuchMethodError:
>
> {noformat}
> java.lang.NoSuchMethodError:
> org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
> at
>
[jira] [Created] (TEXT-233) Missing OSGi import-package commons-lang3 version can make commons-text unusable in OSGi
K P created TEXT-233:
Summary: Missing OSGi import-package commons-lang3 version can
make commons-text unusable in OSGi
Key: TEXT-233
URL: https://issues.apache.org/jira/browse/TEXT-233
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.11.0
Reporter: K P
Since commons-text 1.11.0, there's commons-text codes that requires the
presence of commons-lang3 3.13.0 or higher. However, in an OSGi environment,
this requirement is not enforced due to shortcoming an the commons-text 1.11.0
MANIFEST.MF, which may lead to unpredictable, uncontrollable failure when
trying to use commons-text 1.11.0.
Some more detail:
Since commons-text 1.11.0, the NumericEntityEscaper makes uses of the method
*Range.{_}+of+{_}(...)* in commons-lang3 :
{code:java}
private NumericEntityEscaper(final int below, final int above, final boolean
between) {
this.range = Range.of(below, above);
this.between = between;
}{code}
Method Range.of(...) was added in *commons-lang3 3.13.0* :
{code:java}
* @since 3.13.0
*/
public static > Range of(final T
fromInclusive, final T toInclusive) {{code}
Previously, in commons-text 1.10.0 or earlier, NumericEntityEscaper made use of
the the commons-lang3 method *Range.{_}+between+{_}(...)* (which is now marked
as deprecated since commons-lang3 3.13.0)
{code:java}
private NumericEntityEscaper(final int below, final int above, final boolean
between) {
this.range = Range.between(below, above);
this.between = between;
}{code}
This is all fine in a non-OSGi environment.
However, to always resolve this correctly in an OSGi environment, some
essential information is missing in the commons-text 1.11.0 {*}MANIFEST.MF{*}.
The commons-text 1.11.0 declares the following *Import-Package* in its manifest:
{noformat}
Import-Package: javax.script,javax.xml.xpath,org.apache.commons.lang3,or
g.apache.commons.lang3.time,org.xml.sax
{noformat}
Notice how this indeed imports the required package
"{_}org.apache.commons.lang3{_}", but this import {+}is not qualified with a
version number{+}.
When an OSGi package is not qualified by a version number or version range,
then during package resolution, OSGi may resolve this import against whatever
version of commons-lang3 it can find and that exports this package.
In other words, because there's no version restriction in this import as far as
OSGi is concerned : if you have an OSGi environment where also an older version
older version of commons-lang3 is already present, e.g. commons-lang "3.12.0",
then the import-package of commons-text 1.11.0 will happily be satisfied by
that package and resolve and link its import-package requirement against the
3.12.0 version.
So when loading these OSGi bundles, all will look fine. The OSGi will nicely
resolve everything without complaining at this point.
However in the above example environment, maybe much much later, when at a
given moment a user of the 1.11.0 commons-text NumericEntityEscaper (e.g. some
of the StringEscapeUtils method being called by user code) is invoked,
then that commons-text 1.11.0 NumericEntityEscaper will see the 3.12.0 version
of the Range class in its classpath. It will try to invoke the method
Range.of(...) ... but this method didn't exist yet in this 3.12.0 version of
the Range class.
Which will fail with a NoSuchMethodError:
{noformat}
java.lang.NoSuchMethodError:
org.apache.commons.lang3.Range.of(Ljava/lang/Comparable;Ljava/lang/Comparable;)Lorg/apache/commons/lang3/Range;
at
org.apache.commons.text.translate.NumericEntityEscaper.(NumericEntityEscaper.java:97)
~[?:?]{noformat}
To avoid this, it is +required+ that the commons-text 1.11.0 *MANIFEST.MF*
correctly specifies the minimally required version of the commons-lang3 package
in its Import-Package:
E.g. by adding a version directive: *{{;version="3.13"}}* : in OSGi, 1 single
version number means a minimal version number, i.e. an open range 3.13.0 or
higher.
Example:
{code:java}
Import-Package:
javax.script,javax.xml.xpath,org.apache.commons.lang3;version="3.13",or
g.apache.commons.lang3.time;version="3.13",org.xml.sax{code}
That way, when OSGi resolves commons-text 1.11.0, it will now only be satisifed
by version 3.13 of those package, or higher, and therefore be guaranteed to
link its org.apache.commons.lang3 Import-Package against the package from
commons-lang3 3.13.0 or higher.
Then at runtime, whenever the NumericEntityEscaper calls a method on the Range
class, it sees a 3.13.0 (or higher) version of the Range class, where the
method Range.of(...) exists.
(Note: a manifst example from another Apache Project:
this snippet is from the MANIFEST.MF of the Apache Velocity Engine jar:
{code:java}
Import-Package: javax.naming,javax.sql,org.apache.commons.lang3;versio
n="[3.11,4)",
{code}
Notice how they've specified a version range, which
Re: [PR] CLI-322: Add '-' as an option char and implemented extensive tests [commons-cli]
garydgregory merged PR #217: URL: https://github.com/apache/commons-cli/pull/217 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] CLI-323: Added Supplier defaults for getParsedOptionValue [commons-cli]
garydgregory commented on code in PR #229:
URL: https://github.com/apache/commons-cli/pull/229#discussion_r1489662879
##
src/test/java/org/apache/commons/cli/CommandLineTest.java:
##
@@ -166,7 +166,27 @@ public void testGetParsedOptionValueWithOption() throws
Exception {
}
@Test
-public void testNullhOption() throws Exception {
+public void testGetParsedOptionValueUsingDefault() throws Exception {
+final Options options = new Options();
+final Option optI =
Option.builder("i").hasArg().type(Number.class).build();
+final Option optF = Option.builder("f").hasArg().build();
+options.addOption(optI);
+options.addOption(optF);
+
+final CommandLineParser parser = new DefaultParser();
+final CommandLine cmd = parser.parse(options, new String[] {"-i",
"123"});
+
+assertEquals(123, ((Number)
cmd.getParsedOptionValue(optI)).intValue());
+assertEquals("foo", cmd.getParsedOptionValue(optF, "foo"));
+assertEquals("foo", cmd.getParsedOptionValue(optF, ()-> "foo"));
Review Comment:
`() -> ...`
##
src/main/java/org/apache/commons/cli/CommandLine.java:
##
@@ -437,15 +452,27 @@ public T getParsedOptionValue(final Option option)
throws ParseException {
* @see PatternOptionBuilder
* @since 1.7.0
*/
-@SuppressWarnings("unchecked")
public T getParsedOptionValue(final Option option, final T
defaultValue) throws ParseException {
-if (option == null) {
-return null;
-}
-final String res = getOptionValue(option);
+return getParsedOptionValue(option, () -> defaultValue);
+}
+
+/**
+ * Gets a version of this {@code Option} converted to a particular type.
+ *
+ * @param option the name of the option.
+ * @param defaultValue the default value to return if opt is not set.
+ * @param The return type for the method.
+ * @return the value parsed into a particular object.
+ * @throws ParseException if there are problems turning the option value
into the desired type
+ * @see PatternOptionBuilder
+ * @since 1.7.0
+ */
+@SuppressWarnings("unchecked")
+public T getParsedOptionValue(final Option option, final Supplier
defaultValue) throws ParseException {
+final String res = option == null ? null : getOptionValue(option);
try {
-return res == null ? defaultValue : (T)
option.getConverter().apply(res);
+return res == null ? defaultValue.get() : (T)
option.getConverter().apply(res);
Review Comment:
Hi @Claudenw
You're missing a test for when `defaultValue` is null.
##
src/main/java/org/apache/commons/cli/CommandLine.java:
##
@@ -423,7 +438,7 @@ public T getParsedOptionValue(final char opt, final T
defaultValue) throws P
* @since 1.5.0
*/
public T getParsedOptionValue(final Option option) throws
ParseException {
-return getParsedOptionValue(option, null);
+return getParsedOptionValue(option, ()-> null);
Review Comment:
Missing a space after `()`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] CLI-324 Make adding OptionGroups and Options to existing Options easier [commons-cli]
garydgregory commented on code in PR #230:
URL: https://github.com/apache/commons-cli/pull/230#discussion_r1489658135
##
src/main/java/org/apache/commons/cli/Options.java:
##
@@ -231,8 +243,9 @@ public OptionGroup getOptionGroup(final Option opt) {
* Gets the OptionGroups that are members of this Options instance.
*
* @return a Collection of OptionGroup instances.
+ * @since 1.7.0
*/
-Collection getOptionGroups() {
+public Collection getOptionGroups() {
Review Comment:
Hello @Claudenw
The typing needs some thought I think if make this public:
- First, do we really want this to be public?
- Why are we filtering out duplicates here?
- If we indeed want to return a Set, why hide this and type the return as a
Collection.
Consider:
- Changing the return type to a Set
- Changing the wrapping to an ArrayList
Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] CLI-312 fix [commons-cli]
garydgregory commented on code in PR #233:
URL: https://github.com/apache/commons-cli/pull/233#discussion_r1489645584
##
src/main/java/org/apache/commons/cli/DefaultParser.java:
##
@@ -228,6 +228,9 @@ private DefaultParser(final boolean allowPartialMatching,
*/
private void checkRequiredArgs() throws ParseException {
if (currentOption != null && currentOption.requiresArg()) {
+if (isJavaProperty(currentOption.getKey()) &&
currentOption.getValues().length == 1) {
Review Comment:
Hi @Claudenw
I think you are missing a test case to account for `Option#getValues()`
returning `null`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] CLI-320: Awkward behavior of Option.builder() for multiple optional args [commons-cli]
Claudenw commented on PR #206: URL: https://github.com/apache/commons-cli/pull/206#issuecomment-1943475593 @aherbert or @garydgregory The failure on the build for this is the old Java-22 issue. I rebased this on top of one of my changes and there were no issues. I think this can be merged without rebasing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] CLI-323: Added Supplier defaults for getParsedOptionValue [commons-cli]
Claudenw commented on PR #229: URL: https://github.com/apache/commons-cli/pull/229#issuecomment-1943316591 I think I have this fixed now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
