[jira] [Updated] (MSITE-945) Remove dependency on Commons IO
[ https://issues.apache.org/jira/browse/MSITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-945: - Fix Version/s: 4.0.0-M8 > Remove dependency on Commons IO > --- > > Key: MSITE-945 > URL: https://issues.apache.org/jira/browse/MSITE-945 > Project: Maven Site Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0-M8 > > > All uses look easily replaceable by standard JDK methods these days -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSITE-945) Remove dependency on Commons IO
[ https://issues.apache.org/jira/browse/MSITE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-945: - Summary: Remove dependency on Commons IO (was: Remove dependency on commons IO) > Remove dependency on Commons IO > --- > > Key: MSITE-945 > URL: https://issues.apache.org/jira/browse/MSITE-945 > Project: Maven Site Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > > All uses look easily replaceable by standard JDK methods these days -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-953) trimming can remove all whitespace
[ https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-953: Fix Version/s: maven-shared-utils-3.4.1 > trimming can remove all whitespace > -- > > Key: MSHARED-953 > URL: https://issues.apache.org/jira/browse/MSHARED-953 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: maven-shared-utils-3.4.1 > > > The trim parameter in buildDom methods in Xpp3DomBuilder is based on a > serious misunderstanding of how the characters method in SAX works. As > currently written, trim can potentially remove all whitespace in text content > from a document. A little more commonly, it will randomly remove or not > remove whitespace depending on how the SAX parser chooses to split text nodes > when it reports them. > It might be possible to implement this correctly at the cost of a lot of code > complexity if anyone is using this. More easily, we could make the parameter > a no-op and never trim. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717722#comment-17717722
]
Gary D. Gregory edited comment on MSHARED-1247 at 4/28/23 8:50 PM:
---
[~sjaranowski]
WRT ossfuzz/issue51980/Test.class:
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an {{IOException}},
then any error is logged and does not blow up the Maven run (the method already
throws {{IOException}}).
was (Author: garydgregory):
WRT ossfuzz/issue51980/Test.class:
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an {{IOException}},
then any error is logged and does not blow up the Maven run (the method already
throws {{IOException}}).
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at
[jira] [Commented] (MRESOLVER-358) Upgrade Guava, Maven, mockito, Plexus Utils
[ https://issues.apache.org/jira/browse/MRESOLVER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717800#comment-17717800 ] ASF GitHub Bot commented on MRESOLVER-358: -- slawekjaranowski commented on code in PR #284: URL: https://github.com/apache/maven-resolver/pull/284#discussion_r1180770118 ## maven-resolver-demos/pom.xml: ## @@ -38,7 +38,7 @@ -3.8.4 +3.8.8 Review Comment: There is IT in resolver-demo-maven-plugin which will fail when Maven < 3.8.8 will be used ... But we enforce minimal version as 3.8.4 > Upgrade Guava, Maven, mockito, Plexus Utils > --- > > Key: MRESOLVER-358 > URL: https://issues.apache.org/jira/browse/MRESOLVER-358 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Upgrades > * guava to 31.1-jre (was 30.1-jre) > * mockito-core to 4.11.0 (was 4.8.1) > * plexus-utils to 3.5.1 (was 3.5.0) > * maven deps (used in demos only) to 3.8.8 (was 3.8.4) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] slawekjaranowski commented on a diff in pull request #284: [MRESOLVER-358] Upgrade some dependencies
slawekjaranowski commented on code in PR #284: URL: https://github.com/apache/maven-resolver/pull/284#discussion_r1180770118 ## maven-resolver-demos/pom.xml: ## @@ -38,7 +38,7 @@ -3.8.4 +3.8.8 Review Comment: There is IT in resolver-demo-maven-plugin which will fail when Maven < 3.8.8 will be used ... But we enforce minimal version as 3.8.4 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
[
https://issues.apache.org/jira/browse/MENFORCER-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717795#comment-17717795
]
Slawomir Jaranowski commented on MENFORCER-479:
---
>From enforcer perspective {{3.8.4}} is equal to range {{[3.8.4,)}} it is
>different than standard Maven behavior where {{3.8.4}} means - recommended
>version.
Current messages are:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.3.0:enforce
(enforce-maven-version) on project apache:
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireMavenVersion
failed with message:
[ERROR] Detected Maven Version: 3.9.1 is not in the allowed range [3.10.1,).
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.3.0:enforce
(enforce-java-version) on project apache:
[ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion
failed with message:
[ERROR] Detected JDK version 20
(JAVA_HOME=/usr/local/Cellar/openjdk/20/libexec/openjdk.jdk/Contents/Home) is
not in the allowed range [22.2.1,).
{noformat}
> Version enforcer rules print single versions when a range is expected
> -
>
> Key: MENFORCER-479
> URL: https://issues.apache.org/jira/browse/MENFORCER-479
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Rule API
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> AbstractStandardEnforcerRule incorrectly assumes that the toString method of
> a VersionRange will be a version range. However it can be just a single
> version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717791#comment-17717791 ] ASF GitHub Bot commented on MRESOLVER-359: -- cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180733890 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: Hm, wait a second... seems am wrong: "[enforcer] redefined as a minimum version.". So did I misinterpret then? Still, I think if we provide (semantically) equivalent value, but in form of (maven and not "redefined enforcer") range, we are somehow clearer what we _really mean_ here. > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8u362 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #285: [MRESOLVER-359] Make build be explicit about build time requirements
cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180733890 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: Hm, wait a second... seems am wrong: "[enforcer] redefined as a minimum version.". So did I misinterpret then? Still, I think if we provide (semantically) equivalent value, but in form of (maven and not "redefined enforcer") range, we are somehow clearer what we _really mean_ here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717790#comment-17717790 ] ASF GitHub Bot commented on MRESOLVER-359: -- cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180731785 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) +[1.8.0-362,) Review Comment: Same as above, 1.8.0-362 is NOT the recommended Java 8, just _minimal_ we allow to build with. > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8u362 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #285: [MRESOLVER-359] Make build be explicit about build time requirements
cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180731785 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) +[1.8.0-362,) Review Comment: Same as above, 1.8.0-362 is NOT the recommended Java 8, just _minimal_ we allow to build with. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717789#comment-17717789 ] ASF GitHub Bot commented on MRESOLVER-359: -- cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180731396 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: Is not, see https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html "3.8.4" was "x >= 3.8.4 but 3.8.4 RECOMMENDED". This is not (semantically) what we _mean_. What we mean is "use minimally 3.8.4 or ANY NEWER". > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8u362 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #285: [MRESOLVER-359] Make build be explicit about build time requirements
cstamas commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180731396 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: Is not, see https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html "3.8.4" was "x >= 3.8.4 but 3.8.4 RECOMMENDED". This is not (semantically) what we _mean_. What we mean is "use minimally 3.8.4 or ANY NEWER". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717787#comment-17717787 ] ASF GitHub Bot commented on MRESOLVER-359: -- slawekjaranowski commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180727977 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) +[1.8.0-362,) Review Comment: Here can also be simple `1.8.0-362` ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: It is exactly the same - what is the reason for such change? > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8u362 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] slawekjaranowski commented on a diff in pull request #285: [MRESOLVER-359] Make build be explicit about build time requirements
slawekjaranowski commented on code in PR #285: URL: https://github.com/apache/maven-resolver/pull/285#discussion_r1180727977 ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) +[1.8.0-362,) Review Comment: Here can also be simple `1.8.0-362` ## pom.xml: ## @@ -93,7 +93,8 @@ 30.1-jre 1.0.1 1.7.36 -3.8.4 +[3.8.4,) Review Comment: It is exactly the same - what is the reason for such change? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
[ https://issues.apache.org/jira/browse/MENFORCER-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717754#comment-17717754 ] Elliotte Rusty Harold commented on MENFORCER-479: - Apparently 3.8.4 is interpreted as [3.8.4,) That might make sense for authoring purposes but I still think that's unclear output here. [3.8.4,) would be clearer UI, and "3.8.4 or later" would be better still. The purpose of this message is to communicate with the human developer, not to set a value. > Version enforcer rules print single versions when a range is expected > - > > Key: MENFORCER-479 > URL: https://issues.apache.org/jira/browse/MENFORCER-479 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Reporter: Elliotte Rusty Harold >Priority: Major > > AbstractStandardEnforcerRule incorrectly assumes that the toString method of > a VersionRange will be a version range. However it can be just a single > version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
[ https://issues.apache.org/jira/browse/MENFORCER-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717753#comment-17717753 ] Elliotte Rusty Harold commented on MENFORCER-479: - Whichever version is pulled in by head in maven-resolver right now, though looking at the source code for the enforcer rules and the Version Range class I'm pretty sure this is true at head unless someone fixed it today. > Version enforcer rules print single versions when a range is expected > - > > Key: MENFORCER-479 > URL: https://issues.apache.org/jira/browse/MENFORCER-479 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Reporter: Elliotte Rusty Harold >Priority: Major > > AbstractStandardEnforcerRule incorrectly assumes that the toString method of > a VersionRange will be a version range. However it can be just a single > version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (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 resolved MNG-7729. Resolution: Fixed > 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] [Closed] (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 closed MNG-7729. -- > 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)
[GitHub] [maven-mvnd] tbw777 commented on issue #793: java.lang.UnsatisfiedLinkError: Can't load library: jansi.dll
tbw777 commented on issue #793: URL: https://github.com/apache/maven-mvnd/issues/793#issuecomment-1527809399 1.0m6 C:\Users\Андрей>c:\mvnd\bin\mvnd.cmd -v Failed to load native library:jansi-2.4.0-7a1b3e95bab9e2b8-jansi.dll. osinfo: Windows/x86_64 java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\A4F7~1\AppData\Local\Temp\jansi-2.4.0-7a1b3e95bab9e2b8-jansi.dll Exception in thread "main" java.lang.UnsatisfiedLinkError: org.fusesource.jansi.internal.CLibrary.isatty(I)I [symbol: Java_org_fusesource_jansi_internal_CLibrary_isatty or Java_org_fusesource_jansi_internal_CLibrary_isatty__I] at org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:152) at org.graalvm.nativeimage.builder/com.oracle.svm.core.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:53) at org.fusesource.jansi.internal.CLibrary.isatty(CLibrary.java) at org.mvndaemon.mvnd.client.DefaultClient.main(DefaultClient.java:103) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-359: -- Description: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. Questions: * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, and then even after a year later (when possibly new Java 8 versions may be released), it is expected that u371 and later ones will still work. CI "answered" this for me, it uses Java 8 361 List of Java 8 releases [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] was: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. Questions: * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, and then even after a year later (when possibly new Java 8 versions may be released), it is expected that u371 and later ones will still work. List of Java 8 releases [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8 361 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-359: -- Description: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. Questions: * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, and then even after a year later (when possibly new Java 8 versions may be released), it is expected that u371 and later ones will still work. CI "answered" this for me, it uses Java 8u362 List of Java 8 releases [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] was: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. Questions: * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, and then even after a year later (when possibly new Java 8 versions may be released), it is expected that u371 and later ones will still work. CI "answered" this for me, it uses Java 8 361 List of Java 8 releases [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. CI > "answered" this for me, it uses Java 8u362 > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717722#comment-17717722
]
Gary D. Gregory edited comment on MSHARED-1247 at 4/28/23 3:22 PM:
---
WRT ossfuzz/issue51980/Test.class:
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an {{IOException}},
then any error is logged and does not blow up the Maven run (the method already
throws {{IOException}}).
was (Author: garydgregory):
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an {{IOException}},
then any error is logged and does not blow up the Maven run (the method already
throws {{IOException}}).
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.r
[jira] [Comment Edited] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717722#comment-17717722
]
Gary D. Gregory edited comment on MSHARED-1247 at 4/28/23 3:22 PM:
---
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an {{IOException}},
then any error is logged and does not blow up the Maven run (the method already
throws {{IOException}}).
was (Author: garydgregory):
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an IOException, then
any error is logged and does not blow up the Maven run (the method already
throws {{{}IOException{}}}).
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
>
[jira] [Comment Edited] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717722#comment-17717722
]
Gary D. Gregory edited comment on MSHARED-1247 at 4/28/23 3:21 PM:
---
A related problem is that
{{ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}} throws a
{{RuntimeException}} which is an anti-pattern; as opposed to an better
unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an IOException, then
any error is logged and does not blow up the Maven run (the method already
throws {{{}IOException{}}}).
was (Author: garydgregory):
A related problem is that
{{org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}}
throws a {{RuntimeException}} which is an anti-pattern; as opposed to an
better unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an IOException, then
any error is logged and does not blow up the Maven run (the method already
throws {{{}IOException{}}}).
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.Mojo
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717722#comment-17717722
]
Gary D. Gregory commented on MSHARED-1247:
--
A related problem is that
{{org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences(ByteBuffer)}}
throws a {{RuntimeException}} which is an anti-pattern; as opposed to an
better unchecked exception like {{{}IllegalArgumentException{}}},
{{{}IllegalStateException{}}}, or {{{}UncheckedIOException{}}}.
IIRC, if in the PR, I change {{ClassFileVisitorUtils.acceptDirectory(File,
ClassFileVisitor)}} to rethrow the {{RuntimeException}} as an IOException, then
any error is logged and does not blow up the Maven run (the method already
throws {{{}IOException{}}}).
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache
[jira] [Updated] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-357:
--
Priority: Blocker (was: Major)
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Blocker
> Fix For: 1.9.10
>
>
> As per user report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" than previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise.
> In fact, the check is wrong: it should check for same GA child count and not
> ANY child count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717718#comment-17717718
]
Gary D. Gregory commented on MSHARED-1247:
--
Hi [~sjaranowski]
Thank you for the quick feedback.
I added a test to the PR.
Yeah, {{cyclonedx}} I suppose a downstream project can depend on any jar
files test or not, and end up delivering it. That's the only reason I can
imagine for analyzing test code and resources.
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.
[jira] [Updated] (MRESOLVER-358) Upgrade Guava, Maven, mockito, Plexus Utils
[ https://issues.apache.org/jira/browse/MRESOLVER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-358: -- Component/s: Resolver > Upgrade Guava, Maven, mockito, Plexus Utils > --- > > Key: MRESOLVER-358 > URL: https://issues.apache.org/jira/browse/MRESOLVER-358 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Upgrades > * guava to 31.1-jre (was 30.1-jre) > * mockito-core to 4.11.0 (was 4.8.1) > * plexus-utils to 3.5.1 (was 3.5.0) > * maven deps (used in demos only) to 3.8.8 (was 3.8.4) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-359: -- Component/s: Resolver > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-359: - Assignee: Tamas Cservenak > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHARED-953) trimming can remove all whitespace
[ https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-953. --- Resolution: Fixed > trimming can remove all whitespace > -- > > Key: MSHARED-953 > URL: https://issues.apache.org/jira/browse/MSHARED-953 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > The trim parameter in buildDom methods in Xpp3DomBuilder is based on a > serious misunderstanding of how the characters method in SAX works. As > currently written, trim can potentially remove all whitespace in text content > from a document. A little more commonly, it will randomly remove or not > remove whitespace depending on how the SAX parser chooses to split text nodes > when it reports them. > It might be possible to implement this correctly at the cost of a lot of code > complexity if anyone is using this. More easily, we could make the parameter > a no-op and never trim. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-953) trimming can remove all whitespace
[ https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717715#comment-17717715 ] ASF GitHub Bot commented on MSHARED-953: elharo closed pull request #125: [MSHARED-953] Trim at end of element URL: https://github.com/apache/maven-shared-utils/pull/125 > trimming can remove all whitespace > -- > > Key: MSHARED-953 > URL: https://issues.apache.org/jira/browse/MSHARED-953 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > The trim parameter in buildDom methods in Xpp3DomBuilder is based on a > serious misunderstanding of how the characters method in SAX works. As > currently written, trim can potentially remove all whitespace in text content > from a document. A little more commonly, it will randomly remove or not > remove whitespace depending on how the SAX parser chooses to split text nodes > when it reports them. > It might be possible to implement this correctly at the cost of a lot of code > complexity if anyone is using this. More easily, we could make the parameter > a no-op and never trim. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-953) trimming can remove all whitespace
[ https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717714#comment-17717714 ] ASF GitHub Bot commented on MSHARED-953: elharo merged PR #124: URL: https://github.com/apache/maven-shared-utils/pull/124 > trimming can remove all whitespace > -- > > Key: MSHARED-953 > URL: https://issues.apache.org/jira/browse/MSHARED-953 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > The trim parameter in buildDom methods in Xpp3DomBuilder is based on a > serious misunderstanding of how the characters method in SAX works. As > currently written, trim can potentially remove all whitespace in text content > from a document. A little more commonly, it will randomly remove or not > remove whitespace depending on how the SAX parser chooses to split text nodes > when it reports them. > It might be possible to implement this correctly at the cost of a lot of code > complexity if anyone is using this. More easily, we could make the parameter > a no-op and never trim. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-953) trimming can remove all whitespace
[ https://issues.apache.org/jira/browse/MSHARED-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-953. - > trimming can remove all whitespace > -- > > Key: MSHARED-953 > URL: https://issues.apache.org/jira/browse/MSHARED-953 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > The trim parameter in buildDom methods in Xpp3DomBuilder is based on a > serious misunderstanding of how the characters method in SAX works. As > currently written, trim can potentially remove all whitespace in text content > from a document. A little more commonly, it will randomly remove or not > remove whitespace depending on how the SAX parser chooses to split text nodes > when it reports them. > It might be possible to implement this correctly at the cost of a lot of code > complexity if anyone is using this. More easily, we could make the parameter > a no-op and never trim. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717716#comment-17717716 ] ASF GitHub Bot commented on MRESOLVER-359: -- cstamas opened a new pull request, #285: URL: https://github.com/apache/maven-resolver/pull/285 Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. --- https://issues.apache.org/jira/browse/MRESOLVER-359 > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] elharo closed pull request #125: [MSHARED-953] Trim at end of element
elharo closed pull request #125: [MSHARED-953] Trim at end of element URL: https://github.com/apache/maven-shared-utils/pull/125 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas opened a new pull request, #285: [MRESOLVER-359] Make build be explicit about build time requirements
cstamas opened a new pull request, #285: URL: https://github.com/apache/maven-resolver/pull/285 Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. --- https://issues.apache.org/jira/browse/MRESOLVER-359 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #124: [MSHARED-953] don't trim
elharo merged PR #124: URL: https://github.com/apache/maven-shared-utils/pull/124 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-359: -- Description: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. Questions: * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, and then even after a year later (when possibly new Java 8 versions may be released), it is expected that u371 and later ones will still work. List of Java 8 releases [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] was: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-352,)" we mean "recent" Java 8. Questions: * why "[1.8.0-352,)"? List of Java 8 releases https://www.oracle.com/java/technologies/javase/8all-relnotes.html > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-371,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-371,)"? I think as in this moment use of latest Java 8 works, > and then even after a year later (when possibly new Java 8 versions may be > released), it is expected that u371 and later ones will still work. > List of Java 8 releases > [https://www.oracle.com/java/technologies/javase/8all-relnotes.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7729) Deprecate Xpp3Dom.isNonEmpty and isEmpty
[ https://issues.apache.org/jira/browse/MNG-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717713#comment-17717713 ] ASF GitHub Bot commented on MNG-7729: - elharo merged PR #136: URL: https://github.com/apache/maven-shared-utils/pull/136 > 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)
[GitHub] [maven-shared-utils] elharo merged pull request #136: [MNG-7729] deprecate questionable IsEmpty/IsNotEmpty methods
elharo merged PR #136: URL: https://github.com/apache/maven-shared-utils/pull/136 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-359) Make build be explicit about build time requirements
[ https://issues.apache.org/jira/browse/MRESOLVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-359: -- Description: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-352,)" we mean "recent" Java 8. Questions: * why "[1.8.0-352,)"? List of Java 8 releases https://www.oracle.com/java/technologies/javase/8all-relnotes.html was: Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-352,)" we mean "recent" Java 8. > Make build be explicit about build time requirements > > > Key: MRESOLVER-359 > URL: https://issues.apache.org/jira/browse/MRESOLVER-359 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Current state of affairs: > * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer > rule) set in resolver TLP contains "3.8.4", that according to enforcer > "Version Range Specification" means "3.8.4 or later but 3.8.4 is > RECOMMENDED". This is NOT what we mean. > * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer > rule) inherited from parent contains "1.8" which again, is NOT what we mean, > as we know build will not work on some obsolete Java 8 versions (ie. > Java8u172 from 2018) > Fixes: > * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe > "maintained" Maven version. > * make minimalJavaBuildVersion be "[1.8.0-352,)" we mean "recent" Java 8. > Questions: > * why "[1.8.0-352,)"? List of Java 8 releases > https://www.oracle.com/java/technologies/javase/8all-relnotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-359) Make build be explicit about build time requirements
Tamas Cservenak created MRESOLVER-359: - Summary: Make build be explicit about build time requirements Key: MRESOLVER-359 URL: https://issues.apache.org/jira/browse/MRESOLVER-359 Project: Maven Resolver Issue Type: Task Reporter: Tamas Cservenak Fix For: 1.9.10 Current state of affairs: * property minimalMavenBuildVersion (passed to requireMavenVersion enforcer rule) set in resolver TLP contains "3.8.4", that according to enforcer "Version Range Specification" means "3.8.4 or later but 3.8.4 is RECOMMENDED". This is NOT what we mean. * property minimalJavaBuildVersion (passed to requireJavaVersion enforcer rule) inherited from parent contains "1.8" which again, is NOT what we mean, as we know build will not work on some obsolete Java 8 versions (ie. Java8u172 from 2018) Fixes: * make minimalMavenBuildVersion be "[3.8.4,)", we mean "recent" or maybe "maintained" Maven version. * make minimalJavaBuildVersion be "[1.8.0-352,)" we mean "recent" Java 8. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-358) Upgrade Guava, Maven, mockito, Plexus Utils
[ https://issues.apache.org/jira/browse/MRESOLVER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717706#comment-17717706 ] ASF GitHub Bot commented on MRESOLVER-358: -- cstamas opened a new pull request, #284: URL: https://github.com/apache/maven-resolver/pull/284 Upgrades * guava to 31.1-jre (was 30.1-jre) * mockito-core to 4.11.0 (was 4.8.1) * plexus-utils to 3.5.1 (was 3.5.0) * maven deps (used in demos only) to 3.8.8 (was 3.8.4) --- https://issues.apache.org/jira/browse/MRESOLVER-358 > Upgrade Guava, Maven, mockito, Plexus Utils > --- > > Key: MRESOLVER-358 > URL: https://issues.apache.org/jira/browse/MRESOLVER-358 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Upgrades > * guava to 31.1-jre (was 30.1-jre) > * mockito-core to 4.11.0 (was 4.8.1) > * plexus-utils to 3.5.1 (was 3.5.0) > * maven deps (used in demos only) to 3.8.8 (was 3.8.4) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-358) Upgrade Guava, Maven, mockito, Plexus Utils
[ https://issues.apache.org/jira/browse/MRESOLVER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-358: - Assignee: Tamas Cservenak > Upgrade Guava, Maven, mockito, Plexus Utils > --- > > Key: MRESOLVER-358 > URL: https://issues.apache.org/jira/browse/MRESOLVER-358 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.10 > > > Upgrades > * guava to 31.1-jre (was 30.1-jre) > * mockito-core to 4.11.0 (was 4.8.1) > * plexus-utils to 3.5.1 (was 3.5.0) > * maven deps (used in demos only) to 3.8.8 (was 3.8.4) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717707#comment-17717707
]
Slawomir Jaranowski commented on MSHARED-1247:
--
We have
{noformat}
java.lang.IllegalArgumentException: Unsupported class file major version 1025
{noformat}
for class:
{noformat}
ossfuzz/issue51980/Test.class
{noformat}
As I see {{ossfuzz}} contains corrupted classes for tests - [~ggregory]
questions is why {{cyclonedx}} try to analyze also test resources
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMave
[GitHub] [maven-resolver] cstamas opened a new pull request, #284: [MRESOLVER-358] Upgrade some dependencies
cstamas opened a new pull request, #284: URL: https://github.com/apache/maven-resolver/pull/284 Upgrades * guava to 31.1-jre (was 30.1-jre) * mockito-core to 4.11.0 (was 4.8.1) * plexus-utils to 3.5.1 (was 3.5.0) * maven deps (used in demos only) to 3.8.8 (was 3.8.4) --- https://issues.apache.org/jira/browse/MRESOLVER-358 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-358) Upgrade Guava, Maven, mockito, Plexus Utils
Tamas Cservenak created MRESOLVER-358: - Summary: Upgrade Guava, Maven, mockito, Plexus Utils Key: MRESOLVER-358 URL: https://issues.apache.org/jira/browse/MRESOLVER-358 Project: Maven Resolver Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 1.9.10 Upgrades * guava to 31.1-jre (was 30.1-jre) * mockito-core to 4.11.0 (was 4.8.1) * plexus-utils to 3.5.1 (was 3.5.0) * maven deps (used in demos only) to 3.8.8 (was 3.8.4) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7769) Upgrade to Resolver 1.9.10
[ https://issues.apache.org/jira/browse/MNG-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7769: - Description: As resolver 1.9.8 suffers from event bug MRESOLVER-352 that may break extensions relying on events. And resolver 1.9.9 suffers from verbose tree bug MRESOLVER-357 that may not detect some cases of divergence. was:As resolver 1.9.8 suffers from event bug MRESOLVER-352 that may break extensions relying on events. > Upgrade to Resolver 1.9.10 > -- > > Key: MNG-7769 > URL: https://issues.apache.org/jira/browse/MNG-7769 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-6, 4.0.0 > > > As resolver 1.9.8 suffers from event bug MRESOLVER-352 that may break > extensions relying on events. > And resolver 1.9.9 suffers from verbose tree bug MRESOLVER-357 that may not > detect some cases of divergence. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7769) Upgrade to Resolver 1.9.10
[ https://issues.apache.org/jira/browse/MNG-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7769: - Summary: Upgrade to Resolver 1.9.10 (was: Upgrade to Resolver 1.9.9) > Upgrade to Resolver 1.9.10 > -- > > Key: MNG-7769 > URL: https://issues.apache.org/jira/browse/MNG-7769 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-6, 4.0.0 > > > As resolver 1.9.8 suffers from event bug MRESOLVER-352 that may break > extensions relying on events. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717696#comment-17717696
]
Slawomir Jaranowski commented on MSHARED-1247:
--
This one is a problem:
{{commons-bcel/target/test-classes/issue362/Bcel362.class}}
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.Nat
[jira] [Commented] (MGPG-97) add pgpverify check to the build
[ https://issues.apache.org/jira/browse/MGPG-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717691#comment-17717691 ] ASF GitHub Bot commented on MGPG-97: hboutemy merged PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48 > add pgpverify check to the build > > > Key: MGPG-97 > URL: https://issues.apache.org/jira/browse/MGPG-97 > Project: Maven GPG Plugin > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > signing is useful only if signature checks are done > let's apply this best practice to maven-gpg-plugin itself -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-gpg-plugin] hboutemy merged pull request #48: [MGPG-97] use pgpverify plugin to check dependencies signatures
hboutemy merged PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717690#comment-17717690
]
Slawomir Jaranowski commented on MSHARED-1247:
--
[~ggregory] thanks for reports. Do you know which class from your project has
type 17 in constant pool?
I can try to find it, and we can add test - it will be easier to debug.
By the way all versions are affected :)
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
> at org.apache
[jira] [Commented] (SUREFIRE-2072) Surefire retains too much heap in some case, leading to OutOfMemory
[ https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717689#comment-17717689 ] Martijn Visser commented on SUREFIRE-2072: -- Is there any update on this ticket? > Surefire retains too much heap in some case, leading to OutOfMemory > --- > > Key: SUREFIRE-2072 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2072 > Project: Maven Surefire > Issue Type: Bug >Reporter: Mickael Istria >Priority: Major > > Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM > (as cache). Which caching is welcome, this cannot scale with some big test > suites of several thousands of tests and cause OutOfMemoryError. > This is the case when running Eclipse JDT dom test suite, since > tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in > https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-357:
-
Assignee: Tamas Cservenak
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.10
>
>
> As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" that previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise.
> In fact, the check is wrong: it should check for same GA child count and not
> ANY child count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-357:
--
Description:
As per user report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" than previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The {{some-group:d:jar:1.0 [compile]}} should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise.
In fact, the check is wrong: it should check for same GA child count and not
ANY child count.
was:
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The {{some-group:d:jar:1.0 [compile]}} should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise.
In fact, the check is wrong: it should check for same GA child count and not
ANY child count.
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.10
>
>
> As per user report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" than previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise.
> In fact, the check is wrong: it should check for same GA child count and not
> ANY child count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717668#comment-17717668
]
Gary D. Gregory commented on MSHARED-1247:
--
Here is an attempt at fixing this issue:
[https://github.com/apache/maven-dependency-analyzer/pull/88]
It might not be complete or there might be other issues.
If I run "mvn clean install" and then update BCEL's pom.xml to:
{noformat}
diff --git a/pom.xml b/pom.xml
index 7ebef432..4b3bd4e1 100644
--- a/pom.xml
+++ b/pom.xml
@@ -27,7 +27,7 @@
org.apache.commons
commons-parent
-56
+57^M
org.apache.bcel
@@ -210,6 +210,17 @@
clean verify apache-rat:check japicmp:cmp checkstyle:check
pmd:check spotbugs:check javadoc:javadoc
+ ^M
+org.cyclonedx^M
+cyclonedx-maven-plugin^M
+^M
+ ^M
+org.apache.maven.shared^M
+maven-dependency-analyzer^M
+1.13.2-SNAPSHOT^M
+ ^M
+ ^M
+ ^M
org.apache.felix
maven-bundle-plugin
{noformat}
I then get a different error that suggests the parsing is still wrong:
{noformat}
Caused by: java.lang.IllegalArgumentException: Unsupported class file major
version 1025
at org.objectweb.asm.ClassReader. (ClassReader.java:199)
at org.objectweb.asm.ClassReader. (ClassReader.java:180)
at org.objectweb.asm.ClassReader. (ClassReader.java:166)
at
org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
(DependencyClassFileVisitor.java:57)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
(ClassFileVisitorUtils.java:114)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
(ClassFileVisitorUtils.java:106)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
(ClassFileVisitorUtils.java:97)
at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
(ClassFileVisitorUtils.java:59)
at
org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
(ASMDependencyAnalyzer.java:43)
{noformat}
Any suggestions or fix?
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComp
[jira] [Commented] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
[
https://issues.apache.org/jira/browse/MSHARED-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717666#comment-17717666
]
ASF GitHub Bot commented on MSHARED-1247:
-
garydgregory opened a new pull request, #88:
URL: https://github.com/apache/maven-dependency-analyzer/pull/88
- Parses constant pool tag 17 per
https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.4.10
- No unit test :-(
> java.lang.RuntimeException: Unknown constant pool type '17'
> ---
>
> Key: MSHARED-1247
> URL: https://issues.apache.org/jira/browse/MSHARED-1247
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Blocker
>
> You get the exception:
> {noformat}
> ...
> Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
> (ConstantPoolParser.java:120)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
> (ConstantPoolParser.java:104)
> at
> org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
> (DependencyClassFileVisitor.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:114)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
> (ClassFileVisitorUtils.java:106)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
> (ClassFileVisitorUtils.java:97)
> at
> org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
> (ClassFileVisitorUtils.java:59)
> at
> org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
> (ASMDependencyAnalyzer.java:43)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:206)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
> (DefaultProjectDependencyAnalyzer.java:200)
> at
> org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
> (DefaultProjectDependencyAnalyzer.java:68)
> at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
> (CycloneDxMojo.java:86)
> at
> org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
> (CycloneDxAggregateMojo.java:130)
> at org.cyclonedx.maven.BaseCycloneDxMojo.execute
> (BaseCycloneDxMojo.java:258)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827
[GitHub] [maven-dependency-analyzer] garydgregory opened a new pull request, #88: [MSHARED-1247] java.lang.RuntimeException: Unknown constant pool type
garydgregory opened a new pull request, #88: URL: https://github.com/apache/maven-dependency-analyzer/pull/88 - Parses constant pool tag 17 per https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.4.10 - No unit test :-( -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1247) java.lang.RuntimeException: Unknown constant pool type '17'
Gary D. Gregory created MSHARED-1247:
Summary: java.lang.RuntimeException: Unknown constant pool type
'17'
Key: MSHARED-1247
URL: https://issues.apache.org/jira/browse/MSHARED-1247
Project: Maven Shared Components
Issue Type: Bug
Components: maven-dependency-analyzer
Affects Versions: maven-dependency-analyzer-1.13.1
Environment: Apache Maven 3.9.1
(2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: C:\java\apache-maven-3.9.1
Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
Adoptium\jdk-8.0.362.9-hotspot\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Microsoft Windows [Version 10.0.19044.2728]
Reporter: Gary D. Gregory
You get the exception:
{noformat}
...
Caused by: java.lang.RuntimeException: Unknown constant pool type '17'
at
org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.parseConstantPoolClassReferences
(ConstantPoolParser.java:120)
at
org.apache.maven.shared.dependency.analyzer.asm.ConstantPoolParser.getConstantPoolClassReferences
(ConstantPoolParser.java:104)
at
org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass
(DependencyClassFileVisitor.java:59)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
(ClassFileVisitorUtils.java:114)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass
(ClassFileVisitorUtils.java:106)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.acceptDirectory
(ClassFileVisitorUtils.java:97)
at org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.accept
(ClassFileVisitorUtils.java:59)
at
org.apache.maven.shared.dependency.analyzer.asm.ASMDependencyAnalyzer.analyze
(ASMDependencyAnalyzer.java:43)
at
org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildDependencyClasses
(DefaultProjectDependencyAnalyzer.java:206)
at
org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.buildTestDependencyClasses
(DefaultProjectDependencyAnalyzer.java:200)
at
org.apache.maven.shared.dependency.analyzer.DefaultProjectDependencyAnalyzer.analyze
(DefaultProjectDependencyAnalyzer.java:68)
at org.cyclonedx.maven.CycloneDxMojo.doProjectDependencyAnalysis
(CycloneDxMojo.java:86)
at
org.cyclonedx.maven.CycloneDxAggregateMojo.extractComponentsAndDependencies
(CycloneDxAggregateMojo.java:130)
at org.cyclonedx.maven.BaseCycloneDxMojo.execute
(BaseCycloneDxMojo.java:258)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:342)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:330)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:175)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:76)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:163)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:160)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:272)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717656#comment-17717656
]
ASF GitHub Bot commented on MNG-7338:
-
michael-o commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180344798
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -444,10 +447,10 @@ private CommandLine cliMerge(CommandLine mavenConfig,
CommandLine mavenCli) {
*/
void logging(CliRequest cliRequest) {
// LOG LEVEL
-cliRequest.verbose =
cliRequest.commandLine.hasOption(CLIManager.VERBOSE)
-|| cliRequest.commandLine.hasOption(CLIManager.DEBUG);
-cliRequest.quiet = !cliRequest.verbose &&
cliRequest.commandLine.hasOption(CLIManager.QUIET);
-cliRequest.showErrors = cliRequest.verbose ||
cliRequest.commandLine.hasOption(CLIManager.ERRORS);
+CommandLine commandLine = cliRequest.commandLine;
+cliRequest.verbose = commandLine.hasOption(CLIManager.VERBOSE) ||
commandLine.hasOption(CLIManager.DEBUG);
Review Comment:
Fine
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 279/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB
[GitHub] [maven] michael-o commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
michael-o commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180344798
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -444,10 +447,10 @@ private CommandLine cliMerge(CommandLine mavenConfig,
CommandLine mavenCli) {
*/
void logging(CliRequest cliRequest) {
// LOG LEVEL
-cliRequest.verbose =
cliRequest.commandLine.hasOption(CLIManager.VERBOSE)
-|| cliRequest.commandLine.hasOption(CLIManager.DEBUG);
-cliRequest.quiet = !cliRequest.verbose &&
cliRequest.commandLine.hasOption(CLIManager.QUIET);
-cliRequest.showErrors = cliRequest.verbose ||
cliRequest.commandLine.hasOption(CLIManager.ERRORS);
+CommandLine commandLine = cliRequest.commandLine;
+cliRequest.verbose = commandLine.hasOption(CLIManager.VERBOSE) ||
commandLine.hasOption(CLIManager.DEBUG);
Review Comment:
Fine
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
[ https://issues.apache.org/jira/browse/MENFORCER-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717651#comment-17717651 ] Slawomir Jaranowski commented on MENFORCER-479: --- Which version of plugin? Did you test with the latest version? > Version enforcer rules print single versions when a range is expected > - > > Key: MENFORCER-479 > URL: https://issues.apache.org/jira/browse/MENFORCER-479 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Reporter: Elliotte Rusty Harold >Priority: Major > > AbstractStandardEnforcerRule incorrectly assumes that the toString method of > a VersionRange will be a version range. However it can be just a single > version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-97) add pgpverify check to the build
[ https://issues.apache.org/jira/browse/MGPG-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717648#comment-17717648 ] ASF GitHub Bot commented on MGPG-97: hboutemy commented on PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48#issuecomment-1527483398 this is part for the experience: if we do not check signature, why sign at all? > add pgpverify check to the build > > > Key: MGPG-97 > URL: https://issues.apache.org/jira/browse/MGPG-97 > Project: Maven GPG Plugin > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > signing is useful only if signature checks are done > let's apply this best practice to maven-gpg-plugin itself -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-gpg-plugin] hboutemy commented on pull request #48: [MGPG-97] use pgpverify plugin to check dependencies signatures
hboutemy commented on PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48#issuecomment-1527483398 this is part for the experience: if we do not check signature, why sign at all? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
[ https://issues.apache.org/jira/browse/MENFORCER-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717638#comment-17717638 ] Elliotte Rusty Harold commented on MENFORCER-479: - Real world example from RequireMavenVersion: [ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message: Detected Maven Version: 3.5.0 is not in the allowed range 3.8.4 3.8.4 is a single version, not a range. Either fix VersionRange.toString to always return a range or don't use toString here. > Version enforcer rules print single versions when a range is expected > - > > Key: MENFORCER-479 > URL: https://issues.apache.org/jira/browse/MENFORCER-479 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Rule API >Reporter: Elliotte Rusty Harold >Priority: Major > > AbstractStandardEnforcerRule incorrectly assumes that the toString method of > a VersionRange will be a version range. However it can be just a single > version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-479) Version enforcer rules print single versions when a range is expected
Elliotte Rusty Harold created MENFORCER-479: --- Summary: Version enforcer rules print single versions when a range is expected Key: MENFORCER-479 URL: https://issues.apache.org/jira/browse/MENFORCER-479 Project: Maven Enforcer Plugin Issue Type: Bug Components: Rule API Reporter: Elliotte Rusty Harold AbstractStandardEnforcerRule incorrectly assumes that the toString method of a VersionRange will be a version range. However it can be just a single version rather than the entire range. E.g. 3.8.4 instead [3.8.0, 3.9) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7775) toString method in VersionRange is undocumented and surprising
Elliotte Rusty Harold created MNG-7775: -- Summary: toString method in VersionRange is undocumented and surprising Key: MNG-7775 URL: https://issues.apache.org/jira/browse/MNG-7775 Project: Maven Issue Type: Bug Reporter: Elliotte Rusty Harold It sometimes returns a single version rather than the full range, though the only way to see this is by reading the code. I've seen this create confusing end user messages in enforcer rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717632#comment-17717632
]
ASF GitHub Bot commented on MRESOLVER-357:
--
cstamas opened a new pull request, #283:
URL: https://github.com/apache/maven-resolver/pull/283
The check was wrong, it was "has ANY sibling", while it should be "has ANY
RELATED sibling".
---
https://issues.apache.org/jira/browse/MRESOLVER-357
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.10
>
>
> As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" that previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise.
> In fact, the check is wrong: it should check for same GA child count and not
> ANY child count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #283: [MRESOLVER-357] Fix the code to deliver the promise in comment
cstamas opened a new pull request, #283: URL: https://github.com/apache/maven-resolver/pull/283 The check was wrong, it was "has ANY sibling", while it should be "has ANY RELATED sibling". --- https://issues.apache.org/jira/browse/MRESOLVER-357 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717626#comment-17717626
]
Elliotte Rusty Harold commented on MNG-7714:
Yes, I think that's true. What I haven't figured out yet is what the correct
logic to fix this is. Any suggestions or PRs you might have are appreciated.
> 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
> Fix For: 4.0.0-alpha-6
>
>
> 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] [Updated] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-357:
--
Description:
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The {{some-group:d:jar:1.0 [compile]}} should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise.
In fact, the check is wrong: it should check for same GA child count and not
ANY child count.
was:
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The {{some-group:d:jar:1.0 [compile]}} should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise (the check is wrong, it should
check for same GAs and not ANY child count).
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.10
>
>
> As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" that previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise.
> In fact, the check is wrong: it should check for same GA child count and not
> ANY child count.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
Tamas Cservenak created MRESOLVER-357:
-
Summary: ConflictResolver STANDARD verbosity misbehaves
Key: MRESOLVER-357
URL: https://issues.apache.org/jira/browse/MRESOLVER-357
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Affects Versions: 1.9.9, 1.9.8
Reporter: Tamas Cservenak
Fix For: 1.9.10
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The d:1.0 should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise (the check is wrong, it should
check for same GAs and not ANY child count).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-357) ConflictResolver STANDARD verbosity misbehaves
[
https://issues.apache.org/jira/browse/MRESOLVER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-357:
--
Description:
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The {{some-group:d:jar:1.0 [compile]}} should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise (the check is wrong, it should
check for same GAs and not ANY child count).
was:
As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
tree" that previous versions:
{noformat}
Input node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| +- some-group:c:jar:1.0 [compile]
| +- some-group:c:jar:2.0 [compile]
| \- some-group:d:jar:1.0 [compile]
+- some-group:c:jar:2.0 [compile]
+- some-group:c:jar:1.0 [compile]
\- some-group:d:jar:2.0 [compile]
Transformed node:
some-group:a:jar:1.0 [compile]
+- some-group:b:jar:1.0 [compile]
| \- some-group:c:jar:2.0 [compile] (nearer exists)
+- some-group:c:jar:2.0 [compile]
\- some-group:d:jar:2.0 [compile] {noformat}
The d:1.0 should not be removed.
Seems that code comment "leaving only 1 loser" is present in comments only, but
the actual code does not deliver this promise (the check is wrong, it should
check for same GAs and not ANY child count).
> ConflictResolver STANDARD verbosity misbehaves
> --
>
> Key: MRESOLVER-357
> URL: https://issues.apache.org/jira/browse/MRESOLVER-357
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.8, 1.9.9
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.10
>
>
> As per use report, the 1.9.8 and 1.9.9 versions produce different "verbose
> tree" that previous versions:
> {noformat}
> Input node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:d:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:d:jar:2.0 [compile]
> Transformed node:
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile] (nearer exists)
> +- some-group:c:jar:2.0 [compile]
> \- some-group:d:jar:2.0 [compile] {noformat}
> The {{some-group:d:jar:1.0 [compile]}} should not be removed.
> Seems that code comment "leaving only 1 loser" is present in comments only,
> but the actual code does not deliver this promise (the check is wrong, it
> should check for same GAs and not ANY child count).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-97) add pgpverify check to the build
[ https://issues.apache.org/jira/browse/MGPG-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717591#comment-17717591 ] ASF GitHub Bot commented on MGPG-97: hboutemy commented on code in PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48#discussion_r1180202813 ## pom.xml: ## @@ -194,6 +194,14 @@ under the License. maven-invoker-plugin 3.5.1 + + org.simplify4u.plugins + pgpverify-maven-plugin + 1.11.0 Review Comment: updated, thank you > add pgpverify check to the build > > > Key: MGPG-97 > URL: https://issues.apache.org/jira/browse/MGPG-97 > Project: Maven GPG Plugin > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.1.0 > > > signing is useful only if signature checks are done > let's apply this best practice to maven-gpg-plugin itself -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-gpg-plugin] hboutemy commented on a diff in pull request #48: [MGPG-97] use pgpverify plugin to check dependencies signatures
hboutemy commented on code in PR #48: URL: https://github.com/apache/maven-gpg-plugin/pull/48#discussion_r1180202813 ## pom.xml: ## @@ -194,6 +194,14 @@ under the License. maven-invoker-plugin 3.5.1 + + org.simplify4u.plugins + pgpverify-maven-plugin + 1.11.0 Review Comment: updated, thank you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MGPG-96) add INFO message when signing
[
https://issues.apache.org/jira/browse/MGPG-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MGPG-96.
-
Assignee: Herve Boutemy
Resolution: Fixed
> add INFO message when signing
> -
>
> Key: MGPG-96
> URL: https://issues.apache.org/jira/browse/MGPG-96
> Project: Maven GPG Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> currently, gpg:sign does not display any INFO, which makes feel that nothing
> may happen:
> {noformat}
> [INFO] --- gpg:3.1.0-SNAPSHOT:sign (sign-release-artifacts) @
> maven-gpg-plugin ---
> [INFO] {noformat}
> Displaying most important info, like number of files being signed, or key
> configuration options (like optional keyname) would make this output still
> simple enough but show the action being done, something like:
> {noformat}
> [INFO] --- gpg:3.1.0-SNAPSHOT:sign (sign-release-artifacts) @
> maven-gpg-plugin ---
> [INFO] Signing 5 files with default key
> [INFO]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-96) add INFO message when signing
[
https://issues.apache.org/jira/browse/MGPG-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717588#comment-17717588
]
ASF GitHub Bot commented on MGPG-96:
hboutemy merged PR #47:
URL: https://github.com/apache/maven-gpg-plugin/pull/47
> add INFO message when signing
> -
>
> Key: MGPG-96
> URL: https://issues.apache.org/jira/browse/MGPG-96
> Project: Maven GPG Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> currently, gpg:sign does not display any INFO, which makes feel that nothing
> may happen:
> {noformat}
> [INFO] --- gpg:3.1.0-SNAPSHOT:sign (sign-release-artifacts) @
> maven-gpg-plugin ---
> [INFO] {noformat}
> Displaying most important info, like number of files being signed, or key
> configuration options (like optional keyname) would make this output still
> simple enough but show the action being done, something like:
> {noformat}
> [INFO] --- gpg:3.1.0-SNAPSHOT:sign (sign-release-artifacts) @
> maven-gpg-plugin ---
> [INFO] Signing 5 files with default key
> [INFO]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-gpg-plugin] hboutemy merged pull request #47: [MGPG-96] add INFO message
hboutemy merged PR #47: URL: https://github.com/apache/maven-gpg-plugin/pull/47 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717569#comment-17717569
]
ASF GitHub Bot commented on MNG-7338:
-
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180163974
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -444,10 +447,10 @@ private CommandLine cliMerge(CommandLine mavenConfig,
CommandLine mavenCli) {
*/
void logging(CliRequest cliRequest) {
// LOG LEVEL
-cliRequest.verbose =
cliRequest.commandLine.hasOption(CLIManager.VERBOSE)
-|| cliRequest.commandLine.hasOption(CLIManager.DEBUG);
-cliRequest.quiet = !cliRequest.verbose &&
cliRequest.commandLine.hasOption(CLIManager.QUIET);
-cliRequest.showErrors = cliRequest.verbose ||
cliRequest.commandLine.hasOption(CLIManager.ERRORS);
+CommandLine commandLine = cliRequest.commandLine;
+cliRequest.verbose = commandLine.hasOption(CLIManager.VERBOSE) ||
commandLine.hasOption(CLIManager.DEBUG);
Review Comment:
Hmm, I think it's a nice improvement, but since it's just formatting
related, I would rather just ship it with this PR.
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (
[GitHub] [maven] MartinKanters commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180163974
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -444,10 +447,10 @@ private CommandLine cliMerge(CommandLine mavenConfig,
CommandLine mavenCli) {
*/
void logging(CliRequest cliRequest) {
// LOG LEVEL
-cliRequest.verbose =
cliRequest.commandLine.hasOption(CLIManager.VERBOSE)
-|| cliRequest.commandLine.hasOption(CLIManager.DEBUG);
-cliRequest.quiet = !cliRequest.verbose &&
cliRequest.commandLine.hasOption(CLIManager.QUIET);
-cliRequest.showErrors = cliRequest.verbose ||
cliRequest.commandLine.hasOption(CLIManager.ERRORS);
+CommandLine commandLine = cliRequest.commandLine;
+cliRequest.verbose = commandLine.hasOption(CLIManager.VERBOSE) ||
commandLine.hasOption(CLIManager.DEBUG);
Review Comment:
Hmm, I think it's a nice improvement, but since it's just formatting
related, I would rather just ship it with this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717556#comment-17717556
]
Zhongming Hua commented on MNG-7714:
[~elharo]
I find that this problem is related to the following logic. Because treat *.x*
as {*}-x{*}, 1.0.sp is resolved as [1,[sp]], not [1,sp].
{code:java}
// 1.0.0.X1 < 1.0.0-X2
// treat .X as -X for any string qualifier X
if (!list.isEmpty()) {
list.add(list = new ListItem());
stack.push(list);
} {code}
> 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
> Fix For: 4.0.0-alpha-6
>
>
> 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-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717553#comment-17717553
]
ASF GitHub Bot commented on MNG-7338:
-
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180126561
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -38,6 +38,10 @@ public class CLIManager {
public static final char BATCH_MODE = 'B';
+public static final String NON_INTERACTIVE = "ni";
+
+public static final String FORCE_INTERACTIVE = "fi";
Review Comment:
I agree, I've removed them
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 279/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 283/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 287/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 291/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 295/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 299/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 303/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 307/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 311/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 311/502 kB | 115/196 kB
> Progress (4): 1.0/2.6 MB |
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717551#comment-17717551
]
ASF GitHub Bot commented on MNG-7338:
-
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180126255
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
+.build());
+options.addOption(Option.builder(NON_INTERACTIVE)
+.longOpt("non-interactive")
+.desc("Run in non-interactive (batch) mode (disables output
color) - alias for --batch-mode")
+.build());
+options.addOption(Option.builder(FORCE_INTERACTIVE)
+.longOpt("force-interactive")
+.desc(
+"Run in interactive mode - even when the environment
variable CI is set to true and --non-interactive or --batch-mode are set")
Review Comment:
I'm not sure how to pass this information to Jansi. `isatty(2)` will atm
just return 1/true. Also if `--batch-mode` is set.
Do you think a change like this should be part of this PR?
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717554#comment-17717554
]
ASF GitHub Bot commented on MNG-7338:
-
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180127108
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
Review Comment:
Yeah, that's true. I copied the original description of --batch-mode, but I
agree that it doesn't cover the functionally anymore. I've rewritten them.
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 258/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 262/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 266/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 270/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 274/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 279/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 283/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 287/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 291/502 k
[GitHub] [maven] MartinKanters commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180127108
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
Review Comment:
Yeah, that's true. I copied the original description of --batch-mode, but I
agree that it doesn't cover the functionally anymore. I've rewritten them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180126561
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -38,6 +38,10 @@ public class CLIManager {
public static final char BATCH_MODE = 'B';
+public static final String NON_INTERACTIVE = "ni";
+
+public static final String FORCE_INTERACTIVE = "fi";
Review Comment:
I agree, I've removed them
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] MartinKanters commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
MartinKanters commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1180126255
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
+.build());
+options.addOption(Option.builder(NON_INTERACTIVE)
+.longOpt("non-interactive")
+.desc("Run in non-interactive (batch) mode (disables output
color) - alias for --batch-mode")
+.build());
+options.addOption(Option.builder(FORCE_INTERACTIVE)
+.longOpt("force-interactive")
+.desc(
+"Run in interactive mode - even when the environment
variable CI is set to true and --non-interactive or --batch-mode are set")
Review Comment:
I'm not sure how to pass this information to Jansi. `isatty(2)` will atm
just return 1/true. Also if `--batch-mode` is set.
Do you think a change like this should be part of this PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (MSITE-964) Fix failure of 'site-jar' IT on Java 17
[ https://issues.apache.org/jira/browse/MSITE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-964. Resolution: Fixed Fixed with [48f4155af2069e61c15399a475a26d2467749347|https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git;a=commit;h=48f4155af2069e61c15399a475a26d2467749347]. > Fix failure of 'site-jar' IT on Java 17 > --- > > Key: MSITE-964 > URL: https://issues.apache.org/jira/browse/MSITE-964 > Project: Maven Site Plugin > Issue Type: Sub-task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > See: > https://github.com/apache/maven-site-plugin/pull/148#issuecomment-1525468715 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSITE-960) CI is broken
[ https://issues.apache.org/jira/browse/MSITE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-960. Resolution: Fixed All issues done. > CI is broken > > > Key: MSITE-960 > URL: https://issues.apache.org/jira/browse/MSITE-960 > Project: Maven Site Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Blocker > Attachments: screenshot-1.png > > > Error: Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site) on > project maven-site-plugin: RendererException while preparing context for > skin: Cannot use skin: has 2.0.0-M5 Doxia Sitetools prerequisite, but current > is 1.11.1 -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-964) Fix failure of 'site-jar' IT on Java 17
[ https://issues.apache.org/jira/browse/MSITE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717529#comment-17717529 ] ASF GitHub Bot commented on MSITE-964: -- asfgit closed pull request #150: [MSITE-964] Fix failure of 'site-jar' IT on Java 17 URL: https://github.com/apache/maven-site-plugin/pull/150 > Fix failure of 'site-jar' IT on Java 17 > --- > > Key: MSITE-964 > URL: https://issues.apache.org/jira/browse/MSITE-964 > Project: Maven Site Plugin > Issue Type: Sub-task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > See: > https://github.com/apache/maven-site-plugin/pull/148#issuecomment-1525468715 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site-plugin] asfgit closed pull request #150: [MSITE-964] Fix failure of 'site-jar' IT on Java 17
asfgit closed pull request #150: [MSITE-964] Fix failure of 'site-jar' IT on Java 17 URL: https://github.com/apache/maven-site-plugin/pull/150 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MSITE-964) Fix failure of 'site-jar' IT on Java 17
[ https://issues.apache.org/jira/browse/MSITE-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MSITE-964: Assignee: Michael Osipov > Fix failure of 'site-jar' IT on Java 17 > --- > > Key: MSITE-964 > URL: https://issues.apache.org/jira/browse/MSITE-964 > Project: Maven Site Plugin > Issue Type: Sub-task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > See: > https://github.com/apache/maven-site-plugin/pull/148#issuecomment-1525468715 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-304) DirectoryUtils should consider interpolation
[ https://issues.apache.org/jira/browse/MRESOLVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717510#comment-17717510 ] Tamas Cservenak commented on MRESOLVER-304: --- Maven 3.9.2 targeted issue and related work in MNG-7774 solves this. > DirectoryUtils should consider interpolation > > > Key: MRESOLVER-304 > URL: https://issues.apache.org/jira/browse/MRESOLVER-304 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > As currently it cannot be interpolated, and it applies this logic: > * if "relative path" it resolves against local repo > * if "absolute path" it resolves against path > what would be ideal to introduce somehow 3rd case: > * resolve against local repo > * resolve against maven.multiModuleProjectDirectory > * resolve against absolute path > As new 2nd option would allow to check in filter config along with sources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7774) Maven config and command line interpolation
[
https://issues.apache.org/jira/browse/MNG-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-7774:
Assignee: Tamas Cservenak
> Maven config and command line interpolation
> ---
>
> Key: MNG-7774
> URL: https://issues.apache.org/jira/browse/MNG-7774
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.2
>
>
> Note: this issue "mildly follows" functionality done in Maven 4 as part of
> MNG-7038 and MNG-6303, with partial implementation only (is not full
> back-port), hence "mild introduction".
> Rationale: many new resolver features are akin to be able to store their
> configuration and input along SCM tracked Maven project sources. Sadly,
> currently this is not possible. The two issues targeting Maven4 (MNG-7038 and
> MNG-6303) with introduction of session and project "topDirectory" and
> "rootDirectory" properties solve this. Still, Maven 3.9.x does not need all
> of this.
> So, idea is following:
> * extend MavenCli to interpolate Maven arguments
> * introduce two special properties {{session.rootDirectory}} and
> {{session.topDirectory}} in interpolation. They are special, as they may not
> be defined, and IF they are not defined, their use in Maven argument
> interpolation causes error (Maven will not boot).
> * limit the use of the two new properties to Maven CLI interpolation only.
> This makes projects relying on Maven CLI interpolation "permeable" between
> Maven 3.9.x and Maven 4, while all the whistle and bells (exposing this via
> session or project) will be available in Maven 4 only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7774) Maven config and command line interpolation
[
https://issues.apache.org/jira/browse/MNG-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717506#comment-17717506
]
ASF GitHub Bot commented on MNG-7774:
-
cstamas opened a new pull request, #1097:
URL: https://github.com/apache/maven/pull/1097
This is "mild introduction" of subset of new Maven4 features into Maven
3.9.x land, with single intent: be able to store resolver configuration along
with checked in project sources in SCM.
Changes:
* interpolate properties and arguments
* introduce two new special properties "session.rootDirectory" and
"session.topDirectory"
* these two properties may be undefined (the .mvn may not be found)
* these two properties if undefined, but referenced during interpolation,
causes Maven to bail out (error out), and will prevent starting.
* some other minor cosmetic cleanup
---
https://issues.apache.org/jira/browse/MNG-7774
> Maven config and command line interpolation
> ---
>
> Key: MNG-7774
> URL: https://issues.apache.org/jira/browse/MNG-7774
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.2
>
>
> Note: this issue "mildly follows" functionality done in Maven 4 as part of
> MNG-7038 and MNG-6303, with partial implementation only (is not full
> back-port), hence "mild introduction".
> Rationale: many new resolver features are akin to be able to store their
> configuration and input along SCM tracked Maven project sources. Sadly,
> currently this is not possible. The two issues targeting Maven4 (MNG-7038 and
> MNG-6303) with introduction of session and project "topDirectory" and
> "rootDirectory" properties solve this. Still, Maven 3.9.x does not need all
> of this.
> So, idea is following:
> * extend MavenCli to interpolate Maven arguments
> * introduce two special properties {{session.rootDirectory}} and
> {{session.topDirectory}} in interpolation. They are special, as they may not
> be defined, and IF they are not defined, their use in Maven argument
> interpolation causes error (Maven will not boot).
> * limit the use of the two new properties to Maven CLI interpolation only.
> This makes projects relying on Maven CLI interpolation "permeable" between
> Maven 3.9.x and Maven 4, while all the whistle and bells (exposing this via
> session or project) will be available in Maven 4 only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas opened a new pull request, #1097: [MNG-7774] Maven config and command line interpolation
cstamas opened a new pull request, #1097: URL: https://github.com/apache/maven/pull/1097 This is "mild introduction" of subset of new Maven4 features into Maven 3.9.x land, with single intent: be able to store resolver configuration along with checked in project sources in SCM. Changes: * interpolate properties and arguments * introduce two new special properties "session.rootDirectory" and "session.topDirectory" * these two properties may be undefined (the .mvn may not be found) * these two properties if undefined, but referenced during interpolation, causes Maven to bail out (error out), and will prevent starting. * some other minor cosmetic cleanup --- https://issues.apache.org/jira/browse/MNG-7774 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7774) Maven config and command line interpolation
Tamas Cservenak created MNG-7774:
Summary: Maven config and command line interpolation
Key: MNG-7774
URL: https://issues.apache.org/jira/browse/MNG-7774
Project: Maven
Issue Type: Task
Components: Command Line
Reporter: Tamas Cservenak
Fix For: 3.9.2
Note: this issue "mildly follows" functionality done in Maven 4 as part of
MNG-7038 and MNG-6303, with partial implementation only (is not full
back-port), hence "mild introduction".
Rationale: many new resolver features are akin to be able to store their
configuration and input along SCM tracked Maven project sources. Sadly,
currently this is not possible. The two issues targeting Maven4 (MNG-7038 and
MNG-6303) with introduction of session and project "topDirectory" and
"rootDirectory" properties solve this. Still, Maven 3.9.x does not need all of
this.
So, idea is following:
* extend MavenCli to interpolate Maven arguments
* introduce two special properties {{session.rootDirectory}} and
{{session.topDirectory}} in interpolation. They are special, as they may not be
defined, and IF they are not defined, their use in Maven argument interpolation
causes error (Maven will not boot).
* limit the use of the two new properties to Maven CLI interpolation only.
This makes projects relying on Maven CLI interpolation "permeable" between
Maven 3.9.x and Maven 4, while all the whistle and bells (exposing this via
session or project) will be available in Maven 4 only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
