[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694515#comment-17694515
]
Elliotte Rusty Harold commented on MNG-7701:
final vs sp is a different case than previously shown and likely involves a
different code path because of the special casing text you cite. I'll take a
look when I get a minute, though I would prefer to treat this as a separate
bug.
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7714) sp == final
Elliotte Rusty Harold created MNG-7714:
--
Summary: sp == final
Key: MNG-7714
URL: https://issues.apache.org/jira/browse/MNG-7714
Project: Maven
Issue Type: Bug
Reporter: Elliotte Rusty Harold
It is easy to demonstrate that this is not fixed and also not in line with the
spec, with just this one important example (yes this does break for us):
$ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
[1
versus
$ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, [1]
As you can see, our `sp` release is now ordered after our `final` release
despite this clear text in the "spec":
Non-numeric tokens ("qualifiers") have the alphabetical order, except for
the following tokens which come first in this order: "alpha" < "beta" <
"milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
It's clear that this tokenization isn't really correct by any reasonable
measurement, and breaking large amounts of (our) existing artifacts in the wild
is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-7714:
---
Summary: sp < final (was: sp == final)
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MNG-7714:
--
Assignee: Elliotte Rusty Harold
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-7714:
---
Description:
Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
The claim is that sp < final, which if true is incorrect according to spec.
It is easy to demonstrate that this is not fixed and also not in line with the
spec, with just this one important example (yes this does break for us):
$ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
[1
versus
$ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, [1]
As you can see, our `sp` release is now ordered after our `final` release
despite this clear text in the "spec":
Non-numeric tokens ("qualifiers") have the alphabetical order, except for
the following tokens which come first in this order: "alpha" < "beta" <
"milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
It's clear that this tokenization isn't really correct by any reasonable
measurement, and breaking large amounts of (our) existing artifacts in the wild
is definitely not OK.
was:
It is easy to demonstrate that this is not fixed and also not in line with the
spec, with just this one important example (yes this does break for us):
$ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
[1
versus
$ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
1.0.sp1-redhat-0001
Display parameters as parsed by Maven (in canonical form and as a list of
tokens) and comparison result:
1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, [1]
As you can see, our `sp` release is now ordered after our `final` release
despite this clear text in the "spec":
Non-numeric tokens ("qualifiers") have the alphabetical order, except for
the following tokens which come first in this order: "alpha" < "beta" <
"milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
It's clear that this tokenization isn't really correct by any reasonable
measurement, and breaking large amounts of (our) existing artifacts in the wild
is definitely not OK.
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695687#comment-17695687
]
Elliotte Rusty Harold commented on MNG-7714:
I can reproduce this. Specifically,
"final" < "sp" // correct
"final" < "sp1" // correct
"1.0.final-redhat-0001" < "1.0.sp-redhat-0001" // correct
"1.0.final-redhat-0001" > "1.0.sp1-redhat-0001" // likely incorrect,
investigating
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695690#comment-17695690
]
Elliotte Rusty Harold commented on MNG-7714:
also correctly handled:
"1.0.final-redhat-0001" < "1.0.sp.1-redhat-0001"
"1.0.final-redhat-0001" < "1.0.sp-1-redhat-0001"
so it might be something in the splitting that screws this up. E.g. maybe sp1
is getting parsed as "sp1" instead of "sp-1"
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695697#comment-17695697
]
Elliotte Rusty Harold commented on MNG-7714:
"1.0.final" < "1.0.sp1"
However
1.0.final-redhat > "1.0.sp1-redhat" // incorrect
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695704#comment-17695704
]
Elliotte Rusty Harold commented on MNG-7714:
somehow in the failing cases we end up comparing redhat on the left to sp on
the right, like the iteration is off. (Assuming I'm reading the debugger
correctly)
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695739#comment-17695739
]
Elliotte Rusty Harold commented on MNG-6825:
Both org.codehaus.plexus.util.StringUtils and maven-shared-utils should go
away. In many cases we can simply use the JDK. Otherwise the better choice is
org.apache.commons.lang3.StringUtils as it's actively supported, which is more
than we can say for plexus utils and maven-shared-utils. Generally we need to
get away from the idea that generic utilities should be implemented in maven
itself. They are better handled by Apache Commons, which focuses on those
things and is used and tested far beyond Maven.
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695800#comment-17695800
]
Elliotte Rusty Harold commented on MNG-6825:
Feel free to throw any reviews my way. I do prefer smaller reviews. They tend
not to be drop in replacements since null checking particular can vary from one
line of code to the next. E.g. sometimes a StringUtils.isEmpty replacement
needs to include a null check and sometime it doesn't if the string has already
been dereferenced previously. We don't really have tooling to perform a lot of
these modifications at scale, so if you do what you can when you can,
eventually we'll get it done.
https://google.github.io/eng-practices/review/developer/small-cls.html
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696438#comment-17696438
]
Elliotte Rusty Harold commented on MNG-7714:
https://github.com/apache/maven/pull/929 is likely involved
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696441#comment-17696441
]
Elliotte Rusty Harold commented on MNG-7714:
This is proving quite ugly. I can see the issue, but I can't easily fix it,
much less without breaking other things. It seems to have to do with 1.0.sp
getting parsed into [1, [sp]] instead of [1, sp]. Meanwhile 1.0.final-redhat
gets parsed into [1, [redhat]] so redhat gets compared to sp.
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MSHARED-848) Code Improvement in ReaderFactory to get rid of commons-io dependency
[
https://issues.apache.org/jira/browse/MSHARED-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MSHARED-848:
-
Assignee: Elliotte Rusty Harold
> Code Improvement in ReaderFactory to get rid of commons-io dependency
> -
>
> Key: MSHARED-848
> URL: https://issues.apache.org/jira/browse/MSHARED-848
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.3
>Reporter: Karl Heinz Marbaise
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
> Currently the dependency to:
> {code:xml}
>
> commons-io
> commons-io
> 2.6
>
> {code}
> is only needed within the class {{ReaderFactory}} which imports
> {{org.apache.commons.io.input.XmlStreamReader}}.
> The question: Can that be replaced with something different? In consequence
> we could get rid of the dependency on {{commons-io}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1195) Set JDK 8 to minimum
Elliotte Rusty Harold created MSHARED-1195: -- Summary: Set JDK 8 to minimum Key: MSHARED-1195 URL: https://issues.apache.org/jira/browse/MSHARED-1195 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-io Reporter: Elliotte Rusty Harold This is necessary to update other dependencies such as commons-io to more secure versions, and matches the rest of Maven -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1195) Set minimum JDK to 8
[ https://issues.apache.org/jira/browse/MSHARED-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-1195: --- Summary: Set minimum JDK to 8 (was: Set JDK 8 to minimum) > Set minimum JDK to 8 > > > Key: MSHARED-1195 > URL: https://issues.apache.org/jira/browse/MSHARED-1195 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > This is necessary to update other dependencies such as commons-io to more > secure versions, and matches the rest of Maven -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1195) Set JDK 8 to minimum
[ https://issues.apache.org/jira/browse/MSHARED-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MSHARED-1195: -- Assignee: Elliotte Rusty Harold > Set JDK 8 to minimum > > > Key: MSHARED-1195 > URL: https://issues.apache.org/jira/browse/MSHARED-1195 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > This is necessary to update other dependencies such as commons-io to more > secure versions, and matches the rest of Maven -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHARED-1195) Set minimum JDK to 8
[ https://issues.apache.org/jira/browse/MSHARED-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1195. Resolution: Fixed > Set minimum JDK to 8 > > > Key: MSHARED-1195 > URL: https://issues.apache.org/jira/browse/MSHARED-1195 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > This is necessary to update other dependencies such as commons-io to more > secure versions, and matches the rest of Maven -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1195) Set minimum JDK to 8
[ https://issues.apache.org/jira/browse/MSHARED-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1195. -- > Set minimum JDK to 8 > > > Key: MSHARED-1195 > URL: https://issues.apache.org/jira/browse/MSHARED-1195 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > This is necessary to update other dependencies such as commons-io to more > secure versions, and matches the rest of Maven -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1196) Bump maven-shared-components from 37 to 39
Elliotte Rusty Harold created MSHARED-1196: -- Summary: Bump maven-shared-components from 37 to 39 Key: MSHARED-1196 URL: https://issues.apache.org/jira/browse/MSHARED-1196 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-utils Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697662#comment-17697662 ] Elliotte Rusty Harold commented on MNG-7724: Warning seems the right level notice here. If someone is treating this as an error, that's their choice and problem, not ours. > Slf4jConfigurationFactory should use info level when there is no exception > and the logger type is unknown > - > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-7724. Resolution: Not A Problem > Slf4jConfigurationFactory should use info level when there is no exception > and the logger type is unknown > - > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-7724. -- > Slf4jConfigurationFactory should use info level when there is no exception > and the logger type is unknown > - > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697888#comment-17697888 ] Elliotte Rusty Harold commented on MNG-7724: One more time: if a project chooses to fail on *warnings* that's there issue, not ours. We should not adjust our code to suit their idiosyncratic code bureaucracy. It sounds like maybe this shouldn't log at all. That is, this issue is simply not a problem. The code runs fine. If so, turn it off completely. But if it is a problem, then make it a warning, not info. > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-338) Drop FileTransform API
[ https://issues.apache.org/jira/browse/MRESOLVER-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697894#comment-17697894 ] Elliotte Rusty Harold commented on MRESOLVER-338: - This should not be done in 1.10.0. If we're dropping API, make it 2.0. > Drop FileTransform API > -- > > Key: MRESOLVER-338 > URL: https://issues.apache.org/jira/browse/MRESOLVER-338 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > As this will streamline things from impl through connector and transport. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697939#comment-17697939 ] Elliotte Rusty Harold commented on MNG-7724: I've heard the claim that "You must change your open source project because we see a warning, and our build requires no warnings" many times on many projects, hardly just Maven. It's a flat out bad idea. Warnings are warnings and not errors for a reason. I have no sympathy for this request. > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697946#comment-17697946 ] Elliotte Rusty Harold commented on MNG-7724: The code in question is a bit of a mess. I think UnsupportedSlf4jBindingConfiguration.activate should be a no-op and the warning, if any, belongs in Slf4jConfigurationFactory.getConfigurationFactory. However my gut is this shouldn't even be a warning. I'd accept no warning at all here, or just maybe a debug level warning. Info is too high. > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697950#comment-17697950 ] Elliotte Rusty Harold commented on MNG-7724: Also we shouldn't call ex.printStackTrace in Slf4jConfigurationFactory.getConfigurationFactory. The catch block maybe should log a warning (though that's a potentially different warning than we're logging now, and more actionable). Or perhaps this should be at debug level? But UnsupportedSlf4jBindingConfiguration should not log anything. > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPOM-200) remove Apache Resource Bundles parent POM
[ https://issues.apache.org/jira/browse/MPOM-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697981#comment-17697981 ] Elliotte Rusty Harold commented on MPOM-200: On first glance, I'm thoroughly confused about what's happening here or being proposed. That doesn't mean you shouldn't do it, just that I'm probably missing a lot of context and can't offer an informed review right now. I'll try to spend a little more time digging into this tonight or tomorrow. > remove Apache Resource Bundles parent POM > - > > Key: MPOM-200 > URL: https://issues.apache.org/jira/browse/MPOM-200 > Project: Maven POMs > Issue Type: Task >Affects Versions: MAVEN-32 >Reporter: Herve Boutemy >Priority: Major > > as part of Apache Resource Bundles migration to Git MASFRES-20 > source: > https://github.com/apache/maven-parent/tree/master/apache-resource-bundles > content in Central: > https://repo1.maven.org/maven2/org/apache/apache/resources/apache-resource-bundles/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-36) remove unnecessary CLI code
[ https://issues.apache.org/jira/browse/MWRAPPER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698113#comment-17698113 ] Elliotte Rusty Harold commented on MWRAPPER-36: --- This is used. E.g. here: https://github.com/apache/maven-wrapper/blob/8a1ded6cc4de5b2c9e238efe84ae122fdd8db050/maven-wrapper/src/main/java/org/apache/maven/wrapper/MavenWrapperMain.java#L32 It could perhaps be replaced with some other library, though it's public API so a deprecation cycle might be needed. > remove unnecessary CLI code > --- > > Key: MWRAPPER-36 > URL: https://issues.apache.org/jira/browse/MWRAPPER-36 > Project: Maven Wrapper > Issue Type: Wish > Components: Maven Wrapper Jar >Affects Versions: 0.5.6 >Reporter: Herve Boutemy >Assignee: Robert Scholte >Priority: Major > > CLI code seems unnecessary: > https://github.com/apache/maven-wrapper/tree/abb74e20115252cfa6d9b50fc7ba286c103b452d/src/main/java/org/apache/maven/wrapper/cli -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-100) maven-shared-utils is unused
Elliotte Rusty Harold created MWRAPPER-100: -- Summary: maven-shared-utils is unused Key: MWRAPPER-100 URL: https://issues.apache.org/jira/browse/MWRAPPER-100 Project: Maven Wrapper Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-100) maven-shared-utils is unused
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698114#comment-17698114 ] Elliotte Rusty Harold commented on MWRAPPER-100: and other issues: [WARNING] Used undeclared dependencies found: [WARNING]org.apache.maven:maven-settings:jar:3.2.5:provided [WARNING]javax.inject:javax.inject:jar:1:compile [WARNING]org.codehaus.plexus:plexus-io:jar:3.4.1:compile [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:provided [WARNING] Unused declared dependencies found: [WARNING] org.apache.maven.wrapper:maven-wrapper-distribution:pom:3.2.1-SNAPSHOT:test > maven-shared-utils is unused > > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-100) Declare needed dependencies
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MWRAPPER-100: --- Summary: Declare needed dependencies (was: maven-shared-utils is unused) > Declare needed dependencies > --- > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-100) maven-shared-utils is unused
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698122#comment-17698122 ] Elliotte Rusty Harold commented on MWRAPPER-100: Missed one. It is used, but a bit of dependency cleanup is needed. > maven-shared-utils is unused > > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1201) Deprecate Xpp3Dom.isNonEmpty and isEmpty
Elliotte Rusty Harold created MSHARED-1201: -- Summary: Deprecate Xpp3Dom.isNonEmpty and isEmpty Key: MSHARED-1201 URL: https://issues.apache.org/jira/browse/MSHARED-1201 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-utils Reporter: Elliotte Rusty Harold Yet more random public String utility methods -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7729) Deprecate Xpp3Dom.isNonEmpty and isEmpty
Elliotte Rusty Harold created MNG-7729: -- Summary: Deprecate Xpp3Dom.isNonEmpty and isEmpty Key: MNG-7729 URL: https://issues.apache.org/jira/browse/MNG-7729 Project: Maven Issue Type: Task Reporter: Elliotte Rusty Harold And yet again copy pasta of random string utility methods that are public and should never have been here -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1201) Deprecate Xpp3Dom.isNonEmpty and isEmpty
[ https://issues.apache.org/jira/browse/MSHARED-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698611#comment-17698611 ] Elliotte Rusty Harold commented on MSHARED-1201: If these are only recently added remove them completely. > Deprecate Xpp3Dom.isNonEmpty and isEmpty > > > Key: MSHARED-1201 > URL: https://issues.apache.org/jira/browse/MSHARED-1201 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > Yet more random public String utility methods -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7730) delete maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java /
Elliotte Rusty Harold created MNG-7730: -- Summary: delete maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java / Key: MNG-7730 URL: https://issues.apache.org/jira/browse/MNG-7730 Project: Maven Issue Type: Bug Reporter: Elliotte Rusty Harold maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java / Doesn't seem to be used, and this shouldn't be a runtime exception anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7727) Remove the implementation of DefaultMavenProfilesBuilder#buildProfiles
[
https://issues.apache.org/jira/browse/MNG-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698900#comment-17698900
]
Elliotte Rusty Harold commented on MNG-7727:
simply returning null is a half-measure. Either delete the class or leave it as
is.
> Remove the implementation of DefaultMavenProfilesBuilder#buildProfiles
> --
>
> Key: MNG-7727
> URL: https://issues.apache.org/jira/browse/MNG-7727
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-5
>
>
> Going through the usage of the plexus-utils {{ReaderFactory}} in maven, the
> {{DefaultMavenProfilesBuilder#buildProfiles}} method suffers from possible
> encoding/BOM problems. Removing this code would get rid of a few
> dependencies on plexus-utils.
> This class is deprecated since 2009. I don't think there are any code
> actually using this method, and such usage would have to deal with a null
> return value anyway, so it should be perfectly safe to just always return
> null.
> See https://github.com/apache/maven/pull/1044
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MWRAPPER-100) Declare needed dependencies
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MWRAPPER-100: -- Assignee: Elliotte Rusty Harold > Declare needed dependencies > --- > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MWRAPPER-100) Declare needed dependencies
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MWRAPPER-100. -- > Declare needed dependencies > --- > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MWRAPPER-100) Declare needed dependencies
[ https://issues.apache.org/jira/browse/MWRAPPER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MWRAPPER-100. Resolution: Fixed > Declare needed dependencies > --- > > Key: MWRAPPER-100 > URL: https://issues.apache.org/jira/browse/MWRAPPER-100 > Project: Maven Wrapper > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7727) Remove the implementation of DefaultMavenProfilesBuilder#buildProfiles
[
https://issues.apache.org/jira/browse/MNG-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698915#comment-17698915
]
Elliotte Rusty Harold commented on MNG-7727:
If we can remove more, great.
> Remove the implementation of DefaultMavenProfilesBuilder#buildProfiles
> --
>
> Key: MNG-7727
> URL: https://issues.apache.org/jira/browse/MNG-7727
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-5
>
>
> Going through the usage of the plexus-utils {{ReaderFactory}} in maven, the
> {{DefaultMavenProfilesBuilder#buildProfiles}} method suffers from possible
> encoding/BOM problems. Removing this code would get rid of a few
> dependencies on plexus-utils.
> This class is deprecated since 2009. I don't think there are any code
> actually using this method, and such usage would have to deal with a null
> return value anyway, so it should be perfectly safe to just always return
> null.
> See https://github.com/apache/maven/pull/1044
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7732) org.codehaus.plexus.util.xml package shouldn't be in core
Elliotte Rusty Harold created MNG-7732: -- Summary: org.codehaus.plexus.util.xml package shouldn't be in core Key: MNG-7732 URL: https://issues.apache.org/jira/browse/MNG-7732 Project: Maven Issue Type: Bug Reporter: Elliotte Rusty Harold Repackage, shade, or remove as needed. Including that package in the maven-xml-impl artifact risks classpath conflicts everywhere and split package issues in JDK 9+ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7729) Deprecate Xpp3Dom.isNonEmpty and isEmpty
[ https://issues.apache.org/jira/browse/MNG-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MNG-7729: -- Assignee: Elliotte Rusty Harold > Deprecate Xpp3Dom.isNonEmpty and isEmpty > > > Key: MNG-7729 > URL: https://issues.apache.org/jira/browse/MNG-7729 > Project: Maven > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > And yet again copy pasta of random string utility methods that are public and > should never have been here -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2118) surefire-report xml format not compliant with xsi for test failing in all of the re-runs
[
https://issues.apache.org/jira/browse/SUREFIRE-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699207#comment-17699207
]
Elliotte Rusty Harold commented on SUREFIRE-2118:
-
Do you have a repro? Just a guess, but perhaps nothing was output to System.out
in the case where it's not included. If something was output and it's not
included, then that is a bug.
> surefire-report xml format not compliant with xsi for test failing in all of
> the re-runs
>
>
> Key: SUREFIRE-2118
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2118
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin,
> xml generation
>Affects Versions: 3.0.0-M7
>Reporter: Yamini
>Priority: Major
>
> We expect the format of surefire .xml report for test failing in all rerun to
> be as mentioned in
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html#:~:text=2)-,The%20test%20fails%20in%20all%20of%20the%20re%2Druns%3A,-failure%20and%20error]
>
> But, I can see the following format for my run
> rerunFailingTestsCount = 2
> {code:java}
>
> first failure stack trace
>
> rerun failure stack trace
>
>
> rerun failure stack trace
> rerun failure
>
> {code}
> we have only one in last rerunFailure. is missing
> under and first
>
> surefire-plugin
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M7
>
>
> org.apache.maven.surefire
> surefire-junit47
> 3.0.0-M7
>
>
>
>
>
> true
>
> all
> 4
> 1C
> ${tests.groups}
> 2
>
> {code}
>
> Why is it not compliant? Can the issue be fixed?
> Please let me know if you need any more information.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1202) Bump maven-shared-components from 37 to 39
Elliotte Rusty Harold created MSHARED-1202: -- Summary: Bump maven-shared-components from 37 to 39 Key: MSHARED-1202 URL: https://issues.apache.org/jira/browse/MSHARED-1202 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-io Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7736) MavenXpp3Reader exposes Codehaus Plexus in exception signature
Elliotte Rusty Harold created MNG-7736: -- Summary: MavenXpp3Reader exposes Codehaus Plexus in exception signature Key: MNG-7736 URL: https://issues.apache.org/jira/browse/MNG-7736 Project: Maven Issue Type: Improvement Reporter: Elliotte Rusty Harold The read methods in this class all throw org.codehaus.plexus.util.xml.pull.XmlPullParserException which then leaks into a lot of plugins. I'm not yet sure exactly how to resolve this, but these methods (or replacements?) should throw an exception that is from this package or another Maven core package or perhaps the JDK itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7736) MavenXpp3Reader exposes Codehaus Plexus in exception signature
[ https://issues.apache.org/jira/browse/MNG-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699222#comment-17699222 ] Elliotte Rusty Harold commented on MNG-7736: javax.xml.stream.XMLStreamException is one possibility that's been in the JDK since 1.6 > MavenXpp3Reader exposes Codehaus Plexus in exception signature > -- > > Key: MNG-7736 > URL: https://issues.apache.org/jira/browse/MNG-7736 > Project: Maven > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > The read methods in this class all throw > org.codehaus.plexus.util.xml.pull.XmlPullParserException which then leaks > into a lot of plugins. > I'm not yet sure exactly how to resolve this, but these methods (or > replacements?) should throw an exception that is from this package or another > Maven core package or perhaps the JDK itself. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699224#comment-17699224
]
Elliotte Rusty Harold commented on MNG-7655:
I'm OK with keeping the artifact ID org.apache.maven:plexus-utils
I am not OK with keeping the package names the same. The current work seems
likely to cause major problems with split packages in JDK 9+ and classpath
conflicts and dimaond dependency problems in all JDKs.
https://jlbp.dev/JLBP-6
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-7724. -- > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-7724. Resolution: Fixed > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699334#comment-17699334
]
Elliotte Rusty Harold commented on MNG-7655:
You can only keep them as is by leaving the package names, class name AND maven
coordinates the same. If you change the Maven coordinates (group ID, artifact
ID) but leave the fully qualified class name the same, users will experience
broken builds and bugs due to classpath conflicts, diamond dependency problems,
and loading unexpected versions of the classes.
I understand that it might be necessary not to change the package name, but in
that case they have to be published in the same artifact.
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-746) Remove netware code
[ https://issues.apache.org/jira/browse/MJAVADOC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MJAVADOC-746: -- Assignee: Elliotte Rusty Harold > Remove netware code > --- > > Key: MJAVADOC-746 > URL: https://issues.apache.org/jira/browse/MJAVADOC-746 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > Netware is long dead. See JavadocUtil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAVADOC-746) Remove netware code
Elliotte Rusty Harold created MJAVADOC-746: -- Summary: Remove netware code Key: MJAVADOC-746 URL: https://issues.apache.org/jira/browse/MJAVADOC-746 Project: Maven Javadoc Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold Netware is long dead. See JavadocUtil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-746) Remove netware code
[ https://issues.apache.org/jira/browse/MJAVADOC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699404#comment-17699404 ] Elliotte Rusty Harold commented on MJAVADOC-746: Per wikipedia, "The final update release was version 6.5SP8 of May 2009; NetWare is no longer on Novell's product list.[3] NetWare 6.5SP8 General Support ended in 2010; Extended Support was available until the end of 2015, and Self Support until the end of 2017." > Remove netware code > --- > > Key: MJAVADOC-746 > URL: https://issues.apache.org/jira/browse/MJAVADOC-746 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > Netware is long dead. See JavadocUtil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1203) Use Files.createSymbolicLink from Java 7
Elliotte Rusty Harold created MSHARED-1203: -- Summary: Use Files.createSymbolicLink from Java 7 Key: MSHARED-1203 URL: https://issues.apache.org/jira/browse/MSHARED-1203 Project: Maven Shared Components Issue Type: Improvement Components: file-management Reporter: Elliotte Rusty Harold Instead of the massive hack in FileSetUtilsTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MNG-7730) delete maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java /
[ https://issues.apache.org/jira/browse/MNG-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-7730. Resolution: Fixed > delete > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > > > Key: MNG-7730 > URL: https://issues.apache.org/jira/browse/MNG-7730 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > Doesn't seem to be used, and this shouldn't be a runtime exception anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7730) delete maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java /
[ https://issues.apache.org/jira/browse/MNG-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MNG-7730: -- Assignee: Elliotte Rusty Harold > delete > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > > > Key: MNG-7730 > URL: https://issues.apache.org/jira/browse/MNG-7730 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > Doesn't seem to be used, and this shouldn't be a runtime exception anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7730) delete maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java /
[ https://issues.apache.org/jira/browse/MNG-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-7730. -- > delete > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > > > Key: MNG-7730 > URL: https://issues.apache.org/jira/browse/MNG-7730 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > maven/maven-xml-impl/src/main/java/org/apache/maven/internal/xml/MavenXmlException.java > / > Doesn't seem to be used, and this shouldn't be a runtime exception anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7738) Remove printStackTrace
Elliotte Rusty Harold created MNG-7738: -- Summary: Remove printStackTrace Key: MNG-7738 URL: https://issues.apache.org/jira/browse/MNG-7738 Project: Maven Issue Type: Bug Reporter: Elliotte Rusty Harold There are multiple places in core where the code simply calls ex.printStackTrace() or equivalent, usually in a catch block, instead of going through the logging framework. This produces ugly, uncontrollable, often duplicate output. Remove or replace these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7655) rename Maven core's plexus-utils to more explicit artifactId
[
https://issues.apache.org/jira/browse/MNG-7655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699583#comment-17699583
]
Elliotte Rusty Harold commented on MNG-7655:
You're right. You can't (well, shouldn't) change either group ID or artifact ID
without changing the package or class name as well. General principle of Java:
do not put the same class in two different jars in the classpath. Maven and
Gradle can keep this from happening when the different jars have the same group
ID and artifact ID but not when those are changed.
In Java 9+ the rules get even stronger. You shouldn't put different classes
from the same package in two different jars. I'm not sure if the Maven class
loader will avoid this problem for Maven, but it absolutely does not for any
other project that does not use the Maven class loader but does depend on these
artifacts.
It is not simply the Maven core classloader that is affected here, but every
project that depends on any of these dependencies, whether it uses Maven or
not.
https://jlbp.dev/JLBP-6
> rename Maven core's plexus-utils to more explicit artifactId
>
>
> Key: MNG-7655
> URL: https://issues.apache.org/jira/browse/MNG-7655
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Herve Boutemy
>Priority: Major
>
> in https://github.com/apache/maven/pull/829 , Maven's internal plexus-utils
> repackaging is used, switching from Plexus original
> {{org.codehaus.plexus:plexus-utils}} to {{org.apache.maven:plexus-utils}}
> this switch keeping the exact same artifactId but just changing only the
> groupId is confusing: we need another artifactId
> {{maven-plexus-utils}}?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7738) Remove printStackTrace
[ https://issues.apache.org/jira/browse/MNG-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699868#comment-17699868 ] Elliotte Rusty Harold commented on MNG-7738: org.apache.maven.toolchain.RequirementMatchFactory is one class. I've seen at least one other. Slf4jConfigurationFactory I think. grep should find them. > Remove printStackTrace > -- > > Key: MNG-7738 > URL: https://issues.apache.org/jira/browse/MNG-7738 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > There are multiple places in core where the code simply calls > ex.printStackTrace() or equivalent, usually in a catch block, instead of > going through the logging framework. This produces ugly, uncontrollable, > often duplicate output. Remove or replace these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1117) Normalize line endings doesn't respect encoding
Elliotte Rusty Harold created MRELEASE-1117:
---
Summary: Normalize line endings doesn't respect encoding
Key: MRELEASE-1117
URL: https://issues.apache.org/jira/browse/MRELEASE-1117
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Elliotte Rusty Harold
This chunk of code in ReleaseUtil could be seriously broken in the event of a
confusion between single and multibyte encodings. It's not a straight-forward
fix and might require some rethinking of the API.
```
public static String readXmlFile(File file, String ls) throws IOException {
try (Reader reader = ReaderFactory.newXmlReader(file)) {
return normalizeLineEndings(IOUtil.toString(reader), ls);
}
}
/**
* Normalizes the line separators in the specified string.
*
* @param text The string to normalize, may be null.
* @param separator The line separator to use for normalization, typically
"\n" or "\r\n", must not be
*null.
* @return The input string with normalized line separators or
null if the string was null
* .
*/
public static String normalizeLineEndings(String text, String separator) {
String norm = text;
if (text != null) {
norm = text.replaceAll("(\r\n)|(\n)|(\r)", separator);
}
return norm;
}
```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-746) Remove netware code
[ https://issues.apache.org/jira/browse/MJAVADOC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJAVADOC-746. Resolution: Fixed > Remove netware code > --- > > Key: MJAVADOC-746 > URL: https://issues.apache.org/jira/browse/MJAVADOC-746 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > Netware is long dead. See JavadocUtil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-746) Remove netware code
[ https://issues.apache.org/jira/browse/MJAVADOC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJAVADOC-746. -- > Remove netware code > --- > > Key: MJAVADOC-746 > URL: https://issues.apache.org/jira/browse/MJAVADOC-746 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > Netware is long dead. See JavadocUtil -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1204) Consider special casing slf4j-simple et al
Elliotte Rusty Harold created MSHARED-1204: -- Summary: Consider special casing slf4j-simple et al Key: MSHARED-1204 URL: https://issues.apache.org/jira/browse/MSHARED-1204 Project: Maven Shared Components Issue Type: New Feature Components: maven-dependency-analyzer Reporter: Elliotte Rusty Harold slf4j-simple is sometimes added to classpaths to shut up annoying warnings from SLF4J at run and test time, even though it isn't absolutely required. Can we do better with our analysis of the common case and similar ones, rather than reporting it as declared but unused? ``` org.slf4j slf4j-simple test ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1204) Consider special casing slf4j-simple et al
[ https://issues.apache.org/jira/browse/MSHARED-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701109#comment-17701109 ] Elliotte Rusty Harold commented on MSHARED-1204: mvn-compat is another one that can in fact be required, even more strongly than slf4j-simple, but the analyzer misreports as unused > Consider special casing slf4j-simple et al > -- > > Key: MSHARED-1204 > URL: https://issues.apache.org/jira/browse/MSHARED-1204 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Elliotte Rusty Harold >Priority: Major > > slf4j-simple is sometimes added to classpaths to shut up annoying warnings > from SLF4J at run and test time, even though it isn't absolutely required. > Can we do better with our analysis of the common case and similar ones, > rather than reporting it as declared but unused? > ``` > > org.slf4j > slf4j-simple > test > > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SCM-1007) XML encoding detection bugs
Elliotte Rusty Harold created SCM-1007: -- Summary: XML encoding detection bugs Key: SCM-1007 URL: https://issues.apache.org/jira/browse/SCM-1007 Project: Maven SCM Issue Type: Bug Reporter: Elliotte Rusty Harold In https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java and possibly elsewhere Should use an InputStream and let the parser detect the encoding instead of a reader that always picks the system wncoding, regardless of what the file uses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1117) Normalize line endings doesn't respect encoding
[
https://issues.apache.org/jira/browse/MRELEASE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701203#comment-17701203
]
Elliotte Rusty Harold commented on MRELEASE-1117:
-
normalizeLineEndings is OK. readXmlFile is not. It does not properly detect the
encoding of the XML file so the string it creates can be wrong
> Normalize line endings doesn't respect encoding
> ---
>
> Key: MRELEASE-1117
> URL: https://issues.apache.org/jira/browse/MRELEASE-1117
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> This chunk of code in ReleaseUtil could be seriously broken in the event of a
> confusion between single and multibyte encodings. It's not a straight-forward
> fix and might require some rethinking of the API.
> ```
> public static String readXmlFile(File file, String ls) throws IOException
> {
> try (Reader reader = ReaderFactory.newXmlReader(file)) {
> return normalizeLineEndings(IOUtil.toString(reader), ls);
> }
> }
> /**
> * Normalizes the line separators in the specified string.
> *
> * @param text The string to normalize, may be null.
> * @param separator The line separator to use for normalization,
> typically "\n" or "\r\n", must not be
> *null.
> * @return The input string with normalized line separators or
> null if the string was null
> * .
> */
> public static String normalizeLineEndings(String text, String separator) {
> String norm = text;
> if (text != null) {
> norm = text.replaceAll("(\r\n)|(\n)|(\r)", separator);
> }
> return norm;
> }
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRELEASE-1117) ReleaseUtil.readXmlFile doesn't respect encoding
[
https://issues.apache.org/jira/browse/MRELEASE-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MRELEASE-1117:
Summary: ReleaseUtil.readXmlFile doesn't respect encoding (was: Normalize
line endings doesn't respect encoding)
> ReleaseUtil.readXmlFile doesn't respect encoding
>
>
> Key: MRELEASE-1117
> URL: https://issues.apache.org/jira/browse/MRELEASE-1117
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> This chunk of code in ReleaseUtil could be seriously broken in the event of a
> confusion between single and multibyte encodings. It's not a straight-forward
> fix and might require some rethinking of the API.
> ```
> public static String readXmlFile(File file, String ls) throws IOException
> {
> try (Reader reader = ReaderFactory.newXmlReader(file)) {
> return normalizeLineEndings(IOUtil.toString(reader), ls);
> }
> }
> /**
> * Normalizes the line separators in the specified string.
> *
> * @param text The string to normalize, may be null.
> * @param separator The line separator to use for normalization,
> typically "\n" or "\r\n", must not be
> *null.
> * @return The input string with normalized line separators or
> null if the string was null
> * .
> */
> public static String normalizeLineEndings(String text, String separator) {
> String norm = text;
> if (text != null) {
> norm = text.replaceAll("(\r\n)|(\n)|(\r)", separator);
> }
> return norm;
> }
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SCM-1008) Undeclare unused dependencies
Elliotte Rusty Harold created SCM-1008: -- Summary: Undeclare unused dependencies Key: SCM-1008 URL: https://issues.apache.org/jira/browse/SCM-1008 Project: Maven SCM Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold Some of these are probably needed but loaded through mechanisms maven-dependency-analyzer doesn't catch, notably org.apache.maven:maven-compat, but some of them should be able to be removed [WARNING] Unused declared dependencies found: [WARNING]org.apache.maven:maven-artifact:jar:3.2.5:provided [WARNING]org.apache.maven:maven-compat:jar:3.2.5:provided [WARNING] org.apache.maven.scm:maven-scm-manager-plexus:jar:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-providers-standard:pom:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-provider-local:jar:2.0.1-SNAPSHOT:runtime [WARNING]org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0:runtime [WARNING]junit:junit:jar:4.13.2:test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SCM-1008) Undeclare unused dependencies
[ https://issues.apache.org/jira/browse/SCM-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701312#comment-17701312 ] Elliotte Rusty Harold commented on SCM-1008: in scm-git-provider ``` [WARNING] Used undeclared dependencies found: [WARNING]org.apache.sshd:sshd-osgi:jar:2.7.0:compile [WARNING]javax.annotation:javax.annotation-api:jar:1.2:test [WARNING] Unused declared dependencies found: [WARNING]org.slf4j:jcl-over-slf4j:jar:1.7.36:runtime [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [WARNING]org.apache.maven.scm:maven-scm-test:jar:2.0.1-SNAPSHOT:test [WARNING] Non-test scoped test only dependencies found: [WARNING]org.apache.sshd:sshd-osgi:jar:2.7.0:compile ``` > Undeclare unused dependencies > - > > Key: SCM-1008 > URL: https://issues.apache.org/jira/browse/SCM-1008 > Project: Maven SCM > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > Some of these are probably needed but loaded through mechanisms > maven-dependency-analyzer doesn't catch, notably > org.apache.maven:maven-compat, but some of them should be able to be removed > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.2.5:provided > [WARNING]org.apache.maven:maven-compat:jar:3.2.5:provided > [WARNING] > org.apache.maven.scm:maven-scm-manager-plexus:jar:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-providers-standard:pom:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-provider-local:jar:2.0.1-SNAPSHOT:runtime > [WARNING]org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0:runtime > [WARNING]junit:junit:jar:4.13.2:test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SCM-1008) Undeclare unused dependencies
[ https://issues.apache.org/jira/browse/SCM-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701311#comment-17701311 ] Elliotte Rusty Harold commented on SCM-1008: also in maven-scm-providers ``` [WARNING] Used undeclared dependencies found: [WARNING]org.apache.sshd:sshd-common:jar:2.9.2:compile [WARNING]org.bouncycastle:bcprov-jdk15on:jar:1.70:compile [WARNING]org.apache.sshd:sshd-core:jar:2.9.2:compile ``` > Undeclare unused dependencies > - > > Key: SCM-1008 > URL: https://issues.apache.org/jira/browse/SCM-1008 > Project: Maven SCM > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > Some of these are probably needed but loaded through mechanisms > maven-dependency-analyzer doesn't catch, notably > org.apache.maven:maven-compat, but some of them should be able to be removed > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.2.5:provided > [WARNING]org.apache.maven:maven-compat:jar:3.2.5:provided > [WARNING] > org.apache.maven.scm:maven-scm-manager-plexus:jar:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-providers-standard:pom:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-provider-local:jar:2.0.1-SNAPSHOT:runtime > [WARNING]org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0:runtime > [WARNING]junit:junit:jar:4.13.2:test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SCM-1008) Undeclare unused dependencies
[ https://issues.apache.org/jira/browse/SCM-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701314#comment-17701314 ] Elliotte Rusty Harold commented on SCM-1008: in scm client ``` [WARNING] Unused declared dependencies found: [WARNING] org.apache.maven.scm:maven-scm-manager-plexus:jar:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-provider-gitexe:jar:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-provider-hg:jar:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-provider-local:jar:2.0.1-SNAPSHOT:runtime [WARNING] org.apache.maven.scm:maven-scm-provider-svnexe:jar:2.0.1-SNAPSHOT:runtime [WARNING]org.codehaus.plexus:plexus-classworlds:jar:2.6.0:runtime [WARNING]org.codehaus.plexus:plexus-component-annotations:jar:2.1.1:runtime [WARNING]com.google.inject:guice:jar:no_aop:4.2.3:runtim ``` > Undeclare unused dependencies > - > > Key: SCM-1008 > URL: https://issues.apache.org/jira/browse/SCM-1008 > Project: Maven SCM > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Minor > > Some of these are probably needed but loaded through mechanisms > maven-dependency-analyzer doesn't catch, notably > org.apache.maven:maven-compat, but some of them should be able to be removed > [WARNING] Unused declared dependencies found: > [WARNING]org.apache.maven:maven-artifact:jar:3.2.5:provided > [WARNING]org.apache.maven:maven-compat:jar:3.2.5:provided > [WARNING] > org.apache.maven.scm:maven-scm-manager-plexus:jar:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-providers-standard:pom:2.0.1-SNAPSHOT:runtime > [WARNING] > org.apache.maven.scm:maven-scm-provider-local:jar:2.0.1-SNAPSHOT:runtime > [WARNING]org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0:runtime > [WARNING]junit:junit:jar:4.13.2:test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SCM-1007) XML encoding detection bugs
[ https://issues.apache.org/jira/browse/SCM-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated SCM-1007: --- Description: In https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java and possibly elsewhere Should use an InputStream and let the parser detect the encoding instead of a reader that always picks the system encoding, regardless of what the file uses. was: In https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java and possibly elsewhere Should use an InputStream and let the parser detect the encoding instead of a reader that always picks the system wncoding, regardless of what the file uses. > XML encoding detection bugs > --- > > Key: SCM-1007 > URL: https://issues.apache.org/jira/browse/SCM-1007 > Project: Maven SCM > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > In > https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java > and possibly elsewhere > Should use an InputStream and let the parser detect the encoding instead of a > reader that always picks the system encoding, regardless of what the file > uses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SCM-1007) XML encoding detection bugs
[ https://issues.apache.org/jira/browse/SCM-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved SCM-1007. Resolution: Invalid Digging into the code this is doing a better job at encoding detection than I initially thought. > XML encoding detection bugs > --- > > Key: SCM-1007 > URL: https://issues.apache.org/jira/browse/SCM-1007 > Project: Maven SCM > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > In > https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java > and possibly elsewhere > Should use an InputStream and let the parser detect the encoding instead of a > reader that always picks the system encoding, regardless of what the file > uses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SCM-1007) XML encoding detection bugs
[ https://issues.apache.org/jira/browse/SCM-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed SCM-1007. -- > XML encoding detection bugs > --- > > Key: SCM-1007 > URL: https://issues.apache.org/jira/browse/SCM-1007 > Project: Maven SCM > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > In > https://github.com/apache/maven-scm/blob/ee41988fc7cdc818a070c346039d9156c8d97ec9/maven-scm-providers/maven-scm-provider-local/src/main/java/org/apache/maven/scm/provider/local/metadata/LocalScmMetadataUtils.java > and possibly elsewhere > Should use an InputStream and let the parser detect the encoding instead of a > reader that always picks the system encoding, regardless of what the file > uses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7738) Remove printStackTrace
[ https://issues.apache.org/jira/browse/MNG-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MNG-7738: -- Assignee: Elliotte Rusty Harold > Remove printStackTrace > -- > > Key: MNG-7738 > URL: https://issues.apache.org/jira/browse/MNG-7738 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > There are multiple places in core where the code simply calls > ex.printStackTrace() or equivalent, usually in a catch block, instead of > going through the logging framework. This produces ugly, uncontrollable, > often duplicate output. Remove or replace these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEPLOY-266) More verbose output for deployment to trace down errors (esp. 401)
[ https://issues.apache.org/jira/browse/MDEPLOY-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703603#comment-17703603 ] Elliotte Rusty Harold commented on MDEPLOY-266: --- "In that place it should be possible to log a warning when the password is empty/null." This sounds to me like this case should be an exception thrown up the chain, not a simple log statement. Same thing for empty/null username. Logging a non-null username might help. > More verbose output for deployment to trace down errors (esp. 401) > -- > > Key: MDEPLOY-266 > URL: https://issues.apache.org/jira/browse/MDEPLOY-266 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.8.2 >Reporter: Jörg Hohwiller >Priority: Major > > There are many reasons why a deployment of maven artifacts can fail: > * network error > * error on server side in repo server > * no login configured > * wrong login configured > * no password configured > * wrong password configured (password may be encrypted so even almost > impossible to determine) > * repository ID in distribution-management and server ID in settings.xml do > not match > * etc. > It is really hard to check all the possibilities (please note that the > distributionManagement may be configured in a parent^N pom and out of sight > so you need to print the effective-pom. Many Maven users even do not have a > clue how to do that). However, maven-deploy-plugin only prints that the > deployment failed and an HTTP status code (typically 401). But this is very > little information. Tons of users are therefore waisting their own time and > especially also the time of others (e.g. OSSRH team) to trace down the reason. > It should be trivial for maven-deploy-plugin to log some more information: > * ID of repository that deployment is going to use > * whether a server tag from settings.xml could be resolved for this ID > * the login that is used for the deployment or a WARNING if login is > undefined > * WARNING if password is undefined (obviously you should not log the > password) > With this simple information users could save many hours/days of valuable > time to trace down errors more easily. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MNG-7738) Remove printStackTrace
[ https://issues.apache.org/jira/browse/MNG-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-7738. Resolution: Fixed > Remove printStackTrace > -- > > Key: MNG-7738 > URL: https://issues.apache.org/jira/browse/MNG-7738 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > There are multiple places in core where the code simply calls > ex.printStackTrace() or equivalent, usually in a catch block, instead of > going through the logging framework. This produces ugly, uncontrollable, > often duplicate output. Remove or replace these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7738) Remove printStackTrace
[ https://issues.apache.org/jira/browse/MNG-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-7738. -- > Remove printStackTrace > -- > > Key: MNG-7738 > URL: https://issues.apache.org/jira/browse/MNG-7738 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > There are multiple places in core where the code simply calls > ex.printStackTrace() or equivalent, usually in a catch block, instead of > going through the logging framework. This produces ugly, uncontrollable, > often duplicate output. Remove or replace these. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MEJB-134) Update parent pom to 39
Elliotte Rusty Harold created MEJB-134: -- Summary: Update parent pom to 39 Key: MEJB-134 URL: https://issues.apache.org/jira/browse/MEJB-134 Project: Maven EJB Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MEJB-33) Add support for fewer dependencies in client-jars
[ https://issues.apache.org/jira/browse/MEJB-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MEJB-33: - Assignee: Elliotte Rusty Harold > Add support for fewer dependencies in client-jars > - > > Key: MEJB-33 > URL: https://issues.apache.org/jira/browse/MEJB-33 > Project: Maven EJB Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: tinne >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: more-investigation > > Attachments: ejb-client-packaging-problem-2014.zip, > ejb-client-packaging-problem.zip, make-client-separate.patch > > > Given a scenario, where several application tiers are installed on different > servers, are realized as EJB3 applications, and packaged using maven. > When configuring an ejb module, I give dependencies to all dependency jars > that are used to implement the features. However, they are currently all > added as dependency to the client-jar artifacts as well, so that unused > libraries are deployed on client servers. > I'd like to mark dependencies as server-jar only, e.g. by an > clientJarExclusions configuration element to the plugin, which takes a set of > exclusion elements like the exclusions-element in a dependency. These > dependencies should behave as compile-scope in the server- and provided-scope > in the client-jars. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MEJB-33) Add support for fewer dependencies in client-jars
[ https://issues.apache.org/jira/browse/MEJB-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MEJB-33: - Assignee: (was: Elliotte Rusty Harold) > Add support for fewer dependencies in client-jars > - > > Key: MEJB-33 > URL: https://issues.apache.org/jira/browse/MEJB-33 > Project: Maven EJB Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: tinne >Priority: Major > Fix For: more-investigation > > Attachments: ejb-client-packaging-problem-2014.zip, > ejb-client-packaging-problem.zip, make-client-separate.patch > > > Given a scenario, where several application tiers are installed on different > servers, are realized as EJB3 applications, and packaged using maven. > When configuring an ejb module, I give dependencies to all dependency jars > that are used to implement the features. However, they are currently all > added as dependency to the client-jar artifacts as well, so that unused > libraries are deployed on client servers. > I'd like to mark dependencies as server-jar only, e.g. by an > clientJarExclusions configuration element to the plugin, which takes a set of > exclusion elements like the exclusions-element in a dependency. These > dependencies should behave as compile-scope in the server- and provided-scope > in the client-jars. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MEJB-134) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MEJB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MEJB-134: -- Assignee: Elliotte Rusty Harold > Update parent pom to 39 > --- > > Key: MEJB-134 > URL: https://issues.apache.org/jira/browse/MEJB-134 > Project: Maven EJB Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MEJB-134) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MEJB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MEJB-134. -- > Update parent pom to 39 > --- > > Key: MEJB-134 > URL: https://issues.apache.org/jira/browse/MEJB-134 > Project: Maven EJB Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MEJB-134) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MEJB-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MEJB-134. Resolution: Fixed > Update parent pom to 39 > --- > > Key: MEJB-134 > URL: https://issues.apache.org/jira/browse/MEJB-134 > Project: Maven EJB Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1214) SVN tag in pom.xml
Elliotte Rusty Harold created MSHARED-1214:
--
Summary: SVN tag in pom.xml
Key: MSHARED-1214
URL: https://issues.apache.org/jira/browse/MSHARED-1214
Project: Maven Shared Components
Issue Type: Dependency upgrade
Components: maven-filtering
Reporter: Elliotte Rusty Harold
Although the current release version is 3.3.1 I see this in pm.xml at head:
```
scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
maven-filtering-3.2.0
https://github.com/apache/maven-filtering/tree/${project.scm.tag}
```
Probably we should just detag this info since it isn't kept up to date and
simply point to head like most projects do.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MSHARED-1196) Bump maven-shared-components from 37 to 39
[ https://issues.apache.org/jira/browse/MSHARED-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1196. Resolution: Fixed > Bump maven-shared-components from 37 to 39 > -- > > Key: MSHARED-1196 > URL: https://issues.apache.org/jira/browse/MSHARED-1196 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DOXIA-698) org.apache.maven.doxia.sink.Sink should implement AutoCloseable
[ https://issues.apache.org/jira/browse/DOXIA-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned DOXIA-698: --- Assignee: Elliotte Rusty Harold > org.apache.maven.doxia.sink.Sink should implement AutoCloseable > --- > > Key: DOXIA-698 > URL: https://issues.apache.org/jira/browse/DOXIA-698 > Project: Maven Doxia > Issue Type: New Feature >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1196) Bump maven-shared-components from 37 to 39
[ https://issues.apache.org/jira/browse/MSHARED-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1196. -- > Bump maven-shared-components from 37 to 39 > -- > > Key: MSHARED-1196 > URL: https://issues.apache.org/jira/browse/MSHARED-1196 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHARED-1202) Bump maven-shared-components from 37 to 39
[ https://issues.apache.org/jira/browse/MSHARED-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1202. Resolution: Fixed > Bump maven-shared-components from 37 to 39 > -- > > Key: MSHARED-1202 > URL: https://issues.apache.org/jira/browse/MSHARED-1202 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1202) Bump maven-shared-components from 37 to 39
[ https://issues.apache.org/jira/browse/MSHARED-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1202. -- > Bump maven-shared-components from 37 to 39 > -- > > Key: MSHARED-1202 > URL: https://issues.apache.org/jira/browse/MSHARED-1202 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-io >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1215) Deprecate maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java
Elliotte Rusty Harold created MSHARED-1215: -- Summary: Deprecate maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java Key: MSHARED-1215 URL: https://issues.apache.org/jira/browse/MSHARED-1215 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-utils Reporter: Elliotte Rusty Harold In favor of https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/SystemUtils.html which is not a drop-in replacement, but is better supported, better designed, and has more modern operating systems -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1214) SVN tag in pom.xml
[
https://issues.apache.org/jira/browse/MSHARED-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704988#comment-17704988
]
Elliotte Rusty Harold commented on MSHARED-1214:
if it's auto-populated why is it maven-filtering-3.2.0 instead of 3.3.1? Does
this point to a bug in maven release?
> SVN tag in pom.xml
> --
>
> Key: MSHARED-1214
> URL: https://issues.apache.org/jira/browse/MSHARED-1214
> Project: Maven Shared Components
> Issue Type: Dependency upgrade
> Components: maven-filtering
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Although the current release version is 3.3.1 I see this in pm.xml at head:
> ```
>
>
> scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
>
> scm:git:https://gitbox.apache.org/repos/asf/maven-filtering.git
> maven-filtering-3.2.0
>
> https://github.com/apache/maven-filtering/tree/${project.scm.tag}
>
> ```
> Probably we should just detag this info since it isn't kept up to date and
> simply point to head like most projects do.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704989#comment-17704989
]
Elliotte Rusty Harold commented on MNG-7714:
```
@Test
public void testMng7714() {
ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");
ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");
assertTrue(greater.compareTo( lesser ) > 0);
}
```
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704989#comment-17704989
]
Elliotte Rusty Harold edited comment on MNG-7714 at 3/25/23 10:01 PM:
--
Failing test:
{{@Test
public void testMng7714() {
ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");
ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");
assertTrue(greater.compareTo( lesser ) > 0);
}}}
was (Author: elharo):
```
@Test
public void testMng7714() {
ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");
ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");
assertTrue(greater.compareTo( lesser ) > 0);
}
```
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704989#comment-17704989
]
Elliotte Rusty Harold edited comment on MNG-7714 at 3/25/23 10:01 PM:
--
Failing test:
{{@Test}}
{{public void testMng7714() { }}
{{ ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");}}
{{ ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");}}
{{ assertTrue(greater.compareTo( lesser ) > 0); }}
{{}}}
was (Author: elharo):
Failing test:
{{@Test
public void testMng7714() {
ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");
ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");
assertTrue(greater.compareTo( lesser ) > 0);
}}}
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704989#comment-17704989
]
Elliotte Rusty Harold edited comment on MNG-7714 at 3/25/23 10:02 PM:
--
Failing test:
{{@Test}}
public void testMng7714() \{ }}
{{ ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");}}
{{ ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");}}
assertTrue(greater.compareTo( lesser ) > 0); }}
{{}}}
was (Author: elharo):
Failing test:
{{@Test}}
{{public void testMng7714() { }}
{{ ComparableVersion lesser = new ComparableVersion("1.0.final-redhat");}}
{{ ComparableVersion greater = new ComparableVersion("1.0.sp1-redhat");}}
{{ assertTrue(greater.compareTo( lesser ) > 0); }}
{{}}}
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
