[jira] [Closed] (MNG-8150) Make SimplexTransferListener handle absent source/target files
[ https://issues.apache.org/jira/browse/MNG-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8150. Resolution: Fixed > Make SimplexTransferListener handle absent source/target files > -- > > Key: MNG-8150 > URL: https://issues.apache.org/jira/browse/MNG-8150 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.9.7 >Reporter: Pavlo Shevchenko >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > See the discussion: > [https://github.com/apache/maven/pull/1471/files#r1632930409] > The `TransferResource#file` may be `null`. The current implementation of the > `SimplexTransferListener` cannot handle this case and will break with an NPE. > > The fix should be merged to `master` and backported to `maven-3.9.x` branches. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8148) DefaultProjectDependenciesResolver takes up to several minutes for some modules of the project
[
https://issues.apache.org/jira/browse/MNG-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854145#comment-17854145
]
Tamas Cservenak commented on MNG-8148:
--
Any chance to get some reproducer for this? Am getting curious...
> DefaultProjectDependenciesResolver takes up to several minutes for some
> modules of the project
> --
>
> Key: MNG-8148
> URL: https://issues.apache.org/jira/browse/MNG-8148
> Project: Maven
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The project is relatively small (5 modules and maybe about 1k classes in
> total)
> unfortunately it is private so I couldn't share the source
> 1 thing that may be makes sense to mention is that some modules generates
> code for protobuf integration.
> also I was able to take thread dump of maven build
> and this is the thing which I faced. most of the times when the build was
> hanging
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=394695.18ms elapsed=448.93s
> tid=0x00015d80a800 nid=0x2403 runnable [0x00016dec4000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.transformGraph(ConflictMarker.java:63)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:58)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:224)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:355)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:313)
> {noformat}
> and
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=456718.35ms elapsed=518.34s
> tid=0x000127811000 nid=0x2403 runnable [0x00016b3ac000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.hash(java.base@11.0.23/HashMap.java:340)
> at java.util.LinkedHashMap.get(java.base@11.0.23/LinkedHashMap.java:440)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:110)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:78)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
> at
>
[jira] [Updated] (MRESOLVER-569) DependencyCollectionException.getResult().getExceptions() always returns one exception
[ https://issues.apache.org/jira/browse/MRESOLVER-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-569: -- Summary: DependencyCollectionException.getResult().getExceptions() always returns one exception (was: DependencyCollectionException.getResult().getExceptions() always return one exec) > DependencyCollectionException.getResult().getExceptions() always returns one > exception > -- > > Key: MRESOLVER-569 > URL: https://issues.apache.org/jira/browse/MRESOLVER-569 > Project: Maven Resolver > Issue Type: Bug >Reporter: Slawomir Jaranowski >Priority: Major > > The problem is when we have more then one repository in configuration. > We see only exception from last one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-564) Align with Maven4 beta-3
[ https://issues.apache.org/jira/browse/MRESOLVER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-564: -- Component/s: Resolver > Align with Maven4 beta-3 > > > Key: MRESOLVER-564 > URL: https://issues.apache.org/jira/browse/MRESOLVER-564 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-564) Align with Maven4 beta-3
[ https://issues.apache.org/jira/browse/MRESOLVER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-564: -- Component/s: (was: re) > Align with Maven4 beta-3 > > > Key: MRESOLVER-564 > URL: https://issues.apache.org/jira/browse/MRESOLVER-564 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-563) Bump org.codehaus.plexus:plexus-xml from 4.0.3 to 4.0.4
[ https://issues.apache.org/jira/browse/MRESOLVER-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-563: -- Component/s: Resolver > Bump org.codehaus.plexus:plexus-xml from 4.0.3 to 4.0.4 > --- > > Key: MRESOLVER-563 > URL: https://issues.apache.org/jira/browse/MRESOLVER-563 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-564) Align with Maven4 beta-3
[ https://issues.apache.org/jira/browse/MRESOLVER-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-564: -- Component/s: re > Align with Maven4 beta-3 > > > Key: MRESOLVER-564 > URL: https://issues.apache.org/jira/browse/MRESOLVER-564 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: re, Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-566) Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3
[ https://issues.apache.org/jira/browse/MRESOLVER-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-566: -- Component/s: Resolver > Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3 > -- > > Key: MRESOLVER-566 > URL: https://issues.apache.org/jira/browse/MRESOLVER-566 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-568) Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2
[ https://issues.apache.org/jira/browse/MRESOLVER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-568: -- Component/s: Resolver > Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2 > -- > > Key: MRESOLVER-568 > URL: https://issues.apache.org/jira/browse/MRESOLVER-568 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-562) Bump org.codehaus.mojo:exec-maven-plugin from 3.2.0 to 3.3.0
[ https://issues.apache.org/jira/browse/MRESOLVER-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-562: -- Component/s: Resolver > Bump org.codehaus.mojo:exec-maven-plugin from 3.2.0 to 3.3.0 > > > Key: MRESOLVER-562 > URL: https://issues.apache.org/jira/browse/MRESOLVER-562 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-567) Bump org.redisson:redisson from 3.30.0 to 3.31.0
[ https://issues.apache.org/jira/browse/MRESOLVER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-567: -- Component/s: Resolver > Bump org.redisson:redisson from 3.30.0 to 3.31.0 > > > Key: MRESOLVER-567 > URL: https://issues.apache.org/jira/browse/MRESOLVER-567 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-566) Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3
[ https://issues.apache.org/jira/browse/MRESOLVER-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-566: - Assignee: Tamas Cservenak > Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3 > -- > > Key: MRESOLVER-566 > URL: https://issues.apache.org/jira/browse/MRESOLVER-566 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-568) Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2
[ https://issues.apache.org/jira/browse/MRESOLVER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-568: - Assignee: Tamas Cservenak > Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2 > -- > > Key: MRESOLVER-568 > URL: https://issues.apache.org/jira/browse/MRESOLVER-568 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-567) Bump org.redisson:redisson from 3.30.0 to 3.31.0
[ https://issues.apache.org/jira/browse/MRESOLVER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-567. - Resolution: Fixed > Bump org.redisson:redisson from 3.30.0 to 3.31.0 > > > Key: MRESOLVER-567 > URL: https://issues.apache.org/jira/browse/MRESOLVER-567 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-568) Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2
[ https://issues.apache.org/jira/browse/MRESOLVER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-568. - Resolution: Fixed > Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2 > -- > > Key: MRESOLVER-568 > URL: https://issues.apache.org/jira/browse/MRESOLVER-568 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-567) Bump org.redisson:redisson from 3.30.0 to 3.31.0
[ https://issues.apache.org/jira/browse/MRESOLVER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-567: - Assignee: Tamas Cservenak > Bump org.redisson:redisson from 3.30.0 to 3.31.0 > > > Key: MRESOLVER-567 > URL: https://issues.apache.org/jira/browse/MRESOLVER-567 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-568) Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2
Tamas Cservenak created MRESOLVER-568: - Summary: Bump org.apache.commons:commons-compress from 1.26.1 to 1.26.2 Key: MRESOLVER-568 URL: https://issues.apache.org/jira/browse/MRESOLVER-568 Project: Maven Resolver Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-567) Bump org.redisson:redisson from 3.30.0 to 3.31.0
Tamas Cservenak created MRESOLVER-567: - Summary: Bump org.redisson:redisson from 3.30.0 to 3.31.0 Key: MRESOLVER-567 URL: https://issues.apache.org/jira/browse/MRESOLVER-567 Project: Maven Resolver Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-566) Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3
[ https://issues.apache.org/jira/browse/MRESOLVER-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-566. - Resolution: Fixed > Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3 > -- > > Key: MRESOLVER-566 > URL: https://issues.apache.org/jira/browse/MRESOLVER-566 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-566) Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3
Tamas Cservenak created MRESOLVER-566: - Summary: Bump sisuVersion from 0.9.0.M2 to 0.9.0.M3 Key: MRESOLVER-566 URL: https://issues.apache.org/jira/browse/MRESOLVER-566 Project: Maven Resolver Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8150) Make SimplexTransferListener handle absent source/target files
[ https://issues.apache.org/jira/browse/MNG-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8150: - Component/s: Core > Make SimplexTransferListener handle absent source/target files > -- > > Key: MNG-8150 > URL: https://issues.apache.org/jira/browse/MNG-8150 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.9.7 >Reporter: Pavlo Shevchenko >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > See the discussion: > [https://github.com/apache/maven/pull/1471/files#r1632930409] > The `TransferResource#file` may be `null`. The current implementation of the > `SimplexTransferListener` cannot handle this case and will break with an NPE. > > The fix should be merged to `master` and backported to `maven-3.9.x` branches. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8150) Make SimplexTransferListener handle absent source/target files
[ https://issues.apache.org/jira/browse/MNG-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8150: - Fix Version/s: 3.9.8 (was: 3.9.7) > Make SimplexTransferListener handle absent source/target files > -- > > Key: MNG-8150 > URL: https://issues.apache.org/jira/browse/MNG-8150 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.7 >Reporter: Pavlo Shevchenko >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > See the discussion: > [https://github.com/apache/maven/pull/1471/files#r1632930409] > The `TransferResource#file` may be `null`. The current implementation of the > `SimplexTransferListener` cannot handle this case and will break with an NPE. > > The fix should be merged to `master` and backported to `maven-3.9.x` branches. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8150) Make SimplexTransferListener handle absent source/target files
[ https://issues.apache.org/jira/browse/MNG-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8150: - Fix Version/s: 4.0.0 4.0.0-beta-4 > Make SimplexTransferListener handle absent source/target files > -- > > Key: MNG-8150 > URL: https://issues.apache.org/jira/browse/MNG-8150 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.7 >Reporter: Pavlo Shevchenko >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 3.9.7, 4.0.0, 4.0.0-beta-4 > > > See the discussion: > [https://github.com/apache/maven/pull/1471/files#r1632930409] > The `TransferResource#file` may be `null`. The current implementation of the > `SimplexTransferListener` cannot handle this case and will break with an NPE. > > The fix should be merged to `master` and backported to `maven-3.9.x` branches. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-227) Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3
[ https://issues.apache.org/jira/browse/MINDEXER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-227. Resolution: Fixed > Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3 > --- > > Key: MINDEXER-227 > URL: https://issues.apache.org/jira/browse/MINDEXER-227 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINDEXER-228) Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre
[ https://issues.apache.org/jira/browse/MINDEXER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-228: Assignee: Tamas Cservenak > Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre > - > > Key: MINDEXER-228 > URL: https://issues.apache.org/jira/browse/MINDEXER-228 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINDEXER-230) (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0
[ https://issues.apache.org/jira/browse/MINDEXER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-230: Assignee: Tamas Cservenak > (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0 > - > > Key: MINDEXER-230 > URL: https://issues.apache.org/jira/browse/MINDEXER-230 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINDEXER-227) Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3
[ https://issues.apache.org/jira/browse/MINDEXER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-227: Assignee: Tamas Cservenak > Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3 > --- > > Key: MINDEXER-227 > URL: https://issues.apache.org/jira/browse/MINDEXER-227 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-230) (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0
[ https://issues.apache.org/jira/browse/MINDEXER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-230. Resolution: Fixed > (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0 > - > > Key: MINDEXER-230 > URL: https://issues.apache.org/jira/browse/MINDEXER-230 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINDEXER-229) Bump commons-cli:commons-cli from 1.7.0 to 1.8.0
[ https://issues.apache.org/jira/browse/MINDEXER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-229: Assignee: Tamas Cservenak > Bump commons-cli:commons-cli from 1.7.0 to 1.8.0 > > > Key: MINDEXER-229 > URL: https://issues.apache.org/jira/browse/MINDEXER-229 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-228) Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre
[ https://issues.apache.org/jira/browse/MINDEXER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-228. Resolution: Fixed > Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre > - > > Key: MINDEXER-228 > URL: https://issues.apache.org/jira/browse/MINDEXER-228 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-229) Bump commons-cli:commons-cli from 1.7.0 to 1.8.0
[ https://issues.apache.org/jira/browse/MINDEXER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-229. Resolution: Fixed > Bump commons-cli:commons-cli from 1.7.0 to 1.8.0 > > > Key: MINDEXER-229 > URL: https://issues.apache.org/jira/browse/MINDEXER-229 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-230) (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0
Tamas Cservenak created MINDEXER-230: Summary: (build) Bump org.gaul:modernizer-maven-plugin from 2.8.0 to 2.9.0 Key: MINDEXER-230 URL: https://issues.apache.org/jira/browse/MINDEXER-230 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-229) Bump commons-cli:commons-cli from 1.7.0 to 1.8.0
Tamas Cservenak created MINDEXER-229: Summary: Bump commons-cli:commons-cli from 1.7.0 to 1.8.0 Key: MINDEXER-229 URL: https://issues.apache.org/jira/browse/MINDEXER-229 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-228) Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre
Tamas Cservenak created MINDEXER-228: Summary: Bump com.google.guava:guava from 33.2.0-jre to 33.2.1-jre Key: MINDEXER-228 URL: https://issues.apache.org/jira/browse/MINDEXER-228 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINDEXER-226) Bump lucene.version from 9.10.0 to 9.11.0
[ https://issues.apache.org/jira/browse/MINDEXER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-226: Assignee: Tamas Cservenak > Bump lucene.version from 9.10.0 to 9.11.0 > - > > Key: MINDEXER-226 > URL: https://issues.apache.org/jira/browse/MINDEXER-226 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-227) Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3
Tamas Cservenak created MINDEXER-227: Summary: Bump org.eclipse.sisu:org.eclipse.sisu.inject from 0.9.0.M2 to 0.9.0.M3 Key: MINDEXER-227 URL: https://issues.apache.org/jira/browse/MINDEXER-227 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-226) Bump lucene.version from 9.10.0 to 9.11.0
[ https://issues.apache.org/jira/browse/MINDEXER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-226. Resolution: Fixed > Bump lucene.version from 9.10.0 to 9.11.0 > - > > Key: MINDEXER-226 > URL: https://issues.apache.org/jira/browse/MINDEXER-226 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-226) Bump lucene.version from 9.10.0 to 9.11.0
Tamas Cservenak created MINDEXER-226: Summary: Bump lucene.version from 9.10.0 to 9.11.0 Key: MINDEXER-226 URL: https://issues.apache.org/jira/browse/MINDEXER-226 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[ https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8141. Resolution: Fixed > Model Builder should report if not sure about "fully correct" outcome > - > > Key: MNG-8141 > URL: https://issues.apache.org/jira/browse/MNG-8141 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > ModelBuilder is component building models (POM + interpolating + parent > inheritance and many many more things), but it should not rely that built > model "was validated", as it MAY NOT been validated: for "furthest" models it > builds, like a parent of a some-level-dependency we use MIN level of > validation (minimal validation). > Still, while the model builder builds, it relies on several aspects of the > model, and it should ensure that the "output" (built model) is correct. Model > Builder hence must be changed in way, that IF it detects any issue _during > building_ of the model, and IF it appears with even slightest possibility > that it cannot deliver "correct output", it must add WARNs to model building > result with proper messages. > One typical case is when model building injects activated profiles (as they > can deliver properties and extra plugins and what not) and activation code > detects a "problem", like for example duplicated profile IDs being used (this > IS catched by validation, but not on MIN level!), hence, model builder cannot > guarantee that built model IS correct. > This change is really only to make Maven emit WARNINGs if project being built > has some "far POMs" (like parent pom of a dependency of a first level > dependency, as in reproducer). If model builder cannot be "100% sure" it > built model correctly, it should be reported. Moreover, WARNs of model > building result were simply neglected so fat (lost). Having warnings like > these would reveal "invalid parent POM" early, as it is case in issue > MNG-8131 for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8148) DefaultProjectDependenciesResolver takes up to several minutes for some modules of the project
[
https://issues.apache.org/jira/browse/MNG-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853491#comment-17853491
]
Tamas Cservenak commented on MNG-8148:
--
Unsure how it was fixed by issue you are referencing, as that issue is about
"upgrade resolver to 2.0.0-alpha (in master)". In short, Maven 4 uses Resolver
2.0.0, while Maven 3 is still on Resolver 1.9.x.
The feature I pointed at, MNG-7960, that is present in Maven 4 solves exactly
this. But alas, it relies on Resolver 2.0.0, so backporting this really no
trivial.
> DefaultProjectDependenciesResolver takes up to several minutes for some
> modules of the project
> --
>
> Key: MNG-8148
> URL: https://issues.apache.org/jira/browse/MNG-8148
> Project: Maven
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The project is relatively small (5 modules and maybe about 1k classes in
> total)
> unfortunately it is private so I couldn't share the source
> 1 thing that may be makes sense to mention is that some modules generates
> code for protobuf integration.
> also I was able to take thread dump of maven build
> and this is the thing which I faced. most of the times when the build was
> hanging
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=394695.18ms elapsed=448.93s
> tid=0x00015d80a800 nid=0x2403 runnable [0x00016dec4000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.transformGraph(ConflictMarker.java:63)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:58)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:224)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:355)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:313)
> {noformat}
> and
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=456718.35ms elapsed=518.34s
> tid=0x000127811000 nid=0x2403 runnable [0x00016b3ac000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.hash(java.base@11.0.23/HashMap.java:340)
> at java.util.LinkedHashMap.get(java.base@11.0.23/LinkedHashMap.java:440)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:110)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:78)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
>
[jira] [Commented] (MNG-8148) DefaultProjectDependenciesResolver takes up to several minutes for some modules of the project
[
https://issues.apache.org/jira/browse/MNG-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853474#comment-17853474
]
Tamas Cservenak commented on MNG-8148:
--
Also look at MNG-7960
> DefaultProjectDependenciesResolver takes up to several minutes for some
> modules of the project
> --
>
> Key: MNG-8148
> URL: https://issues.apache.org/jira/browse/MNG-8148
> Project: Maven
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Priority: Major
>
> The project is relatively small (5 modules and maybe about 1k classes in
> total)
> unfortunately it is private so I couldn't share the source
> 1 thing that may be makes sense to mention is that some modules generates
> code for protobuf integration.
> also I was able to take thread dump of maven build
> and this is the thing which I faced. most of the times when the build was
> hanging
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=394695.18ms elapsed=448.93s
> tid=0x00015d80a800 nid=0x2403 runnable [0x00016dec4000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.analyze(ConflictMarker.java:133)
> at
> org.eclipse.aether.util.graph.transformer.ConflictMarker.transformGraph(ConflictMarker.java:63)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:58)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:151)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:224)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:355)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:313)
> {noformat}
> and
> {noformat}
> "main" #1 prio=5 os_prio=31 cpu=456718.35ms elapsed=518.34s
> tid=0x000127811000 nid=0x2403 runnable [0x00016b3ac000]
>java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.hash(java.base@11.0.23/HashMap.java:340)
> at java.util.LinkedHashMap.get(java.base@11.0.23/LinkedHashMap.java:440)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:110)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.buildConflitIdDAG(ConflictIdSorter.java:122)
> at
> org.eclipse.aether.util.graph.transformer.ConflictIdSorter.transformGraph(ConflictIdSorter.java:78)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:172)
> at
> org.eclipse.aether.util.graph.transformer.ChainedDependencyGraphTransformer.transformGraph(ChainedDependencyGraphTransformer.java:71)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:246)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:306)
> at
>
[jira] [Commented] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[ https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853425#comment-17853425 ] Tamas Cservenak commented on MNG-8141: -- Fixed in 3.9.8, needs changes in master > Model Builder should report if not sure about "fully correct" outcome > - > > Key: MNG-8141 > URL: https://issues.apache.org/jira/browse/MNG-8141 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > ModelBuilder is component building models (POM + interpolating + parent > inheritance and many many more things), but it should not rely that built > model "was validated", as it MAY NOT been validated: for "furthest" models it > builds, like a parent of a some-level-dependency we use MIN level of > validation (minimal validation). > Still, while the model builder builds, it relies on several aspects of the > model, and it should ensure that the "output" (built model) is correct. Model > Builder hence must be changed in way, that IF it detects any issue _during > building_ of the model, and IF it appears with even slightest possibility > that it cannot deliver "correct output", it must add WARNs to model building > result with proper messages. > One typical case is when model building injects activated profiles (as they > can deliver properties and extra plugins and what not) and activation code > detects a "problem", like for example duplicated profile IDs being used (this > IS catched by validation, but not on MIN level!), hence, model builder cannot > guarantee that built model IS correct. > This change is really only to make Maven emit WARNINGs if project being built > has some "far POMs" (like parent pom of a dependency of a first level > dependency, as in reproducer). If model builder cannot be "100% sure" it > built model correctly, it should be reported. Moreover, WARNs of model > building result were simply neglected so fat (lost). Having warnings like > these would reveal "invalid parent POM" early, as it is case in issue > MNG-8131 for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8131) Property replacement in dependency pom no longer works
[
https://issues.apache.org/jira/browse/MNG-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8131.
Resolution: Fixed
Fixed by MNG-8147
> Property replacement in dependency pom no longer works
> --
>
> Key: MNG-8131
> URL: https://issues.apache.org/jira/browse/MNG-8131
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
> Environment: macOS 14.5 (23F79)
>Reporter: Taylor Smock
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> h1. The problem:{{{}{}}}
> Classifiers in dependency poms are no longer replaced (either due to
> performing profile activation of a parent pom of the dependency, or not
> performing replacement of a property).{{{}{}}}
> Steps to reproduce (from [https://openjfx.io/openjfx-docs/#maven] )
> # {{m{{{}vn archetype:generate
> -DarchetypeGroupId=org.openjfx
> -DarchetypeArtifactId=javafx-archetype-simple -DarchetypeVersion=0.0.3
> -DgroupId=org.openjfx -DartifactId=sample -Dversion=1.0.0
> -Djavafx-version=22.0.1{}
> # {{{}mvn compile{{{}{}}}[INFO] Scanning for projects...{}}}{{{}[INFO]
> {}}}{{{}[INFO] -< org.openjfx:sample
> >-{}}}{{{}[INFO] Building sample 1.0.0{}}}{{{}[INFO]
> from pom.xml{}}}{{{}[INFO] [ jar
> ]-{}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom
> (908 B at 1.9 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom
> (8.4 kB at 165 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom
> (904 B at 21 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom
> (749 B at 17 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar
> (306 B at 6.8 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar
> (302 B at 2.4 kB/s){}}}{{{}Downloaded from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar
> (306 B at 2.4 kB/s){}}}{{{}[INFO]
> {}}}{{{}[INFO]
> BUILD FAILURE{}}}{{{}[INFO]
> {}}}{{{}[INFO]
> Total time: 1.378 s{}}}{{{}[INFO] Finished at:
> 2024-05-28T10:23:05-06:00{}}}{{{}[INFO]
> {}}}{{{}[ERROR]
> Failed to execute goal on project sample: Could not resolve dependencies for
> project org.openjfx:sample:jar:1.0.0: The following artifacts could not be
> resolved: org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 (absent),
> org.openjfx:javafx-graphics:jar:${javafx.platform}:22.0.1 (absent),
> org.openjfx:javafx-base:jar:${javafx.platform}:22.0.1 (absent): Could not
> find artifact org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 in
> central
[jira] [Closed] (MNG-8147) Profile interpolation broke their evaluation in case of duplicate IDs
[
https://issues.apache.org/jira/browse/MNG-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8147.
Resolution: Fixed
> Profile interpolation broke their evaluation in case of duplicate IDs
> -
>
> Key: MNG-8147
> URL: https://issues.apache.org/jira/browse/MNG-8147
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> To be clear: we talk about invalid POMs, as you cannot build using a POM that
> contains duplicate Profile ID (is caught and build failed by Maven itself).
> Sadly, POMs are being generated as well, with questionable qualities as it
> seems nothing validates them.
> The change for improvement MNG-8081 broke Maven Model Builder in a way, it
> cannot now properly build projects that have {_}duplicated profile IDs{_}.
> Again, these projects are anyway "just working by chance" (as some dependency
> POM is invalid), but 3.9.6 was building these projects just fine.
> The issue MNG-8141 is created to WARN end users about this.
> This issue should restore 3.9.7 breakage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8147) Profile interpolation broke their evaluation in case of duplicate IDs
[
https://issues.apache.org/jira/browse/MNG-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8147:
-
Description:
To be clear: we talk about invalid POMs, as you cannot build using a POM that
contains duplicate Profile ID (is caught and build failed by Maven itself).
Sadly, POMs are being generated as well, with questionable qualities as it
seems nothing validates them.
The change for improvement MNG-8081 broke Maven Model Builder in a way, it
cannot now properly build projects that have {_}duplicated profile IDs{_}.
Again, these projects are anyway "just working by chance" (as some dependency
POM is invalid), but 3.9.6 was building these projects just fine.
The issue MNG-8141 is created to WARN end users about this.
This issue should restore 3.9.7 breakage.
was:
The change for improvement MNG-8081 broke Maven Model Builder in a way, it
cannot now properly build projects that have {_}duplicated profile IDs{_}.
Again, these projects are anyway "just working by chance" (as some dependency
POM is invalid), but 3.9.6 was building these projects just fine.
The issue MNG-8141 is created to WARN end users about this.
This issue should restore 3.9.7 breakage.
> Profile interpolation broke their evaluation in case of duplicate IDs
> -
>
> Key: MNG-8147
> URL: https://issues.apache.org/jira/browse/MNG-8147
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> To be clear: we talk about invalid POMs, as you cannot build using a POM that
> contains duplicate Profile ID (is caught and build failed by Maven itself).
> Sadly, POMs are being generated as well, with questionable qualities as it
> seems nothing validates them.
> The change for improvement MNG-8081 broke Maven Model Builder in a way, it
> cannot now properly build projects that have {_}duplicated profile IDs{_}.
> Again, these projects are anyway "just working by chance" (as some dependency
> POM is invalid), but 3.9.6 was building these projects just fine.
> The issue MNG-8141 is created to WARN end users about this.
> This issue should restore 3.9.7 breakage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8147) Profile interpolation broke their evaluation in case of duplicate IDs
[
https://issues.apache.org/jira/browse/MNG-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8147:
-
Summary: Profile interpolation broke their evaluation in case of duplicate
IDs (was: Profile interpolation broke their evaluation)
> Profile interpolation broke their evaluation in case of duplicate IDs
> -
>
> Key: MNG-8147
> URL: https://issues.apache.org/jira/browse/MNG-8147
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> The change for improvement MNG-8081 broke Maven Model Builder in a way, it
> cannot now properly build projects that have {_}duplicated profile IDs{_}.
> Again, these projects are anyway "just working by chance" (as some dependency
> POM is invalid), but 3.9.6 was building these projects just fine.
> The issue MNG-8141 is created to WARN end users about this.
> This issue should restore 3.9.7 breakage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8066:
-
Component/s: Core
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: François Guillot
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8146) Drop use of commons-lang
[
https://issues.apache.org/jira/browse/MNG-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8146:
-
Component/s: Dependencies
> Drop use of commons-lang
>
>
> Key: MNG-8146
> URL: https://issues.apache.org/jira/browse/MNG-8146
> Project: Maven
> Issue Type: Task
> Components: Dependencies
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> Maven 4 already did this. By introspection, it turns out that 3.9 is also
> very lightly use commons-lang, while it in fact represents quite noticeable
> overhead of the ZIP distro size (10% almost). Without commons-lang Maven
> 3.9.x distro is 9MB only.
> Moreover, the presence of commons-lang just introduced some peculiarities:
> * confusion over StringUtils (vs Plexus Utils StringUtils)
> * skewed param validation: according to commons-lang string "2." is not a
> valid float, while Float.parseFloat nicely parses it into 2.0 (see MNG-7756)
> * PR ended up with {_}same LOC but noticeable smaller ZIP distro{_}, meaning
> not much was really used out of it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8131) Property replacement in dependency pom no longer works
[
https://issues.apache.org/jira/browse/MNG-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853219#comment-17853219
]
Tamas Cservenak commented on MNG-8131:
--
Latest PR [https://github.com/apache/maven/pull/1568]
Improvements:
* fixed Maven to still build this "invalid" thing (just like 3.9.6 did)
* BUT warn user about presence of invalid models
> Property replacement in dependency pom no longer works
> --
>
> Key: MNG-8131
> URL: https://issues.apache.org/jira/browse/MNG-8131
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
> Environment: macOS 14.5 (23F79)
>Reporter: Taylor Smock
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> h1. The problem:{{{}{}}}
> Classifiers in dependency poms are no longer replaced (either due to
> performing profile activation of a parent pom of the dependency, or not
> performing replacement of a property).{{{}{}}}
> Steps to reproduce (from [https://openjfx.io/openjfx-docs/#maven] )
> # {{m{{{}vn archetype:generate
> -DarchetypeGroupId=org.openjfx
> -DarchetypeArtifactId=javafx-archetype-simple -DarchetypeVersion=0.0.3
> -DgroupId=org.openjfx -DartifactId=sample -Dversion=1.0.0
> -Djavafx-version=22.0.1{}
> # {{{}mvn compile{{{}{}}}[INFO] Scanning for projects...{}}}{{{}[INFO]
> {}}}{{{}[INFO] -< org.openjfx:sample
> >-{}}}{{{}[INFO] Building sample 1.0.0{}}}{{{}[INFO]
> from pom.xml{}}}{{{}[INFO] [ jar
> ]-{}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom
> (908 B at 1.9 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom
> (8.4 kB at 165 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom
> (904 B at 21 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom
> (749 B at 17 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar
> (306 B at 6.8 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar
> (302 B at 2.4 kB/s){}}}{{{}Downloaded from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar
> (306 B at 2.4 kB/s){}}}{{{}[INFO]
> {}}}{{{}[INFO]
> BUILD FAILURE{}}}{{{}[INFO]
> {}}}{{{}[INFO]
> Total time: 1.378 s{}}}{{{}[INFO] Finished at:
> 2024-05-28T10:23:05-06:00{}}}{{{}[INFO]
> {}}}{{{}[ERROR]
> Failed to execute goal on project sample: Could not resolve dependencies for
> project org.openjfx:sample:jar:1.0.0: The following artifacts could not be
> resolved: org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 (absent),
> org.openjfx:javafx-graphics:jar:${javafx.platform}:22.0.1 (absent),
>
[jira] [Assigned] (MNG-8147) Profile interpolation broke their evaluation
[
https://issues.apache.org/jira/browse/MNG-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8147:
Assignee: Tamas Cservenak
> Profile interpolation broke their evaluation
>
>
> Key: MNG-8147
> URL: https://issues.apache.org/jira/browse/MNG-8147
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> The change for improvement MNG-8081 broke Maven Model Builder in a way, it
> cannot now properly build projects that have {_}duplicated profile IDs{_}.
> Again, these projects are anyway "just working by chance" (as some dependency
> POM is invalid), but 3.9.6 was building these projects just fine.
> The issue MNG-8141 is created to WARN end users about this.
> This issue should restore 3.9.7 breakage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8147) Profile interpolation broke their evaluation
Tamas Cservenak created MNG-8147:
Summary: Profile interpolation broke their evaluation
Key: MNG-8147
URL: https://issues.apache.org/jira/browse/MNG-8147
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 3.9.7
Reporter: Tamas Cservenak
Fix For: 3.9.8
The change for improvement MNG-8081 broke Maven Model Builder in a way, it
cannot now properly build projects that have {_}duplicated profile IDs{_}.
Again, these projects are anyway "just working by chance" (as some dependency
POM is invalid), but 3.9.6 was building these projects just fine.
The issue MNG-8141 is created to WARN end users about this.
This issue should restore 3.9.7 breakage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[ https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8141: - Description: ModelBuilder is component building models (POM + interpolating + parent inheritance and many many more things), but it should not rely that built model "was validated", as it MAY NOT been validated: for "furthest" models it builds, like a parent of a some-level-dependency we use MIN level of validation (minimal validation). Still, while the model builder builds, it relies on several aspects of the model, and it should ensure that the "output" (built model) is correct. Model Builder hence must be changed in way, that IF it detects any issue _during building_ of the model, and IF it appears with even slightest possibility that it cannot deliver "correct output", it must add WARNs to model building result with proper messages. One typical case is when model building injects activated profiles (as they can deliver properties and extra plugins and what not) and activation code detects a "problem", like for example duplicated profile IDs being used (this IS catched by validation, but not on MIN level!), hence, model builder cannot guarantee that built model IS correct. This change is really only to make Maven emit WARNINGs if project being built has some "far POMs" (like parent pom of a dependency of a first level dependency, as in reproducer). If model builder cannot be "100% sure" it built model correctly, it should be reported. Moreover, WARNs of model building result were simply neglected so fat (lost). Having warnings like these would reveal "invalid parent POM" early, as it is case in issue MNG-8131 for example. was: ModelBuilder is component building models (POM + interpolating + parent inheritance and many many more things), but it should not rely that built model "was validated", as it MAY NOT been validated: for "furthest" models it builds, like a parent of a some-level-dependency we use MIN level of validation (minimal validation). Still, while the model builder builds, it relies on several aspects of the model, and it should ensure that the "output" (built model) is correct. Model Builder hence must be changed in way, that IF it detects any issue _during building_ of the model, and IF it appears with even slightest possibility that it cannot deliver "correct output", it must fail model building with proper messages. One typical case is when model building injects activated profiles (as they can deliver properties and extra plugins and what not) and activation code detects a "problem", like for example duplicated profile IDs being used (this IS catched by validation, but not on MIN level!), hence, model builder cannot guarantee that built model IS correct. This change is really only to make Maven emit WARNINGs if project being built has some "far POMs" (like parent pom of a dependency of a first level dependency, as in reproducer). If model builder cannot be "100% sure" it built model correctly, it should be reported. Moreover, WARNs of model building result were simply neglected so fat (lost). Having warnings like these would reveal "invalid parent POM" early, as it is case in issue MNG-8131 for example. > Model Builder should report if not sure about "fully correct" outcome > - > > Key: MNG-8141 > URL: https://issues.apache.org/jira/browse/MNG-8141 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > ModelBuilder is component building models (POM + interpolating + parent > inheritance and many many more things), but it should not rely that built > model "was validated", as it MAY NOT been validated: for "furthest" models it > builds, like a parent of a some-level-dependency we use MIN level of > validation (minimal validation). > Still, while the model builder builds, it relies on several aspects of the > model, and it should ensure that the "output" (built model) is correct. Model > Builder hence must be changed in way, that IF it detects any issue _during > building_ of the model, and IF it appears with even slightest possibility > that it cannot deliver "correct output", it must add WARNs to model building > result with proper messages. > One typical case is when model building injects activated profiles (as they > can deliver properties and extra plugins and what not) and activation code > detects a "problem", like for example duplicated profile IDs being used (this > IS catched by validation, but not on MIN level!), hence, model builder cannot > guarantee that built model IS correct. > This change is really only to make Maven
[jira] [Updated] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[
https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8141:
-
Description:
ModelBuilder is component building models (POM + interpolating + parent
inheritance and many many more things), but it should not rely that built model
"was validated", as it MAY NOT been validated: for "furthest" models it builds,
like a parent of a some-level-dependency we use MIN level of validation
(minimal validation).
Still, while the model builder builds, it relies on several aspects of the
model, and it should ensure that the "output" (built model) is correct. Model
Builder hence must be changed in way, that IF it detects any issue _during
building_ of the model, and IF it appears with even slightest possibility that
it cannot deliver "correct output", it must fail model building with proper
messages.
One typical case is when model building injects activated profiles (as they can
deliver properties and extra plugins and what not) and activation code detects
a "problem", like for example duplicated profile IDs being used (this IS
catched by validation, but not on MIN level!), hence, model builder cannot
guarantee that built model IS correct.
This change is really only to make Maven emit WARNINGs if project being built
has some "far POMs" (like parent pom of a dependency of a first level
dependency, as in reproducer). If model builder cannot be "100% sure" it built
model correctly, it should be reported. Moreover, WARNs of model building
result were simply neglected so fat (lost). Having warnings like these would
reveal "invalid parent POM" early, as it is case in issue MNG-8131 for example.
was:
ModelBuilder is component building models (POM + interpolating + parent
inheritance and many many more things), but it should not rely that built model
"was validated", as it MAY NOT been validated: for "furthest" models it builds,
like a parent of a some-level-dependency we use MIN level of validation
(minimal validation).
Still, while the model builder builds, it relies on several aspects of the
model, and it should ensure that the "output" (built model) is correct. Model
Builder hence must be changed in way, that IF it detects any issue _during
building_ of the model, and IF it appears with even slightest possibility that
it cannot deliver "correct output", it must fail model building with proper
messages.
One typical case is when model building injects activated profiles (as they can
deliver properties and extra plugins and what not) and activation code detects
a "problem", like for example duplicated profile IDs being used (this IS
catched by validation, but not on MIN level!), hence, model builder cannot
guarantee that built model IS correct.
Projects "stuck" on invalid models can use "escape hatch"
{{-Dmaven.modelBuilder.failOnInvalidModel=false}} that reverts to original
Maven behaviour, as reported in issue MNG-8131 for example.
> Model Builder should report if not sure about "fully correct" outcome
> -
>
> Key: MNG-8141
> URL: https://issues.apache.org/jira/browse/MNG-8141
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> ModelBuilder is component building models (POM + interpolating + parent
> inheritance and many many more things), but it should not rely that built
> model "was validated", as it MAY NOT been validated: for "furthest" models it
> builds, like a parent of a some-level-dependency we use MIN level of
> validation (minimal validation).
> Still, while the model builder builds, it relies on several aspects of the
> model, and it should ensure that the "output" (built model) is correct. Model
> Builder hence must be changed in way, that IF it detects any issue _during
> building_ of the model, and IF it appears with even slightest possibility
> that it cannot deliver "correct output", it must fail model building with
> proper messages.
> One typical case is when model building injects activated profiles (as they
> can deliver properties and extra plugins and what not) and activation code
> detects a "problem", like for example duplicated profile IDs being used (this
> IS catched by validation, but not on MIN level!), hence, model builder cannot
> guarantee that built model IS correct.
> This change is really only to make Maven emit WARNINGs if project being built
> has some "far POMs" (like parent pom of a dependency of a first level
> dependency, as in reproducer). If model builder cannot be "100% sure" it
> built model correctly, it should be reported. Moreover, WARNs of model
> building result were simply neglected
[jira] [Updated] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[
https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8141:
-
Summary: Model Builder should report if not sure about "fully correct"
outcome (was: Model Builder should not rely on "validity" of processed model)
> Model Builder should report if not sure about "fully correct" outcome
> -
>
> Key: MNG-8141
> URL: https://issues.apache.org/jira/browse/MNG-8141
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> ModelBuilder is component building models (POM + interpolating + parent
> inheritance and many many more things), but it should not rely that built
> model "was validated", as it MAY NOT been validated: for "furthest" models it
> builds, like a parent of a some-level-dependency we use MIN level of
> validation (minimal validation).
> Still, while the model builder builds, it relies on several aspects of the
> model, and it should ensure that the "output" (built model) is correct. Model
> Builder hence must be changed in way, that IF it detects any issue _during
> building_ of the model, and IF it appears with even slightest possibility
> that it cannot deliver "correct output", it must fail model building with
> proper messages.
> One typical case is when model building injects activated profiles (as they
> can deliver properties and extra plugins and what not) and activation code
> detects a "problem", like for example duplicated profile IDs being used (this
> IS catched by validation, but not on MIN level!), hence, model builder cannot
> guarantee that built model IS correct.
> Projects "stuck" on invalid models can use "escape hatch"
> {{-Dmaven.modelBuilder.failOnInvalidModel=false}} that reverts to original
> Maven behaviour, as reported in issue MNG-8131 for example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852917#comment-17852917 ] Tamas Cservenak commented on MPLUGIN-504: - WDYM "even if heuristics do not fails"... and you still get "goal prefix must be set" error? > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852916#comment-17852916 ] Tamas Cservenak commented on MPLUGIN-504: - Am pretty much sure 99% (maybe, but 80% for sure) of plugins _have_ goalPrefix (either via heuristics or via explicit config), so we are talking about quite few plugins here... > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8140) When a model is discarded (by model builder) for whatever reason, show why it happened
[
https://issues.apache.org/jira/browse/MNG-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8140.
Resolution: Fixed
Fixed with
3.9
[https://github.com/apache/maven/commit/66266e53156fded27f25d1de8532087cdb6dad13]
master
https://github.com/apache/maven/commit/dd670bf9a1d789b9221d97c53fdcd10780696286
> When a model is discarded (by model builder) for whatever reason, show why it
> happened
> --
>
> Key: MNG-8140
> URL: https://issues.apache.org/jira/browse/MNG-8140
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> Currently, when a model is discarded as "invalid", Maven 3.x shows this line
> in console:
> {noformat}
> [WARNING] The POM for org.openjfx:javafx-controls:jar:22.0.1 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details{noformat}
> And then when user uses {{-X}} and battles himself thru a TON of debug logs,
> will find the cause WHY the model was discarded (despite it was all there
> even in non-debug session).
> I want to know from first hand (and as soon as possible) WHY a model was
> discarded, so we should modify this output to:
> * do not "redirect" me at debug output
> * immediately tell me why
> Note: Maven4 already have the CLI switch {{-sadp}} "strict artifact
> descriptor policy" that will FAIL the build when it hits an "invalid" model,
> as users usually don't want invalid models in their builds (is most often
> usually some dev mistake, like using property for version/classifier while
> not defining that property). This issue affects Maven4 as well, as if the
> switch is used, build will fail due "invalid model", but user is still left
> in dark WHY.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8146) Drop use of commons-lang
[
https://issues.apache.org/jira/browse/MNG-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8146.
Assignee: Tamas Cservenak
Resolution: Fixed
> Drop use of commons-lang
>
>
> Key: MNG-8146
> URL: https://issues.apache.org/jira/browse/MNG-8146
> Project: Maven
> Issue Type: Task
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> Maven 4 already did this. By introspection, it turns out that 3.9 is also
> very lightly use commons-lang, while it in fact represents quite noticeable
> overhead of the ZIP distro size (10% almost). Without commons-lang Maven
> 3.9.x distro is 9MB only.
> Moreover, the presence of commons-lang just introduced some peculiarities:
> * confusion over StringUtils (vs Plexus Utils StringUtils)
> * skewed param validation: according to commons-lang string "2." is not a
> valid float, while Float.parseFloat nicely parses it into 2.0 (see MNG-7756)
> * PR ended up with {_}same LOC but noticeable smaller ZIP distro{_}, meaning
> not much was really used out of it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8142) If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why
[
https://issues.apache.org/jira/browse/MNG-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8142.
Resolution: Fixed
Fixed with:
3.9
[https://github.com/apache/maven/commit/200dc02da850d29a1bf1c912fbfb7c938532e189#diff-a39ec57c0b993c16c526bec7a5fd9067301127ec339cc5384c27634b9ff03e77]
master
https://github.com/apache/maven/commit/9db546ddb905392c6c4df9484895bf11182ab303
> If JDK profile activator gets "invalid" JDK version for whatever reason, it
> chokes but does not tell why
>
>
> Key: MNG-8142
> URL: https://issues.apache.org/jira/browse/MNG-8142
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> The JDK profile activator uses property {{java.version}} to determine is
> profile active or not, but if you look at MNG-3746 you can see that Maven
> _allows overriding that property_ by user, but also, today some "weird
> formatted" version may pop up in the wild.
> The JDK profile activator is not prepared for these cases, and will just
> throw (NumberFormatEx), without telling why it did belly up.
> Improve the message why it throw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852790#comment-17852790
]
Tamas Cservenak commented on MNG-7868:
--
[~rec] can you tell me more about failed build?
* what goal was you running
* I assume you use "built in" parallel builder, so what was -T param
* anything else that may be important? Like I also assume the two mentioned
artifacts (sentencepiece and bar-api) are all external dependencies?
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852786#comment-17852786
]
Tamas Cservenak commented on MNG-7868:
--
Just realized something: Maven 3.9.7 carries fix for _file locking_ (see
MRESOLVER-522), while Richard uses LocalReadWriteLockNamedLockFactory.
Which is okay, I just wanted to clear up this. Most probably we still have some
issues and bugs lurking somewhere.
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852779#comment-17852779
]
Tamas Cservenak commented on MNG-7868:
--
Need to take a peek what is happening in
aQute.bnd.maven.lib.resolve.DependencyResolver... stay tuned.
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852771#comment-17852771
]
Tamas Cservenak commented on MNG-7868:
--
sentencepiece: can you tell what was the stack trace of this:
Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write
lock for 'artifact:ai.djl.sentencepiece:sentencepiece:0.26.0' in 30 SECONDS at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:202)
Basically what operation was resolver doing (that made it to acquire lock)?
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: image-2024-04-10-15-44-37-013.png, screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8146) Drop use of commons-lang
Tamas Cservenak created MNG-8146:
Summary: Drop use of commons-lang
Key: MNG-8146
URL: https://issues.apache.org/jira/browse/MNG-8146
Project: Maven
Issue Type: Task
Reporter: Tamas Cservenak
Fix For: 3.9.8
Maven 4 already did this. By introspection, it turns out that 3.9 is also very
lightly use commons-lang, while it in fact represents quite noticeable overhead
of the ZIP distro size (10% almost). Without commons-lang Maven 3.9.x distro is
9MB only.
Moreover, the presence of commons-lang just introduced some peculiarities:
* confusion over StringUtils (vs Plexus Utils StringUtils)
* skewed param validation: according to commons-lang string "2." is not a
valid float, while Float.parseFloat nicely parses it into 2.0 (see MNG-7756)
* PR ended up with {_}same LOC but noticeable smaller ZIP distro{_}, meaning
not much was really used out of it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7902) Sort plugins in validation report
[ https://issues.apache.org/jira/browse/MNG-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7902: Assignee: Guillaume Nodet > Sort plugins in validation report > - > > Key: MNG-7902 > URL: https://issues.apache.org/jira/browse/MNG-7902 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Michael Keppler >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > Attachments: image-2023-10-07-13-33-27-762.png > > > Please don't ever output the content of a Set for consumption by humans > without sorting it first. The order is otherwise "random". Sorting (case > insensitive) makes the same output easier to read, especially when trying to > find one specific entry (e.g. "Did we fix plugin foo already?") > !image-2023-10-07-13-33-27-762.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8066.
Resolution: Fixed
Fixed with
* 3.9.x
[https://github.com/apache/maven/commit/865072025d98c54e2270d4e41f8d6da0ce5ab036]
* master
https://github.com/apache/maven/commit/9ce85ef4f4469287aae8a1e43e3d6960d41b746c
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-504) [regression] Goal prefix is required now
[
https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852526#comment-17852526
]
Tamas Cservenak edited comment on MPLUGIN-504 at 6/5/24 6:23 PM:
-
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form for artifactId, and similarly, the
heuristics from the maven-plugin-plugin "lifts" the prefix part and makes it
goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618
(allows copy-pasting/reusing Maven log output), as anyway majority of plugins
(that followed artifactId naming convention) had prefix already. Moreover,
prefix is used in G level metadata for plugin discovery as well (explained in
[https://maven.apache.org/settings.html#plugin-groups]) that without prefix
present is not possible.
was (Author: cstamas):
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618
(allows copy-pasting/reusing Maven log output), as anyway majority of plugins
(that followed artifactId naming convention) had prefix already. Moreover,
prefix is used in G level metadata for plugin discovery as well (explained in
[https://maven.apache.org/settings.html#plugin-groups]) that without prefix
present is not possible.
> [regression] Goal prefix is required now
>
>
> Key: MPLUGIN-504
> URL: https://issues.apache.org/jira/browse/MPLUGIN-504
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression
> introduced that leads to previous working builds fail if the have not
> configured a goalprefix, the error message is:
> > You need to specify a goalPrefix as it can not be correctly computed
> This has several issues:
> # It does not explain why one "needs" a goalPrefix, nor what it is useful for
> or why it can not be correctly computed.
> # It is effectively a breaking change in a minor version increment
> # The inital JIRA mentions that
> a) in general, goal prefix is *+optional+*, but "good to have", and usually
> is present.
> b) we may want to have some option to turn off this feature
> # Now it is required and there is no option to turn it off
> Also the message is not true, the plugin has successfully computed a prefix
> before without any issues:
> * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the
> my-cool was chosen
> * If the artifact ends with -plugin as in my-cool-plugin the my-cool was
> chosen
> * otherwise the full artifact if was chosen as a prefix as in my-cool the
> my-cool was chosen
> From a users point of view I don't see any problem or "disambiguates" with
> this approach that justifies a breaking change here, anyone who is concerned
> about not using this default can and already could choose a prefix and seem
> to been fine with it for a long time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-504) [regression] Goal prefix is required now
[
https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852526#comment-17852526
]
Tamas Cservenak edited comment on MPLUGIN-504 at 6/5/24 6:21 PM:
-
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618
(allows copy-pasting/reusing Maven log output), as anyway majority of plugins
(that followed artifactId naming convention) had prefix already. Moreover,
prefix is used in G level metadata for plugin discovery as well (explained in
[https://maven.apache.org/settings.html#plugin-groups]) that without prefix
present is not possible.
was (Author: cstamas):
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618,
as anyway majority of plugins (that followed artifactId naming convention) had
prefix already. Moreover, prefix is used in G level metadata for plugin
discovery as well (explained in
[https://maven.apache.org/settings.html#plugin-groups]) that without prefix
present is not possible.
> [regression] Goal prefix is required now
>
>
> Key: MPLUGIN-504
> URL: https://issues.apache.org/jira/browse/MPLUGIN-504
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression
> introduced that leads to previous working builds fail if the have not
> configured a goalprefix, the error message is:
> > You need to specify a goalPrefix as it can not be correctly computed
> This has several issues:
> # It does not explain why one "needs" a goalPrefix, nor what it is useful for
> or why it can not be correctly computed.
> # It is effectively a breaking change in a minor version increment
> # The inital JIRA mentions that
> a) in general, goal prefix is *+optional+*, but "good to have", and usually
> is present.
> b) we may want to have some option to turn off this feature
> # Now it is required and there is no option to turn it off
> Also the message is not true, the plugin has successfully computed a prefix
> before without any issues:
> * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the
> my-cool was chosen
> * If the artifact ends with -plugin as in my-cool-plugin the my-cool was
> chosen
> * otherwise the full artifact if was chosen as a prefix as in my-cool the
> my-cool was chosen
> From a users point of view I don't see any problem or "disambiguates" with
> this approach that justifies a breaking change here, anyone who is concerned
> about not using this default can and already could choose a prefix and seem
> to been fine with it for a long time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-504) [regression] Goal prefix is required now
[
https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852526#comment-17852526
]
Tamas Cservenak edited comment on MPLUGIN-504 at 6/5/24 6:20 PM:
-
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618,
as anyway majority of plugins (that followed artifactId naming convention) had
prefix already. Moreover, prefix is used in G level metadata for plugin
discovery as well (explained in
[https://maven.apache.org/settings.html#plugin-groups]) that without prefix
present is not possible.
was (Author: cstamas):
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618,
as anyway majority of plugins (that followed artifactId naming convention) had
prefix already. Moreover, prefix is used in G level metadata for plugin
discovery as well (explained in
https://maven.apache.org/settings.html#plugin-groups).
> [regression] Goal prefix is required now
>
>
> Key: MPLUGIN-504
> URL: https://issues.apache.org/jira/browse/MPLUGIN-504
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression
> introduced that leads to previous working builds fail if the have not
> configured a goalprefix, the error message is:
> > You need to specify a goalPrefix as it can not be correctly computed
> This has several issues:
> # It does not explain why one "needs" a goalPrefix, nor what it is useful for
> or why it can not be correctly computed.
> # It is effectively a breaking change in a minor version increment
> # The inital JIRA mentions that
> a) in general, goal prefix is *+optional+*, but "good to have", and usually
> is present.
> b) we may want to have some option to turn off this feature
> # Now it is required and there is no option to turn it off
> Also the message is not true, the plugin has successfully computed a prefix
> before without any issues:
> * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the
> my-cool was chosen
> * If the artifact ends with -plugin as in my-cool-plugin the my-cool was
> chosen
> * otherwise the full artifact if was chosen as a prefix as in my-cool the
> my-cool was chosen
> From a users point of view I don't see any problem or "disambiguates" with
> this approach that justifies a breaking change here, anyone who is concerned
> about not using this default can and already could choose a prefix and seem
> to been fine with it for a long time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[
https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852526#comment-17852526
]
Tamas Cservenak commented on MPLUGIN-504:
-
Right, so the story short: Maven Core plugins (those maintained by Apache Maven
project) have {{artifactId}} in form of {{{}maven-$prefix-plugin{}}}. Here, the
heuristics from the {{maven-plugin-plugin}} (that ironically have prefix
{{{}plugin{}}}) "lifts" the {{$prefix}} part and makes it goalPrefix.
Convention for "non core plugins" (for example
[mojohaus|https://github.com/mojohaus/] plugins, but every other as well) is in
turn use the {{$prefix-maven-plugin}} form, and similarly, the heuristics from
the maven-plugin-plugin "lifts" the prefix part and makes it goalPrefix.
Problem is when this "heuristics" (that is quite simplistic) fails, and no
goalPrefix gets found. In that case use config as:
{noformat}
org.apache.maven.plugins
maven-plugin-plugin
3.13.1
myprefix
{noformat}
The rationale behind requiring plugin prefix was change explained in MNG-7618,
as anyway majority of plugins (that followed artifactId naming convention) had
prefix already. Moreover, prefix is used in G level metadata for plugin
discovery as well (explained in
https://maven.apache.org/settings.html#plugin-groups).
> [regression] Goal prefix is required now
>
>
> Key: MPLUGIN-504
> URL: https://issues.apache.org/jira/browse/MPLUGIN-504
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression
> introduced that leads to previous working builds fail if the have not
> configured a goalprefix, the error message is:
> > You need to specify a goalPrefix as it can not be correctly computed
> This has several issues:
> # It does not explain why one "needs" a goalPrefix, nor what it is useful for
> or why it can not be correctly computed.
> # It is effectively a breaking change in a minor version increment
> # The inital JIRA mentions that
> a) in general, goal prefix is *+optional+*, but "good to have", and usually
> is present.
> b) we may want to have some option to turn off this feature
> # Now it is required and there is no option to turn it off
> Also the message is not true, the plugin has successfully computed a prefix
> before without any issues:
> * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the
> my-cool was chosen
> * If the artifact ends with -plugin as in my-cool-plugin the my-cool was
> chosen
> * otherwise the full artifact if was chosen as a prefix as in my-cool the
> my-cool was chosen
> From a users point of view I don't see any problem or "disambiguates" with
> this approach that justifies a breaking change here, anyone who is concerned
> about not using this default can and already could choose a prefix and seem
> to been fine with it for a long time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7902) Sort plugins in validation report
[ https://issues.apache.org/jira/browse/MNG-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7902: - Fix Version/s: 4.0.0 3.9.8 > Sort plugins in validation report > - > > Key: MNG-7902 > URL: https://issues.apache.org/jira/browse/MNG-7902 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Michael Keppler >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > Attachments: image-2023-10-07-13-33-27-762.png > > > Please don't ever output the content of a Set for consumption by humans > without sorting it first. The order is otherwise "random". Sorting (case > insensitive) makes the same output easier to read, especially when trying to > find one specific entry (e.g. "Did we fix plugin foo already?") > !image-2023-10-07-13-33-27-762.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8144) Update to Guava 32.2.1-jre
[ https://issues.apache.org/jira/browse/MNG-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8144. Resolution: Fixed > Update to Guava 32.2.1-jre > -- > > Key: MNG-8144 > URL: https://issues.apache.org/jira/browse/MNG-8144 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8143) Update to commons-cli 1.8.0
[ https://issues.apache.org/jira/browse/MNG-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8143. Resolution: Fixed > Update to commons-cli 1.8.0 > --- > > Key: MNG-8143 > URL: https://issues.apache.org/jira/browse/MNG-8143 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8135:
Assignee: Tamas Cservenak
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name, arch or version has capital letters, it won't activate the
> profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8135.
Resolution: Fixed
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name, arch or version has capital letters, it won't activate the
> profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8145) GOAWAY received
[
https://issues.apache.org/jira/browse/MNG-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852500#comment-17852500
]
Tamas Cservenak commented on MNG-8145:
--
Just FTR, Maven 4 uses Java HttpClient transport by default, and user can use
{{-Daether.transport.jdk.httpVersion=HTTP_1_1}} user property to force HTTP/1.1
(as by default HTTP/2 is used if remote end supports). See
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-11/configuration.html]
Other options are to switch transport to "apache", or "jetty"
> GOAWAY received
>
>
> Key: MNG-8145
> URL: https://issues.apache.org/jira/browse/MNG-8145
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 4.0.0-beta-3
>Reporter: Filipe Roque
>Priority: Major
>
> When using a repository mirror with an nginx reverse proxy, HTTP/2 connection
> may fail due to reaching
> [keepalive_requests:|http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests]
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.felix:maven-bundle-plugin:5.1.9:manifest (bundle-manifest) on
> project commons-io: Execution bundle-manifest of goal
> org.apache.felix:maven-bundle-plugin:5.1.9:manifest failed: Plugin
> org.apache.felix:maven-bundle-plugin:5.1.9 or one of its dependencies could
> not be resolved: Failed to collect dependencies at
> org.apache.felix:maven-bundle-plugin:jar:5.1.9 ->
> org.apache.maven:maven-archiver:jar:3.5.2: Failed to read artifact descriptor
> for org.slf4j:slf4j-api:jar:1.7.25: The following artifacts could not be
> resolved: org.slf4j:slf4j-api:pom:1.7.25 (absent): Could not transfer
> artifact org.slf4j:slf4j-api:pom:1.7.25 from/to maven-localrepository1
> (https://localhost:8443/central): /127.0.0.1:42086: GOAWAY received -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> {code}
>
> This can be reproduced with:
> {code:bash}
> git clone --quiet --branch rel/commons-io-2.16.1
> g...@github.com:apache/commons-io.git && cd commons-io
> # builds OK without mirror and empty local repository
> TEMP_M2=$(mktemp -d)
> echo $TEMP_M2
> cat >$TEMP_M2/empty_settings.xml <
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
> EOF
> /opt/maven/apache-maven-4.0.0-beta-3/bin/mvn -s $TEMP_M2/empty_settings.xml
> -Dmaven.repo.local=$TEMP_M2 -q clean verify -DskipTests
> # prepare a nginx mirror
> mkdir -p /tmp/docker-ssl-proxy/
> openssl req -subj '/CN=localhost' -x509 -newkey rsa:4096 -nodes -keyout
> /tmp/docker-ssl-proxy/key.pem -out /tmp/docker-ssl-proxy/cert.pem -days 365
> cat >/tmp/docker-ssl-proxy/default.conf < server {
> listen 443 ssl;
> http2 on;
> # lower default value of 1000 for easier demonstration
> keepalive_requests 500;
> ssl_certificate /etc/nginx/conf.d/cert.pem;
> ssl_certificate_key /etc/nginx/conf.d/key.pem;
> location /central {
> proxy_pass https://repo.maven.apache.org/maven2;
> }
> }
> EOF
> docker run -d --rm \
> --name my-custom-nginx-container \
> -p 8443:443 \
> -v /tmp/docker-ssl-proxy/:/etc/nginx/conf.d/ \
> nginx:1.27.0
> cp /etc/ssl/certs/adoptium/cacerts /tmp/docker-ssl-proxy/mykeystore.jks
> keytool \
> -keystore /tmp/docker-ssl-proxy/mykeystore.jks \
> -storepass changeit \
> -importcert \
> -alias SITENAME \
> -trustcacerts \
> -file /tmp/docker-ssl-proxy/cert.pem
> TEMP_M2=$(mktemp -d)
> echo $TEMP_M2
> cat >$TEMP_M2/mirror_settings.xml <
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> maven-localrepository1
> central
> https://localhost:8443/central
>
>
>
> EOF
> export
> MAVEN_OPTS='-Djavax.net.ssl.trustStore=/tmp/docker-ssl-proxy/mykeystore.jks
> -Djavax.net.ssl.trustStorePassword=changeit'
> /opt/maven/apache-maven-4.0.0-beta-3/bin/mvn -s $TEMP_M2/mirror_settings.xml
> -Dmaven.repo.local=$TEMP_M2 -q clean verify -DskipTests {code}
>
> Does not happen with, which only use HTTP/1.1
> {code:java}
> /opt/maven/apache-maven-3.9.7/bin/mvn -s $TEMP_M2/mirror_settings.xml
> -Dmaven.repo.local=$TEMP_M2 -q clean verify -DskipTests
> /opt/maven/apache-maven-4.0.0-beta-3/bin/mvn -s $TEMP_M2/mirror_settings.xml
>
[jira] [Assigned] (MNG-8144) Update to Guava 32.2.1-jre
[ https://issues.apache.org/jira/browse/MNG-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8144: Assignee: Tamas Cservenak > Update to Guava 32.2.1-jre > -- > > Key: MNG-8144 > URL: https://issues.apache.org/jira/browse/MNG-8144 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8143) Update to commons-cli 1.8.0
[ https://issues.apache.org/jira/browse/MNG-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8143: Assignee: Tamas Cservenak > Update to commons-cli 1.8.0 > --- > > Key: MNG-8143 > URL: https://issues.apache.org/jira/browse/MNG-8143 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8143) Update to commons-cli 1.8.0
Tamas Cservenak created MNG-8143: Summary: Update to commons-cli 1.8.0 Key: MNG-8143 URL: https://issues.apache.org/jira/browse/MNG-8143 Project: Maven Issue Type: Dependency upgrade Components: Dependencies Reporter: Tamas Cservenak Fix For: 3.9.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8144) Update to Guava 32.2.1-jre
Tamas Cservenak created MNG-8144: Summary: Update to Guava 32.2.1-jre Key: MNG-8144 URL: https://issues.apache.org/jira/browse/MNG-8144 Project: Maven Issue Type: Dependency upgrade Components: Dependencies Reporter: Tamas Cservenak Fix For: 3.9.8 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8135) Activate profile by capital OS name fail
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8135:
-
Fix Version/s: 4.0.0
3.9.8
4.0.0-beta-4
> Activate profile by capital OS name fail
>
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name has capital letters, it can not activate the profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8140) When a model is discarded (by model builder) for whatever reason, show why it happened
[
https://issues.apache.org/jira/browse/MNG-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8140:
-
Fix Version/s: 4.0.0
> When a model is discarded (by model builder) for whatever reason, show why it
> happened
> --
>
> Key: MNG-8140
> URL: https://issues.apache.org/jira/browse/MNG-8140
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> Currently, when a model is discarded as "invalid", Maven 3.x shows this line
> in console:
> {noformat}
> [WARNING] The POM for org.openjfx:javafx-controls:jar:22.0.1 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details{noformat}
> And then when user uses {{-X}} and battles himself thru a TON of debug logs,
> will find the cause WHY the model was discarded (despite it was all there
> even in non-debug session).
> I want to know from first hand (and as soon as possible) WHY a model was
> discarded, so we should modify this output to:
> * do not "redirect" me at debug output
> * immediately tell me why
> Note: Maven4 already have the CLI switch {{-sadp}} "strict artifact
> descriptor policy" that will FAIL the build when it hits an "invalid" model,
> as users usually don't want invalid models in their builds (is most often
> usually some dev mistake, like using property for version/classifier while
> not defining that property). This issue affects Maven4 as well, as if the
> switch is used, build will fail due "invalid model", but user is still left
> in dark WHY.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8141) Model Builder should not rely on "validity" of processed model
[
https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8141:
-
Fix Version/s: 4.0.0
> Model Builder should not rely on "validity" of processed model
> --
>
> Key: MNG-8141
> URL: https://issues.apache.org/jira/browse/MNG-8141
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> ModelBuilder is component building models (POM + interpolating + parent
> inheritance and many many more things), but it should not rely that built
> model "was validated", as it MAY NOT been validated: for "furthest" models it
> builds, like a parent of a some-level-dependency we use MIN level of
> validation (minimal validation).
> Still, while the model builder builds, it relies on several aspects of the
> model, and it should ensure that the "output" (built model) is correct. Model
> Builder hence must be changed in way, that IF it detects any issue _during
> building_ of the model, and IF it appears with even slightest possibility
> that it cannot deliver "correct output", it must fail model building with
> proper messages.
> One typical case is when model building injects activated profiles (as they
> can deliver properties and extra plugins and what not) and activation code
> detects a "problem", like for example duplicated profile IDs being used (this
> IS catched by validation, but not on MIN level!), hence, model builder cannot
> guarantee that built model IS correct.
> Projects "stuck" on invalid models can use "escape hatch"
> {{-Dmaven.modelBuilder.failOnInvalidModel=false}} that reverts to original
> Maven behaviour, as reported in issue MNG-8131 for example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8142) If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why
[
https://issues.apache.org/jira/browse/MNG-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8142:
-
Fix Version/s: 4.0.0
> If JDK profile activator gets "invalid" JDK version for whatever reason, it
> chokes but does not tell why
>
>
> Key: MNG-8142
> URL: https://issues.apache.org/jira/browse/MNG-8142
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> The JDK profile activator uses property {{java.version}} to determine is
> profile active or not, but if you look at MNG-3746 you can see that Maven
> _allows overriding that property_ by user, but also, today some "weird
> formatted" version may pop up in the wild.
> The JDK profile activator is not prepared for these cases, and will just
> throw (NumberFormatEx), without telling why it did belly up.
> Improve the message why it throw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-565) Rename null selectors to more natural name
Tamas Cservenak created MRESOLVER-565:
-
Summary: Rename null selectors to more natural name
Key: MRESOLVER-565
URL: https://issues.apache.org/jira/browse/MRESOLVER-565
Project: Maven Resolver
Issue Type: Task
Components: Resolver
Reporter: Tamas Cservenak
Fix For: 2.0.0, 2.0.0-beta-1
The classes {{NullProxySelector}} and {{NullAuthenticationSelector}} are badly
named, in way that unlike other implementations of {{ProxySelector}} and
{{AuthenticationSelector}} implementations, they do not "find out" any proxies
or auth, they literally return "what remote repository instance passed in has".
Is more like "identity" or "passthrough" implementation, not "null".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8066:
Assignee: Tamas Cservenak
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attribute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8116:
-
Fix Version/s: 4.0.0
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attribute
> -
>
> Key: MNG-8116
> URL: https://issues.apache.org/jira/browse/MNG-8116
> Project: Maven
> Issue Type: Task
> Components: Plugin Requests
>Affects Versions: 3.9.6
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> Originally discovered via a Jetty bug report see
> https://github.com/jetty/jetty.project/issues/11732
> The bean to configured have the following overloading method naming:
> * public void setExtraClasspath(String extraClasspath)
> * public void setExtraClasspath(List extraClasspath)
> The plugin configuration:
>
> ${basedir}/config
>
> even forcing the implementation attribute doesn't help
>
>implementation="java.lang.String">${basedir}/config
>
> The fix is implemented via the PR
> https://github.com/eclipse/sisu.plexus/pull/52
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8066:
-
Fix Version/s: 4.0.0
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8141) Model Builder should not rely on "validity" of processed model
[
https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8141:
-
Description:
ModelBuilder is component building models (POM + interpolating + parent
inheritance and many many more things), but it should not rely that built model
"was validated", as it MAY NOT been validated: for "furthest" models it builds,
like a parent of a some-level-dependency we use MIN level of validation
(minimal validation).
Still, while the model builder builds, it relies on several aspects of the
model, and it should ensure that the "output" (built model) is correct. Model
Builder hence must be changed in way, that IF it detects any issue _during
building_ of the model, and IF it appears with even slightest possibility that
it cannot deliver "correct output", it must fail model building with proper
messages.
One typical case is when model building injects activated profiles (as they can
deliver properties and extra plugins and what not) and activation code detects
a "problem", like for example duplicated profile IDs being used (this IS
catched by validation, but not on MIN level!), hence, model builder cannot
guarantee that built model IS correct.
Projects "stuck" on invalid models can use "escape hatch"
{{-Dmaven.modelBuilder.failOnInvalidModel=false}} that reverts to original
Maven behaviour, as reported in issue MNG-8131 for example.
was:
ModelBuilder is component building models (POM + interpolating + parent
inheritance and many many more things), but it should not rely that built model
"was validated", as it MAY NOT been validated: for "furthest" models it builds,
like a parent of a some-level-dependency we use MIN level of validation
(minimal validation).
Still, while the model builder builds, it relies on several aspects of the
model, and it should ensure that the "output" (built model) is correct. Model
Builder hence must be changed in way, that IF it detects any issue _during
building_ of the model, and IF it appears with even slightest possibility that
it cannot deliver "correct output", it must fail model building with proper
messages.
One typical case is when model building injects activated profiles (as they can
deliver properties and extra plugins and what not) and activation code detects
a "problem", like for example duplicated profile IDs being used (this IS
catched by validation, but not on MIN level!), hence, model builder cannot
guarantee that built model IS correct.
> Model Builder should not rely on "validity" of processed model
> --
>
> Key: MNG-8141
> URL: https://issues.apache.org/jira/browse/MNG-8141
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8, 4.0.0-beta-4
>
>
> ModelBuilder is component building models (POM + interpolating + parent
> inheritance and many many more things), but it should not rely that built
> model "was validated", as it MAY NOT been validated: for "furthest" models it
> builds, like a parent of a some-level-dependency we use MIN level of
> validation (minimal validation).
> Still, while the model builder builds, it relies on several aspects of the
> model, and it should ensure that the "output" (built model) is correct. Model
> Builder hence must be changed in way, that IF it detects any issue _during
> building_ of the model, and IF it appears with even slightest possibility
> that it cannot deliver "correct output", it must fail model building with
> proper messages.
> One typical case is when model building injects activated profiles (as they
> can deliver properties and extra plugins and what not) and activation code
> detects a "problem", like for example duplicated profile IDs being used (this
> IS catched by validation, but not on MIN level!), hence, model builder cannot
> guarantee that built model IS correct.
> Projects "stuck" on invalid models can use "escape hatch"
> {{-Dmaven.modelBuilder.failOnInvalidModel=false}} that reverts to original
> Maven behaviour, as reported in issue MNG-8131 for example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8142) If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why
[
https://issues.apache.org/jira/browse/MNG-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8142:
Assignee: Tamas Cservenak
> If JDK profile activator gets "invalid" JDK version for whatever reason, it
> chokes but does not tell why
>
>
> Key: MNG-8142
> URL: https://issues.apache.org/jira/browse/MNG-8142
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8, 4.0.0-beta-4
>
>
> The JDK profile activator uses property {{java.version}} to determine is
> profile active or not, but if you look at MNG-3746 you can see that Maven
> _allows overriding that property_ by user, but also, today some "weird
> formatted" version may pop up in the wild.
> The JDK profile activator is not prepared for these cases, and will just
> throw (NumberFormatEx), without telling why it did belly up.
> Improve the message why it throw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8142) If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why
Tamas Cservenak created MNG-8142:
Summary: If JDK profile activator gets "invalid" JDK version for
whatever reason, it chokes but does not tell why
Key: MNG-8142
URL: https://issues.apache.org/jira/browse/MNG-8142
Project: Maven
Issue Type: Bug
Components: Core
Reporter: Tamas Cservenak
Fix For: 3.9.8, 4.0.0-beta-4
The JDK profile activator uses property {{java.version}} to determine is
profile active or not, but if you look at MNG-3746 you can see that Maven
_allows overriding that property_ by user, but also, today some "weird
formatted" version may pop up in the wild.
The JDK profile activator is not prepared for these cases, and will just throw
(NumberFormatEx), without telling why it did belly up.
Improve the message why it throw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8131) Property replacement in dependency pom no longer works
[
https://issues.apache.org/jira/browse/MNG-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8131:
Assignee: Tamas Cservenak
> Property replacement in dependency pom no longer works
> --
>
> Key: MNG-8131
> URL: https://issues.apache.org/jira/browse/MNG-8131
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7
> Environment: macOS 14.5 (23F79)
>Reporter: Taylor Smock
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.8
>
>
> h1. The problem:{{{}{}}}
> Classifiers in dependency poms are no longer replaced (either due to
> performing profile activation of a parent pom of the dependency, or not
> performing replacement of a property).{{{}{}}}
> Steps to reproduce (from [https://openjfx.io/openjfx-docs/#maven] )
> # {{m{{{}vn archetype:generate
> -DarchetypeGroupId=org.openjfx
> -DarchetypeArtifactId=javafx-archetype-simple -DarchetypeVersion=0.0.3
> -DgroupId=org.openjfx -DartifactId=sample -Dversion=1.0.0
> -Djavafx-version=22.0.1{}
> # {{{}mvn compile{{{}{}}}[INFO] Scanning for projects...{}}}{{{}[INFO]
> {}}}{{{}[INFO] -< org.openjfx:sample
> >-{}}}{{{}[INFO] Building sample 1.0.0{}}}{{{}[INFO]
> from pom.xml{}}}{{{}[INFO] [ jar
> ]-{}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.pom
> (908 B at 1.9 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx/22.0.1/javafx-22.0.1.pom
> (8.4 kB at 165 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.pom
> (904 B at 21 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.pom
> (749 B at 17 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1.jar
> (306 B at 6.8 kB/s){}}}{{{}Downloading from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar{}}}{{{}Downloading
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1-$%7Bjavafx.platform%7D.jar{}}}{{{}Downloaded
> from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1.jar
> (302 B at 2.4 kB/s){}}}{{{}Downloaded from central:
> https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1.jar
> (306 B at 2.4 kB/s){}}}{{{}[INFO]
> {}}}{{{}[INFO]
> BUILD FAILURE{}}}{{{}[INFO]
> {}}}{{{}[INFO]
> Total time: 1.378 s{}}}{{{}[INFO] Finished at:
> 2024-05-28T10:23:05-06:00{}}}{{{}[INFO]
> {}}}{{{}[ERROR]
> Failed to execute goal on project sample: Could not resolve dependencies for
> project org.openjfx:sample:jar:1.0.0: The following artifacts could not be
> resolved: org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 (absent),
> org.openjfx:javafx-graphics:jar:${javafx.platform}:22.0.1 (absent),
> org.openjfx:javafx-base:jar:${javafx.platform}:22.0.1 (absent): Could not
> find artifact org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 in
> central
[jira] [Commented] (MNG-8027) Maven cannot be embedded in applications that have upgraded Guice to 7.0+
[
https://issues.apache.org/jira/browse/MNG-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852377#comment-17852377
]
Tamas Cservenak commented on MNG-8027:
--
Maven relies on Eclipse Sisu that relies on javax namespace still... Maven
cannot move until [https://github.com/eclipse-sisu/sisu-project/issues/92] is
fixed and new Sisu released.
> Maven cannot be embedded in applications that have upgraded Guice to 7.0+
> -
>
> Key: MNG-8027
> URL: https://issues.apache.org/jira/browse/MNG-8027
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.6
>Reporter: Basil Crow
>Priority: Major
>
> With Java 17, install Jenkins 2.442, create a Maven installation for Maven
> 3.9.6, and create a Maven project building e.g.
> [https://github.com/basil/simple-maven-project-with-tests]. The job should
> succeed.
> Now run the same job against [https://github.com/jenkinsci/jenkins/pull/8889]
> which upgrades Guice from 6.0 (which supports both {{javax.inject}} and
> {{jakarta.inject}} imports) to 7.0 (which only supports {{jakarta.inject}}
> imports). The job fails with:
> {noformat}
> java.lang.IllegalArgumentException: org.eclipse.sisu.Parameters is not a
> binding annotation. Please annotate it with @BindingAnnotation.
> at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:218)
> at com.google.inject.Key.ensureIsBindingAnnotation(Key.java:382)
> at com.google.inject.Key.strategyFor(Key.java:370)
> at com.google.inject.Key.get(Key.java:229)
> at org.eclipse.sisu.wire.ParameterKeys.(ParameterKeys.java:28)
> Caused: java.lang.ExceptionInInitializerError
> at
> org.eclipse.sisu.wire.DependencyAnalyzer.(DependencyAnalyzer.java:93)
> at
> org.eclipse.sisu.wire.ElementAnalyzer.(ElementAnalyzer.java:104)
> at org.eclipse.sisu.wire.WireModule.configure(WireModule.java:74)
> at
> com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:426)
> at com.google.inject.spi.Elements.getElements(Elements.java:113)
> at
> com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:160)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:87)
> at com.google.inject.Guice.createInjector(Guice.java:69)
> at com.google.inject.Guice.createInjector(Guice.java:59)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:206)
> at
> org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:168)
> at
> hudson.maven.MavenEmbedderUtils.buildPlexusContainer(MavenEmbedderUtils.java:166)
> at
> hudson.maven.MavenEmbedderUtils.buildPlexusContainer(MavenEmbedderUtils.java:159)
> at hudson.maven.MavenEmbedder.(MavenEmbedder.java:110)
> at hudson.maven.MavenEmbedder.(MavenEmbedder.java:137)
> at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:211)
> at
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1324)
> at
> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1124)
> at hudson.FilePath.act(FilePath.java:1236)
> at hudson.FilePath.act(FilePath.java:1219)
> at
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.parsePoms(MavenModuleSetBuild.java:985)
> at
> hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:689)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
> at hudson.model.Run.execute(Run.java:1895)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
> at hudson.model.ResourceController.execute(ResourceController.java:101)
> at hudson.model.Executor.run(Executor.java:442)
> {noformat}
> This is blocking us from upgrading Guice from 6.0 to 7.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8051) Combine dependency scopes instead of overriding
[
https://issues.apache.org/jira/browse/MNG-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852375#comment-17852375
]
Tamas Cservenak edited comment on MNG-8051 at 6/5/24 10:43 AM:
---
This sounds wrong: if you need jakarta.inject-api in "compile" scope, it means
you compile against it (is best practice anyway) to declare it as compile
dependency (and not rely on 3rd party dependency to "pull it in for you").
Moreover, hibernate-core that you declare in "compile" scope declares inject in
"runtime" scope:
[https://repo.maven.apache.org/maven2/org/hibernate/orm/hibernate-core/6.4.1.Final/hibernate-core-6.4.1.Final.pom]
While the other dependency "querydsl-apt" you put in provided scope (and that
"transforms" whole subtree of that node to "provided", as it is initially in
"compile"):
[https://repo.maven.apache.org/maven2/io/github/openfeign/querydsl/querydsl-apt/6.0.2/querydsl-apt-6.0.2.pom]
How could Maven out of these deduce you want "compile" scope Inject? Again, you
declared two deps, the one in "compile" scope sets inject to "runtime", while
other is put by you in "provided" scope.
Maven chooses the scope of node that is "closer":
{noformat}
[cstamas@angeleyes MNG-8051]$ mvn eu.maveniverse.maven.plugins:toolbox:tree
-DverboseTree
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.cstamas:mng-8051 >---
[INFO] Building mng-8051 1.0.0
[INFO] from pom.xml
[INFO] ---[ jar ]
[INFO]
[INFO] — toolbox:0.1.23:tree (default-cli) @ mng-8051 —
[INFO] org.cstamas:mng-8051:jar:1.0.0
[INFO] +- org.hibernate.orm:hibernate-core:jar:6.4.1.Final [compile]
[INFO] | +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [compile]
[INFO] | +- jakarta.transaction:jakarta.transaction-api:jar:2.0.1 [compile]
[INFO] | +- org.jboss.logging:jboss-logging:jar:3.5.0.Final [runtime]
[INFO] | +- org.hibernate.common:hibernate-commons-annotations:jar:6.0.6.Final
[runtime]
[INFO] | +- io.smallrye:jandex:jar:3.1.2 [runtime]
[INFO] | +- com.fasterxml:classmate:jar:1.5.1 [runtime]
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.14.7 [runtime]
[INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
[INFO] | | - jakarta.activation:jakarta.activation-api:jar:2.1.0 [runtime]
[INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:4.0.2 [runtime]
[INFO] | | - org.glassfish.jaxb:jaxb-core:jar:4.0.2 [runtime]
[INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
(nearer exists)
[INFO] | | +- jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.eclipse.angus:angus-activation:jar:2.0.0 [runtime]
[INFO] | | | - jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.glassfish.jaxb:txw2:jar:4.0.2 [runtime]
[INFO] | | - com.sun.istack:istack-commons-runtime:jar:4.1.1 [runtime]
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [runtime]
[INFO] | - org.antlr:antlr4-runtime:jar:4.13.0 [runtime]
[INFO] - io.github.openfeign.querydsl:querydsl-apt:jar:jpa:6.0.2 [provided]
[INFO] +- io.github.openfeign.querydsl:querydsl-codegen:jar:6.0.2 [provided]
[INFO] | +- io.github.openfeign.querydsl:querydsl-core:jar:6.0.2 [provided]
[INFO] | | +- com.mysema.commons:mysema-commons-lang:jar:0.2.4 [provided]
[INFO] | | - jakarta.annotation:jakarta.annotation-api:jar:2.1.1
[provided] (nearer exists)
[INFO] | +- io.github.openfeign.querydsl:codegen-utils:jar:6.0.2 [provided]
[INFO] | | +- org.eclipse.jdt:ecj:jar:3.33.0 [provided]
[INFO] | | - io.github.classgraph:classgraph:jar:4.8.165 [provided]
(nearer exists)
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [provided] (nearer
exists)
[INFO] | - io.github.classgraph:classgraph:jar:4.8.165 [provided]
[INFO] +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [provided]
(nearer exists)
[INFO] - jakarta.annotation:jakarta.annotation-api:jar:2.1.1 [provided]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.204 s
[INFO] Finished at: 2024-06-05T12:34:22+02:00
[INFO]
[cstamas@angeleyes MNG-8051]${noformat}
was (Author: cstamas):
This sounds wrong: if you need jakarta.inject-api in "compile" scope, it means
you compile against it (is best practice anyway) to declare it as compile
dependency (and not rely on 3rd party dependency to "pull it in for you").
Moreover, hibernate-core that you declare in "compile" scope declares inject in
"runtime" scope:
[jira] [Comment Edited] (MNG-8051) Combine dependency scopes instead of overriding
[
https://issues.apache.org/jira/browse/MNG-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852375#comment-17852375
]
Tamas Cservenak edited comment on MNG-8051 at 6/5/24 10:42 AM:
---
This sounds wrong: if you need jakarta.inject-api in "compile" scope, it means
you compile against it (is best practice anyway) to declare it as compile
dependency (and not rely on 3rd party dependency to "pull it in for you").
Moreover, hibernate-core that you declare in "compile" scope declares inject in
"runtime" scope:
[https://repo.maven.apache.org/maven2/org/hibernate/orm/hibernate-core/6.4.1.Final/hibernate-core-6.4.1.Final.pom]
While the other dependency "querydsl-apt" you put in provided scope (and that
"transforms" whole subtree of that node to "provided", as it is initially in
"compile"):
[https://repo.maven.apache.org/maven2/io/github/openfeign/querydsl/querydsl-apt/6.0.2/querydsl-apt-6.0.2.pom]
How could Maven out of these deduce you want "compile" scope Inject? Again, you
declared two deps, the one in "compile" scope sets inject to "runtime", while
other is put by you in "provided" scope.
Maven chooses the scope of node that is "closer":
{noformat}
[cstamas@angeleyes MNG-8051]$ mvn eu.maveniverse.maven.plugins:toolbox:tree
-DverboseTree
[INFO] Scanning for projects...
[INFO]
[INFO] ---< org.cstamas:mng-8051 >---
[INFO] Building mng-8051 1.0.0
[INFO] from pom.xml
[INFO] ---[ jar ]
[INFO]
[INFO] — toolbox:0.1.23:tree (default-cli) @ mng-8051 —
[INFO] org.cstamas:mng-8051:jar:1.0.0
[INFO] +- org.hibernate.orm:hibernate-core:jar:6.4.1.Final [compile]
[INFO] | +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [compile]
[INFO] | +- jakarta.transaction:jakarta.transaction-api:jar:2.0.1 [compile]
[INFO] | +- org.jboss.logging:jboss-logging:jar:3.5.0.Final [runtime]
[INFO] | +- org.hibernate.common:hibernate-commons-annotations:jar:6.0.6.Final
[runtime]
[INFO] | +- io.smallrye:jandex:jar:3.1.2 [runtime]
[INFO] | +- com.fasterxml:classmate:jar:1.5.1 [runtime]
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.14.7 [runtime]
[INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
[INFO] | | - jakarta.activation:jakarta.activation-api:jar:2.1.0 [runtime]
[INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:4.0.2 [runtime]
[INFO] | | - org.glassfish.jaxb:jaxb-core:jar:4.0.2 [runtime]
[INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
(nearer exists)
[INFO] | | +- jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.eclipse.angus:angus-activation:jar:2.0.0 [runtime]
[INFO] | | | - jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.glassfish.jaxb:txw2:jar:4.0.2 [runtime]
[INFO] | | - com.sun.istack:istack-commons-runtime:jar:4.1.1 [runtime]
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [runtime]
[INFO] | - org.antlr:antlr4-runtime:jar:4.13.0 [runtime]
[INFO] - io.github.openfeign.querydsl:querydsl-apt:jar:jpa:6.0.2 [provided]
[INFO] +- io.github.openfeign.querydsl:querydsl-codegen:jar:6.0.2 [provided]
[INFO] | +- io.github.openfeign.querydsl:querydsl-core:jar:6.0.2 [provided]
[INFO] | | +- com.mysema.commons:mysema-commons-lang:jar:0.2.4 [provided]
[INFO] | | - jakarta.annotation:jakarta.annotation-api:jar:2.1.1
[provided] (nearer exists)
[INFO] | +- io.github.openfeign.querydsl:codegen-utils:jar:6.0.2 [provided]
[INFO] | | +- org.eclipse.jdt:ecj:jar:3.33.0 [provided]
[INFO] | | - io.github.classgraph:classgraph:jar:4.8.165 [provided]
(nearer exists)
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [provided] (nearer
exists)
[INFO] | - io.github.classgraph:classgraph:jar:4.8.165 [provided]
[INFO] +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [provided]
(nearer exists)
[INFO] - jakarta.annotation:jakarta.annotation-api:jar:2.1.1 [provided]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.204 s
[INFO] Finished at: 2024-06-05T12:34:22+02:00
[INFO]
[cstamas@angeleyes MNG-8051]${noformat}
was (Author: cstamas):
This sounds wrong: if you need jakarta.inject-api in "compile" scope, it means
you compile against it (is best practice anyway) to declare it as compile
dependency (and not rely on 3rd party dependency to "pull it in for you").
Moreover, hibernate-core that you declare in "compile" scope declares inject in
"runtime" scope:
[jira] [Commented] (MNG-8051) Combine dependency scopes instead of overriding
[
https://issues.apache.org/jira/browse/MNG-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852375#comment-17852375
]
Tamas Cservenak commented on MNG-8051:
--
This sounds wrong: if you need jakarta.inject-api in "compile" scope, it means
you compile against it (is best practice anyway) to declare it as compile
dependency (and not rely on 3rd party dependency to "pull it in for you").
Moreover, hibernate-core that you declare in "compile" scope declares inject in
"runtime" scope:
[https://repo.maven.apache.org/maven2/org/hibernate/orm/hibernate-core/6.4.1.Final/hibernate-core-6.4.1.Final.pom]
While the other dependency "querydsl-apt" you put in provided scope (and that
"transforms" whole subtree of that node to "provided", as it is initially in
"compile"):
[https://repo.maven.apache.org/maven2/io/github/openfeign/querydsl/querydsl-apt/6.0.2/querydsl-apt-6.0.2.pom]
How could Maven out of these deduce you want "compile" scope Inject? Again, you
declared two deps, the one in "compile" scope sets inject to "runtime", while
other is put by you in "provided" scope.
Maven chooses the scope of node that is "closer":
{noformat}
[cstamas@angeleyes MNG-8051]$ mvn eu.maveniverse.maven.plugins:toolbox:tree
-DverboseTree
[INFO] Scanning for projects...
[INFO]
[INFO] < org.cstamas:mng-8051 >
[INFO] Building mng-8051 1.0.0
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- toolbox:0.1.23:tree (default-cli) @ mng-8051 ---
[INFO] org.cstamas:mng-8051:jar:1.0.0
[INFO] +- org.hibernate.orm:hibernate-core:jar:6.4.1.Final [compile]
[INFO] | +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [compile]
[INFO] | +- jakarta.transaction:jakarta.transaction-api:jar:2.0.1 [compile]
[INFO] | +- org.jboss.logging:jboss-logging:jar:3.5.0.Final [runtime]
[INFO] | +- org.hibernate.common:hibernate-commons-annotations:jar:6.0.6.Final
[runtime]
[INFO] | +- io.smallrye:jandex:jar:3.1.2 [runtime]
[INFO] | +- com.fasterxml:classmate:jar:1.5.1 [runtime]
[INFO] | +- net.bytebuddy:byte-buddy:jar:1.14.7 [runtime]
[INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
[INFO] | | \- jakarta.activation:jakarta.activation-api:jar:2.1.0 [runtime]
[INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:4.0.2 [runtime]
[INFO] | | \- org.glassfish.jaxb:jaxb-core:jar:4.0.2 [runtime]
[INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:4.0.0 [runtime]
(nearer exists)
[INFO] | | +- jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.eclipse.angus:angus-activation:jar:2.0.0 [runtime]
[INFO] | | | \- jakarta.activation:jakarta.activation-api:jar:2.1.1
[runtime] (conflicts with 2.1.0)
[INFO] | | +- org.glassfish.jaxb:txw2:jar:4.0.2 [runtime]
[INFO] | | \- com.sun.istack:istack-commons-runtime:jar:4.1.1 [runtime]
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [runtime]
[INFO] | \- org.antlr:antlr4-runtime:jar:4.13.0 [runtime]
[INFO] \- io.github.openfeign.querydsl:querydsl-apt:jar:jpa:6.0.2 [provided]
[INFO] +- io.github.openfeign.querydsl:querydsl-codegen:jar:6.0.2 [provided]
[INFO] | +- io.github.openfeign.querydsl:querydsl-core:jar:6.0.2 [provided]
[INFO] | | +- com.mysema.commons:mysema-commons-lang:jar:0.2.4 [provided]
[INFO] | | \- jakarta.annotation:jakarta.annotation-api:jar:2.1.1
[provided] (nearer exists)
[INFO] | +- io.github.openfeign.querydsl:codegen-utils:jar:6.0.2 [provided]
[INFO] | | +- org.eclipse.jdt:ecj:jar:3.33.0 [provided]
[INFO] | | \- io.github.classgraph:classgraph:jar:4.8.165 [provided]
(nearer exists)
[INFO] | +- jakarta.inject:jakarta.inject-api:jar:2.0.1 [provided] (nearer
exists)
[INFO] | \- io.github.classgraph:classgraph:jar:4.8.165 [provided]
[INFO] +- jakarta.persistence:jakarta.persistence-api:jar:3.1.0 [provided]
(nearer exists)
[INFO] \- jakarta.annotation:jakarta.annotation-api:jar:2.1.1 [provided]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.204 s
[INFO] Finished at: 2024-06-05T12:34:22+02:00
[INFO]
[cstamas@angeleyes MNG-8051]${noformat}
> Combine dependency scopes instead of overriding
> ---
>
> Key: MNG-8051
> URL: https://issues.apache.org/jira/browse/MNG-8051
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.9.6
>Reporter: James Howe
>Priority: Minor
>
> I discovered this situation when combining these dependencies:
> {code:xml}
>
>
[jira] [Updated] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8066:
-
Fix Version/s: 3.9.8
4.0.0-beta-4
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
> Fix For: 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8114) install plugin failed with NPE for profiles activated by files existing
[
https://issues.apache.org/jira/browse/MNG-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8114.
Resolution: Fixed
> install plugin failed with NPE for profiles activated by files existing
> ---
>
> Key: MNG-8114
> URL: https://issues.apache.org/jira/browse/MNG-8114
> Project: Maven
> Issue Type: Bug
> Environment: Apache Maven 4.0.0-alpha-14-SNAPSHOT
> (9fc4f499172637c403f27808d5c0ccd0c770f93c)
> Maven home:
> C:\Users\sellersj\Downloads\apache-maven-4.0.0-alpha-14-20240425.054714-33-bin
> Java version: 21.0.3, vendor: Eclipse Adoptium, runtime:
> C:\devtools\java\jdk21
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "winnt"
>Reporter: Jim Sellers
>Priority: Major
>
> This is a change between apache-maven-4.0.0-alpha-13 and
> 4.0.0-alpha-14-SNAPSHOT which I understand is not released yet.
> This happens both on windows and linux. If an app has a profile that's
> activated by a file existing or not, it will generate a NPE
> {code:XML|title=pom.xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> com.example
> Zminimal
> 0.0.1-SNAPSHOT
> jar
>
> 8
> 8
> UTF-8
> UTF-8
>
>
>
> is-webapp
>
>
> ${basedir}/src/main/webapp/
>
>
>
>
>
> {code}
> {code:title=log snipit}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project Zminimal: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Cannot
> invoke
> "org.apache.maven.internal.impl.model.ProfileActivationFilePathInterpolator.interpolate(String,
> org.apache.maven.api.services.model.ProfileActivationContext)" because
> "this.profileActivationFilePathInterpolator" is null -> [Help 1]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8112) extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path
[ https://issues.apache.org/jira/browse/MNG-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852373#comment-17852373 ] Tamas Cservenak commented on MNG-8112: -- This is by design: this file resolves and adds to classpath. ext class path means is already on classpath. > extension.xml is ignored when extension is loaded by -Dmaven.ext.class.path > --- > > Key: MNG-8112 > URL: https://issues.apache.org/jira/browse/MNG-8112 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.9.6 >Reporter: Rich DiCroce >Priority: Major > > As the title says: extension.xml is ignored when an extension is loaded by > -Dmaven.ext.class.path, which makes it impossible to expose any additional > packages. > I am filing this as a bug due to [this > comment|https://issues.apache.org/jira/browse/MNG-6906?focusedCommentId=17719869=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17719869] > on MNG-6906, which says that lib/ext and -Dmaven.ext.class.path are supposed > to be synonymous. Note that MNG-6906 is a related but different problem. > When looking at org.apache.maven.cli.MavenCli, the problems aren't too hard > to see: > # lib/ext extensions get loaded into the plexus.core realm (as per m2.conf), > but -Dmaven.ext.class.path extensions are loaded into the maven.ext realm (as > per MavenCli#setupContainerRealm()). > # loadCoreExtensions() operates on the coreRealm, but due to #1, the > extensions are not in that realm. Also, the result of parseExtClasspath() is > not passed to loadCoreExtensions(), so there is no way for > loadCoreExtensions() to find the relevant files. > The most obvious solution would be to call coreRealm.addURL() for each of the > files discovered by parseExtClasspath(). This would solve #1 above which > would implicitly fix #2. Though I don't know if it would have other > consequences. > If this is not a bug and is instead "works as designed", then > [https://maven.apache.org/guides/mini/guide-using-extensions.html] needs to > be updated to explain that the three methods of loading core extensions are > not equivalent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8004) Enhance location tracking
[ https://issues.apache.org/jira/browse/MNG-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8004. Resolution: Duplicate > Enhance location tracking > - > > Key: MNG-8004 > URL: https://issues.apache.org/jira/browse/MNG-8004 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.x-candidate, 4.0.0 > > > So far location tracking gives us source file, line num and col num, which is > fine. > But historically, Maven2 had only parent POMs, Maven3 introduced import POMs, > while Maven4 will have things like XInclude as well. > It would be great if we could enhance location with 4th element: "why (or > how) did this element end up here". Was it from current POM, from parent > maybe? From import-pom? Or was it XIncluded? -- This message was sent by Atlassian Jira (v8.20.10#820010)
