[jira] [Commented] (MNG-6737) StackOverflowError when version ranges are unsolvable and graph contains a cycle
[
https://issues.apache.org/jira/browse/MNG-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17093602#comment-17093602
]
Tomo Suzuki commented on MNG-6737:
--
Thank you.
> StackOverflowError when version ranges are unsolvable and graph contains a
> cycle
>
>
> Key: MNG-6737
> URL: https://issues.apache.org/jira/browse/MNG-6737
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> Maven throws StackOverflowError when version ranges are unsolvable and the
> dependency graph contains a cycle.
> {code:java}
> $ mvn install
> ...
> [INFO] --< suztomo:module-c
> >--
> [INFO] Building module-c 1.0
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.406 s
> [INFO] Finished at: 2019-08-16T12:10:30-04:00
> [INFO]
>
> ...
> Exception in thread "main" java.lang.StackOverflowError
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> ...(omitting many lines)...
> {code}
> h1. Example
> Example project to reproduce the issue:
> [https://github.com/suztomo/maven-cyclic-dependency-with-range]
> h1. Diagnosis
> In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
> 1.16.1),
> [org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
> tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
> the exception PathRecordingDependencyVisitor visits nodes in the dependency
> graph and the graph contains a cycle. The visitor goes to infinite recursion
> in visiting the cyclic path, resulting in StackOverflowError.
>
> {code:java}
> private UnsolvableVersionConflictException newFailure( final ConflictContext
> context )
> {
> ...
> PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
> filter );
> context.getRoot().accept( visitor );
> return new UnsolvableVersionConflictException( visitor.getPaths() );
> }{code}
>
> The cycle in the graph consists of module-a and module-b as illustrated below:
> {code:java}
> module-c:1.0.0
> +- module-b:2.0.0
> +- module-a:1.0.0
> +- module-b:0.0.1
> +- module-b:1.0.0
> | +- module-a:1.0.0
> | +- module-b:0.0.1
> | +- module-b:1.0.0
>...{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824520#comment-16824520
]
Tomo Suzuki edited comment on MNG-6357 at 4/13/20, 6:14 PM:
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | +- suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | +- suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
was (Author: suztomo):
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | +- suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | +- suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082550#comment-17082550 ] Tomo Suzuki commented on MNG-6357: -- For building a class path for different artifactIDs, it does not. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021433#comment-17021433
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 7:58 PM:
---
Now PR is to special-case UnknownHostException. Running
maven-integration-testing.
Test passed.
was (Author: suztomo):
Now PR is to special-case UnknownHostException. Running
maven-integration-testing.
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021433#comment-17021433
]
Tomo Suzuki commented on MNG-6732:
--
Now PR is to special-case UnknownHostException. Running
maven-integration-testing.
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 5:46 PM:
---
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
MavenRepositorySystemUtils creates a session that holds "ignoreMissing" and
"ignoreInvalid".
{code:java}
session.setArtifactDescriptorPolicy( new
SimpleArtifactDescriptorPolicy( true, true ) );
{code}
Special-cased {{ChecksumFailureException}}, then it hits
testmng5175_ReadTimeOutFromSettings.
was (Author: suztomo):
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
MavenRepositorySystemUtils creates a session that holds "ignoreMissing" and
"ignoreInvalid".
{code:java}
session.setArtifactDescriptorPolicy( new
SimpleArtifactDescriptorPolicy( true, true ) );
{code}
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1.
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 4:56 PM:
---
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
MavenRepositorySystemUtils creates a session that holds "ignoreMissing" and
"ignoreInvalid".
{code:java}
session.setArtifactDescriptorPolicy( new
SimpleArtifactDescriptorPolicy( true, true ) );
{code}
was (Author: suztomo):
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
MavenRepositorySystemUtils creates a session that "ignoreMissing" and
"ignoreInvalid".
{code:java}
session.setArtifactDescriptorPolicy( new
SimpleArtifactDescriptorPolicy( true, true ) );
{code}
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
>
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 4:56 PM:
---
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
MavenRepositorySystemUtils creates a session that "ignoreMissing" and
"ignoreInvalid".
{code:java}
session.setArtifactDescriptorPolicy( new
SimpleArtifactDescriptorPolicy( true, true ) );
{code}
was (Author: suztomo):
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 4:54 PM:
---
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
In the two phases:
* collectDependencies (reads pom.xml and builds dependencyGraph)
* resolveDependencies (downloads JAR files)
was (Author: suztomo):
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws
[jira] [Comment Edited] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki edited comment on MNG-6732 at 1/22/20 4:47 PM:
---
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
The exception is thrown in DefaultProjectDependenciesResolver:
{code:java}
try
{
process( result, repoSystem.resolveDependencies( session,
depRequest ).getArtifactResults() );
}
catch ( org.eclipse.aether.resolution.DependencyResolutionException e )
{
process( result, e.getResult().getArtifactResults() );
throw new DependencyResolutionException( result, "Could not resolve
dependencies for project "
+ project.getId() + ": " + e.getMessage(), e );
}
{code}
was (Author: suztomo):
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
>
[jira] [Commented] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17021268#comment-17021268
]
Tomo Suzuki commented on MNG-6732:
--
Memo:
Investigation on mng-3470 test case failure:
{noformat}
suztomo@suxtomo24:~/maven-integration-testing/core-it-suite/target/test-classes/mng-3470$
/usr/local/google/home/suztomo/app/maven/apache-maven-3.7.0-SNAPSHOT/bin/mvnDebug
validate --settings settings.xml
Preparing to execute Maven in debug mode
Listening for transport dt_socket at address: 8000
{noformat}
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h1. Problem
> Sometimes [Linkage Checker enforcer
> rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
> does not receive resolved artifact list because of a missing artifact even
> when the missing artifact is unused after Maven's dependency mediation.
> h1. Background
> The enforcer rule fails to retrieve artifact list through
> {{DefaultProjectDependenciesResolver.resolve}} when applied to
> [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
> because of the missing {{xerces:xerces-impl:2.6.2}}, even though the
> artifact does not appear in the final dependency graph. The artifact does not
> appear in the graph because of Maven's dependency mediation.
> Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
> In contrast, the enforcer rule can retrieve artifact list when applied to
> [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
> project even though it outputs "[WARNING] The POM for
> xerces:xerces-impl:jar:2.6.2 is missing, no dependency information
> available". The missing artifact does not appear in final dependency graph.
> [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
> h1. Diagnosis
> Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
> ArtifactNotFoundException. This allows
> {{DefaultProjectDependenciesResolver.resolve}} calls
> {{repoSystem.resolveDependencies}} to obtain partially resolved artifact
> list, rather than failing entirely, when there is a missing artifact (such as
> {{xerces:xerces-impl:2.6.2}})
> However, when a retired Maven repository is involved (such as
> [http://repository.codehaus.org/] ),
> {{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
> and throws ArtifactDescriptorException without checking
> "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
> {{DefaultProjectDependenciesResolver.resolve}} does not return partially
> resolved artifact list.
> {code:java}
> catch ( ArtifactResolutionException e )
> {
> if ( e.getCause() instanceof ArtifactNotFoundException )
> {
> missingDescriptor( session, trace, a, (Exception)
> e.getCause() );
> if ( ( getPolicy( session, a, request ) &
> ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
> {
> return null;
> }
> }
> result.addException( e );
> throw new ArtifactDescriptorException( result );
> }
> {code}
> from
> [DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
> ArtifactNotFoundException is a special case of
> [ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
> h1. Example Project
> Example project to demonstrate the diagnosis:
> [https://github.com/suztomo/maven-missing-artifact] . In this example, even
> though module-b and module-c have the same dependency section, module-c fails
> to run Maven because of a repository section containing a retired repository
> URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MNG-6732:
-
Description:
h1. Problem
Sometimes [Linkage Checker enforcer
rule|https://github.com/GoogleCloudPlatform/cloud-opensource-java/tree/master/enforcer-rules]
does not receive resolved artifact list because of a missing artifact even
when the missing artifact is unused after Maven's dependency mediation.
h1. Background
The enforcer rule fails to retrieve artifact list through
{{DefaultProjectDependenciesResolver.resolve}} when applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing {{xerces:xerces-impl:2.6.2}}, even though the artifact
does not appear in the final dependency graph. The artifact does not appear in
the graph because of Maven's dependency mediation.
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
In contrast, the enforcer rule can retrieve artifact list when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
The missing artifact does not appear in final dependency graph.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently {{DefaultArtifactDescriptorReader.loadPom}} method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
{{DefaultProjectDependenciesResolver.resolve}} calls
{{repoSystem.resolveDependencies}} to obtain partially resolved artifact list,
rather than failing entirely, when there is a missing artifact (such as
{{xerces:xerces-impl:2.6.2}})
However, when a retired Maven repository is involved (such as
[http://repository.codehaus.org/] ),
{{DefaultArtifactDescriptorReader.loadPom}} gets an ArtifactTransferException
and throws ArtifactDescriptorException without checking
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt below), and thus
{{DefaultProjectDependenciesResolver.resolve}} does not return partially
resolved artifact list.
{code:java}
catch ( ArtifactResolutionException e )
{
if ( e.getCause() instanceof ArtifactNotFoundException )
{
missingDescriptor( session, trace, a, (Exception)
e.getCause() );
if ( ( getPolicy( session, a, request ) &
ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
{
return null;
}
}
result.addException( e );
throw new ArtifactDescriptorException( result );
}
{code}
from
[DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
ArtifactNotFoundException is a special case of
[ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
h1. Example Project
Example project to demonstrate the diagnosis:
[https://github.com/suztomo/maven-missing-artifact] . In this example, even
though module-b and module-c have the same dependency section, module-c fails
to run Maven because of a repository section containing a retired repository
URL.
was:
h1. Problem
Sometimes my Maven enforcer rule does not receive resolved artifact list
because of missing artifact even when the missing artifact does not appear in
the final dependency graph.
h1. Background
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
My enforcer rule can retrieve artifact list through
DefaultProjectDependenciesResolver.resolve when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
The missing artifact does not appear in final dependency graph.
On the other hand, the enforcer rule fails to retrieve artifact list when
applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing xerces:xerces-impl:2.6.2, even though the artifact
should not appear in the final dependency graph.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently DefaultArtifactDescriptorReader.loadPom method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies
to obtain
[jira] [Updated] (MSHARED-850) Upgrade org.eclipse.aether:aether-util dependency in org.apache.maven.shared:maven-dependency-tree
[
https://issues.apache.org/jira/browse/MSHARED-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MSHARED-850:
Description:
There was a problem
https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1091 .
Outdated dependency of caused a runtime error.
{noformat}
Caused by: java.lang.IllegalAccessError: tried to access method
org.eclipse.aether.util.ChecksumUtils.toHexString([B)Ljava/lang/String; from
class org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum
at org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum.get
(ChecksumCalculator.java:100)
at org.eclipse.aether.connector.basic.ChecksumCalculator.get
(ChecksumCalculator.java:213)
at
org.eclipse.aether.connector.basic.TransferTransportListener.getChecksums
(TransferTransportListener.java:134)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:460)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:364)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
(RunnableErrorForwarder.java:67)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:644)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:499)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:401)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:229)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:207)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:240)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:171)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
(DefaultDependencyCollector.java:541)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
(DefaultDependencyCollector.java:524)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:412)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:169)
at
com.google.cloud.tools.dependencies.enforcer.LinkageCheckerRule.findProjectClasspath
(LinkageCheckerRule.java:261)
at
[jira] [Updated] (MSHARED-850) Upgrade org.eclipse.aether:aether-util dependency in org.apache.maven.shared:maven-dependency-tree
[
https://issues.apache.org/jira/browse/MSHARED-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MSHARED-850:
Description:
There was a problem
https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1091 .
Outdated dependency of org.eclipse.aether:aether-util caused a runtime error.
{noformat}
Caused by: java.lang.IllegalAccessError: tried to access method
org.eclipse.aether.util.ChecksumUtils.toHexString([B)Ljava/lang/String; from
class org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum
at org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum.get
(ChecksumCalculator.java:100)
at org.eclipse.aether.connector.basic.ChecksumCalculator.get
(ChecksumCalculator.java:213)
at
org.eclipse.aether.connector.basic.TransferTransportListener.getChecksums
(TransferTransportListener.java:134)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:460)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:364)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
(RunnableErrorForwarder.java:67)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:644)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:499)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:401)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:229)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:207)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:240)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:171)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
(DefaultDependencyCollector.java:541)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
(DefaultDependencyCollector.java:524)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:412)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:169)
at
com.google.cloud.tools.dependencies.enforcer.LinkageCheckerRule.findProjectClasspath
(LinkageCheckerRule.java:261)
at
[jira] [Created] (MSHARED-850) Upgrade org.eclipse.aether:aether-util dependency in org.apache.maven.shared:maven-dependency-tree
Tomo Suzuki created MSHARED-850:
---
Summary: Upgrade org.eclipse.aether:aether-util dependency in
org.apache.maven.shared:maven-dependency-tree
Key: MSHARED-850
URL: https://issues.apache.org/jira/browse/MSHARED-850
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-dependency-tree
Reporter: Tomo Suzuki
https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1091
Outdated dependency caused a runtime error.
{noformat}
Caused by: java.lang.IllegalAccessError: tried to access method
org.eclipse.aether.util.ChecksumUtils.toHexString([B)Ljava/lang/String; from
class org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum
at org.eclipse.aether.connector.basic.ChecksumCalculator$Checksum.get
(ChecksumCalculator.java:100)
at org.eclipse.aether.connector.basic.ChecksumCalculator.get
(ChecksumCalculator.java:213)
at
org.eclipse.aether.connector.basic.TransferTransportListener.getChecksums
(TransferTransportListener.java:134)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:460)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:364)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run
(RunnableErrorForwarder.java:67)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:644)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:499)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:401)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:229)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:207)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:240)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:171)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
(DefaultDependencyCollector.java:541)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
(DefaultDependencyCollector.java:524)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:412)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
(DefaultDependencyCollector.java:509)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:461)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:365)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:352)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
[jira] [Commented] (MRESOLVER-93) StackOverflowError by PathRecordingDependencyVisitor
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920791#comment-16920791
]
Tomo Suzuki commented on MRESOLVER-93:
--
[~tibordigana] How about "StackOverflowError by PathRecordingDependencyVisitor"?
> StackOverflowError by PathRecordingDependencyVisitor
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the
[jira] [Updated] (MRESOLVER-93) StackOverflowError by PathRecordingDependencyVisitor
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Summary: StackOverflowError by PathRecordingDependencyVisitor (was:
PathRecordingDependencyVisitor to handle 3 cycles)
> StackOverflowError by PathRecordingDependencyVisitor
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed.
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Solutions
I came up with three solutions. I pick solution #1 for simplicity.
h2. 1. Use "parents" to check the cycle, rather than visited set
This is the simplest. Checking array element member is usually discouraged
especially for large data set. The implementation should confirm the overhead
of this solution.
h2. 2. Use AbstractMapBag/Multiset for visited set
Creating a new class that extends AbstractMapBag and leverages IdentityHashMap.
Although this solution would be theoretically more efficient than solution #1,
I felt it's overkill to create a class just for this solution.
{code:java}
AbstractMapBag(new IdentityHashMap()){code}
[https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
IdentityHashMap() would work as a multiset.
h2. 3. Call visitLeave only when visitEnter is true
The cause of this bug is
[DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
calling visitLeave regardless of visitEnter result.
I'm not sure how many other visitors rely on visitLeave being called regardless
of visitEnter result.
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Affects Version/s: 1.3.3
1.4.0
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
>
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the algorithm calls visitLeave(b0). This
> removes "b0" from visited set.
> !IMG_0238.jpg|width=459,height=197!
> Now visited set is empty.
> Next child of the
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Solutions
I came up with three solutions. I pick solution #1 for simplicity.
h2. 1. Use "parents" to check the cycle, rather than visited set
This is the simplest. Checking array element member is usually discouraged
especially for large data set. The implementation should confirm the overhead
of this solution.
h2. 2. Use AbstractMapBag for visited set
Creating a new class that extends AbstractMapBag and leverages IdentityHashMap.
Although this solution would be theoretically more efficient than solution #1,
I felt it's overkill to create a class just for this solution.
{code:java}
AbstractMapBag(new IdentityHashMap()){code}
[https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
h2. 3. Call visitLeave only when visitEnter is true
The cause of this bug is
[DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
calling visitLeave regardless of visitEnter result.
I'm not sure how many other visitors rely on visitLeave being called regardless
of visitEnter result.
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes. I concluded the visited set is not working as expected to
avoid cycle.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visited set. An internal data structure in PathRecordingDependencyVisitor to
avoid cycle
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
* visitEnter(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
When returning true, the node's children is traversed by the algorithm. This
function adds the node to visited set.
* visitLeave(node): PathRecordingDependencyVisitor's function
([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
This function removes the node from visited set.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration is the node traversal for the test case above by
current algorithm. This illustration tracks the dependency node graph and the
"visited" set maintained by the visitor.
* visitEnter: a function
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
h1. Illustration on why existing algorithm does not catch cycle
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true, meaning that the algorithm traverses this b0's children next. B0
is added to visited.
!IMG_0235.jpg|width=359,height=191!
B0's children is "a". Because visited set contains "a", visitEnter(a) returns
false. This means that the algorithm does not traverse this "a"'s children. A
is added to visited set (already it has).
!IMG_0236.jpg|width=438,height=197!
Now not traversing this "a"'s children, the algorithm calls visitLeave(a). This
removes "a" from visited set.
!IMG_0237.jpg|width=434,height=165!
B0's children are all traversed. the algorithm calls visitLeave(b0). This
removes "b0" from visited set.
!IMG_0238.jpg|width=459,height=197!
Now visited set is empty.
Next child of the root "a" is b1. B1 is not in visited set, thus visitEnter(b1)
returns true. This means the algorithm traverses the children of this b1.
!IMG_0240.jpg|width=445,height=270!
B1's only child is a. "a" is not in visited set. visitEnter(a) returns true.
This means to traverse "a"'s children.
!IMG_0241.jpg|width=418,height=262!
A's first children is b0. b0 is not in visited set. visitEnter(b0) returns
true, meaning to traverse children of this b0.
!IMG_0242.jpg|width=422,height=208!
(img 0242)
The only child of b0 is "a". Visited set contains "a", and thus not traversing
its children.
!IMG_0243.jpg|width=491,height=191!
visitLeave(a) removes "a" from visited set.
!IMG_0244.jpg|width=481,height=189!
b0's children is all traversed. VisitLeave(b0) removes b0 from visited set.
!IMG_0245.jpg|width=498,height=182!
Next child of this "a" is b1. B1 is in visited set, and thus visitEnter(b1)
returns false. This node's children is not to be traversed.
!IMG_0255.jpg|width=545,height=245!
(img 0255)
visitLeave(b1) removes b1 from visited set. Now visited is emtpy.
!IMG_0256.jpg|width=528,height=294!
The last child of "a" is b2. VisitEnter(b2) returns true. It's children is to
be traversed. B2 is in visited set.
!IMG_0257.jpg|width=502,height=309!
B2's only child is "a". "a" is not in visited set, thus visitEnter(a) returns
true. The algorithm traverses this "a"'s children.
!IMG_0258.jpg|width=485,height=299!
(img 0258)
(...omit...)
IMG_0266 shows the step where I decided to give up. The algorithm does not seem
to stop. Indeed the test shows that. The path from the root to the furthest a
includes 5 "a" nodes.
!IMG_0266.jpg|width=656,height=252!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true. B0 is added to visited.
!IMG_0235.jpg|width=359,height=191!
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg,
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
First child of a is b0. Because visited does not contain, visitEnter(b0)
returns true. B0 is added to visited.
!IMG_0235.jpg|width=359,height=191!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
!IMG_0235.jpg!
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> Diagnosis with
>
> The following illustration tracks the node traversal for the test case above.
> The illustration tracks the dependency node graph and the "visited" set
> maintained by the visitor.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true. B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code:java}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
Diagnosis with
The following illustration tracks the node traversal for the test case above.
The illustration tracks the dependency node graph and the "visited" set
maintained by the visitor.
The initial state starts with node "a" and visited set \{a}.
!IMG_0234.jpg|width=334,height=252!
!IMG_0235.jpg!
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> Diagnosis with
>
> The following illustration tracks the node traversal for the test case above.
> The illustration tracks the dependency node graph and the "visited" set
> maintained by the visitor.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> !IMG_0235.jpg!
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Attachment: IMG_0266.jpg
IMG_0265.jpg
IMG_0264.jpg
IMG_0263.jpg
IMG_0262.jpg
IMG_0261.jpg
IMG_0260.jpg
IMG_0259.jpg
IMG_0258.jpg
IMG_0257.jpg
IMG_0256.jpg
IMG_0255.jpg
IMG_0245.jpg
IMG_0244.jpg
IMG_0243.jpg
IMG_0242.jpg
IMG_0241.jpg
IMG_0240.jpg
IMG_0238.jpg
IMG_0237.jpg
IMG_0236.jpg
IMG_0235.jpg
IMG_0234.jpg
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Description:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError. [Test
case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
was:
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError.
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
Tomo Suzuki created MRESOLVER-93:
Summary: PathRecordingDependencyVisitor to handle 3 cycles
Key: MRESOLVER-93
URL: https://issues.apache.org/jira/browse/MRESOLVER-93
Project: Maven Resolver
Issue Type: Improvement
Components: resolver
Affects Versions: 1.4.1
Reporter: Tomo Suzuki
PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
more cycles such as below:
{code}
gid:a:1 (1)
+- gid:b:0
| \- ^1
+- gid:b:1
| \- ^1
\- gid:b:2
\- ^1
{code}
It fails with StackOverflowError or OutOfMemoryError.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6737) StackOverflowError when version ranges are unsolvable and graph contains a cycle
[
https://issues.apache.org/jira/browse/MNG-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910732#comment-16910732
]
Tomo Suzuki commented on MNG-6737:
--
I was able to create a test case in PathRecordingDependencyVisitorTest
[https://github.com/apache/maven-resolver/commit/3e6eb7842727d6af28af27e79f82cb1ed1808031]
> StackOverflowError when version ranges are unsolvable and graph contains a
> cycle
>
>
> Key: MNG-6737
> URL: https://issues.apache.org/jira/browse/MNG-6737
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Priority: Major
>
> Maven throws StackOverflowError when version ranges are unsolvable and the
> dependency graph contains a cycle.
> {code:java}
> $ mvn install
> ...
> [INFO] --< suztomo:module-c
> >--
> [INFO] Building module-c 1.0
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.406 s
> [INFO] Finished at: 2019-08-16T12:10:30-04:00
> [INFO]
>
> ...
> Exception in thread "main" java.lang.StackOverflowError
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> ...(omitting many lines)...
> {code}
> h1. Example
> Example project to reproduce the issue:
> [https://github.com/suztomo/maven-cyclic-dependency-with-range]
> h1. Diagnosis
> In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
> 1.16.1),
> [org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
> tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
> the exception PathRecordingDependencyVisitor visits nodes in the dependency
> graph and the graph contains a cycle. The visitor goes to infinite recursion
> in visiting the cyclic path, resulting in StackOverflowError.
>
> {code:java}
> private UnsolvableVersionConflictException newFailure( final ConflictContext
> context )
> {
> ...
> PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
> filter );
> context.getRoot().accept( visitor );
> return new UnsolvableVersionConflictException( visitor.getPaths() );
> }{code}
>
> The cycle in the graph consists of module-a and module-b as illustrated below:
> {code:java}
> module-c:1.0.0
> +- module-b:2.0.0
> +- module-a:1.0.0
> +- module-b:0.0.1
> +- module-b:1.0.0
> | +- module-a:1.0.0
> | +- module-b:0.0.1
> | +- module-b:1.0.0
>...{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MNG-6732:
-
Description:
h1. Problem
Sometimes my Maven enforcer rule does not receive resolved artifact list
because of missing artifact even when the missing artifact does not appear in
the final dependency graph.
h1. Background
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
My enforcer rule can retrieve artifact list through
DefaultProjectDependenciesResolver.resolve when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
The missing artifact does not appear in final dependency graph.
On the other hand, the enforcer rule fails to retrieve artifact list when
applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing xerces:xerces-impl:2.6.2, even though the artifact
should not appear in the final dependency graph.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently DefaultArtifactDescriptorReader.loadPom method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies
to obtain partially resolved artifact list even when there is a missing
artifact (such as xerces:xerces-impl:2.6.2)
However, when there is a retired Maven repository is involved (such as
[http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom
method gets an ArtifactTransferException and throws ArtifactDescriptorException
without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy (excerpt
below), and thus DefaultProjectDependenciesResolver.resolve does not return
partially resolved artifact list.
{code:java}
catch ( ArtifactResolutionException e )
{
if ( e.getCause() instanceof ArtifactNotFoundException )
{
missingDescriptor( session, trace, a, (Exception)
e.getCause() );
if ( ( getPolicy( session, a, request ) &
ArtifactDescriptorPolicy.IGNORE_MISSING ) != 0 )
{
return null;
}
}
result.addException( e );
throw new ArtifactDescriptorException( result );
}
{code}
from
[DefaultArtifactDescriptorReader.java|https://github.com/apache/maven/blob/d3ace78/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L255]
ArtifactNotFoundException is a special case of
[ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
h1. Example Project
Example project to demonstrate the diagnosis:
[https://github.com/suztomo/maven-missing-artifact] . In this example, even
though module-b and module-c have the same dependency section, module-c fails
to run Maven because of a repository section containing a retired repository
URL.
was:
h1. Problem
Sometimes my Maven enforcer rule does not receive resolved artifact list
because of missing artifact even when the missing artifact does not appear in
the final dependency graph.
h1. Background
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
My enforcer rule can retrieve artifact list through
DefaultProjectDependenciesResolver.resolve when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
The missing artifact does not appear in final dependency graph.
On the other hand, the enforcer rule fails to retrieve artifact list when
applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing xerces:xerces-impl:2.6.2, even though the artifact
should not appear in the final dependency graph.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently DefaultArtifactDescriptorReader.loadPom method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies
to obtain partially resolved artifact list even when there is a missing
artifact (such as xerces:xerces-impl:2.6.2)
However, when there is a retired Maven repository is involved (such as
[http://repository.codehaus.org/] ),
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[
https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MNG-6732:
-
Description:
h1. Problem
Sometimes my Maven enforcer rule does not receive resolved artifact list
because of missing artifact even when the missing artifact does not appear in
the final dependency graph.
h1. Background
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
My enforcer rule can retrieve artifact list through
DefaultProjectDependenciesResolver.resolve when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
The missing artifact does not appear in final dependency graph.
On the other hand, the enforcer rule fails to retrieve artifact list when
applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing xerces:xerces-impl:2.6.2, even though the artifact
should not appear in the final dependency graph.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently DefaultArtifactDescriptorReader.loadPom method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies
to obtain partially resolved artifact list even when there is a missing
artifact (such as xerces:xerces-impl:2.6.2)
However, when there is a retired Maven repository is involved (such as
[http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom
method gets an ArtifactTransferException and throws ArtifactDescriptorException
without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus
DefaultProjectDependenciesResolver.resolve does not return partially resolved
artifact list.
{code:java}
// Some comments here
public String getFoo()
{
return foo;
}
{code}
ArtifactNotFoundException is a special case of
[ArtifactTransferException|https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html].
Example project to demonstrate the diagnosis:
[https://github.com/suztomo/maven-missing-artifact] . Even though module-b and
module-c have the same dependency section, module-c fails to run Maven because
of repository section.
was:
h1. Problem
Sometimes my Maven enforcer rule does not receive resolved artifact list
because of missing artifact even when the missing artifact does not appear in
the final dependency graph.
h1. Background
Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central.
My enforcer rule can retrieve artifact list when applied to
[https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker]
project even though it outputs "[WARNING] The POM for
xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available".
On the other hand, the enforcer rule fails to retrieve artifact list when
applied to
[grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client]
because of the missing xerces:xerces-impl:2.6.2.
[https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834]
h1. Diagnosis
Currently DefaultArtifactDescriptorReader.loadPom method checks
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon
ArtifactNotFoundException. This allows
DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies
to obtain partially resolved artifact list even when there is a missing
artifact (such as xerces:xerces-impl:2.6.2)
However, when there is a retired Maven repository is involved (such as
[http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom
method throws ArtifactDescriptorException without checking
"ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus
DefaultProjectDependenciesResolver.resolve does not return partially resolved
artifact list.
Example project to demonstrate the diagnosis:
[https://github.com/suztomo/maven-missing-artifact] . Even though module-b and
module-c have the same dependency section, module-c fails to run Maven because
of repository section.
> DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon
> ArtifactTransferException
> -
>
> Key: MNG-6732
> URL: https://issues.apache.org/jira/browse/MNG-6732
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Priority: Major
>
[jira] [Commented] (MNG-6737) StackOverflowError when version ranges are unsolvable and graph contains a cycle
[
https://issues.apache.org/jira/browse/MNG-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910552#comment-16910552
]
Tomo Suzuki commented on MNG-6737:
--
My memo: PathRecordingDependencyVisitor has logic to prevent visiting nodes
that already visited. Why didn't this work?
[https://github.com/apache/maven-resolver/blob/47edcfe/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L121]
> StackOverflowError when version ranges are unsolvable and graph contains a
> cycle
>
>
> Key: MNG-6737
> URL: https://issues.apache.org/jira/browse/MNG-6737
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Tomo Suzuki
>Priority: Major
>
> Maven throws StackOverflowError when version ranges are unsolvable and the
> dependency graph contains a cycle.
> {code:java}
> $ mvn install
> ...
> [INFO] --< suztomo:module-c
> >--
> [INFO] Building module-c 1.0
> [INFO] [ jar
> ]-
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.406 s
> [INFO] Finished at: 2019-08-16T12:10:30-04:00
> [INFO]
>
> ...
> Exception in thread "main" java.lang.StackOverflowError
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
> ...(omitting many lines)...
> {code}
> h1. Example
> Example project to reproduce the issue:
> [https://github.com/suztomo/maven-cyclic-dependency-with-range]
> h1. Diagnosis
> In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
> 1.16.1),
> [org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
> tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
> the exception PathRecordingDependencyVisitor visits nodes in the dependency
> graph and the graph contains a cycle. The visitor goes to infinite recursion
> in visiting the cyclic path, resulting in StackOverflowError.
>
> {code:java}
> private UnsolvableVersionConflictException newFailure( final ConflictContext
> context )
> {
> ...
> PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
> filter );
> context.getRoot().accept( visitor );
> return new UnsolvableVersionConflictException( visitor.getPaths() );
> }{code}
>
> The cycle in the graph consists of module-a and module-b as illustrated below:
> {code:java}
> module-c:1.0.0
> +- module-b:2.0.0
> +- module-a:1.0.0
> +- module-b:0.0.1
> +- module-b:1.0.0
> | +- module-a:1.0.0
> | +- module-b:0.0.1
> | +- module-b:1.0.0
>...{code}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MNG-6737) StackOverflowError when version ranges are unsolvable unsolvable and graph contains a cycle
[
https://issues.apache.org/jira/browse/MNG-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MNG-6737:
-
Description:
Maven throws StackOverflowError when version ranges are unsolvable and the
dependency graph contains a cycle.
{code:java}
$ mvn install
...
[INFO] --< suztomo:module-c >--
[INFO] Building module-c 1.0
[INFO] [ jar ]-
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.406 s
[INFO] Finished at: 2019-08-16T12:10:30-04:00
[INFO]
...
Exception in thread "main" java.lang.StackOverflowError
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
...(omitting many lines)...
{code}
h1. Example
Example project to reproduce the issue:
[https://github.com/suztomo/maven-cyclic-dependency-with-range]
h1. Diagnosis
In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
1.16.1),
[org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
the exception PathRecordingDependencyVisitor visits nodes in the dependency
graph and the graph contains a cycle. The visitor goes to infinite recursion in
visiting the cyclic path, resulting in StackOverflowError.
{code:java}
private UnsolvableVersionConflictException newFailure( final ConflictContext
context )
{
...
PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
filter );
context.getRoot().accept( visitor );
return new UnsolvableVersionConflictException( visitor.getPaths() );
}{code}
The cycle in the graph consists of module-a and module-b as illustrated below:
{code:java}
module-c:1.0.0
+- module-b:2.0.0
+- module-a:1.0.0
+- module-b:0.0.1
+- module-b:1.0.0
| +- module-a:1.0.0
| +- module-b:0.0.1
| +- module-b:1.0.0
...{code}
was:
Maven throws StackOverflowError when version ranges are unsolvable and the
dependency graph contains a cycle.
{code:java}
[INFO] --< suztomo:module-c >--
[INFO] Building module-c 1.0
[INFO] [ jar ]-
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.406 s
[INFO] Finished at: 2019-08-16T12:10:30-04:00
[INFO]
...
Exception in thread "main" java.lang.StackOverflowError
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
...(omitting many lines)...
{code}
h1. Example
Example project to reproduce the issue:
[https://github.com/suztomo/maven-cyclic-dependency-with-range]
h1. Diagnosis
In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
1.16.1),
[org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
the exception PathRecordingDependencyVisitor visits nodes in the dependency
graph and the graph contains a cycle. The visitor goes to infinite recursion in
visiting the cyclic path, resulting in
[jira] [Updated] (MNG-6737) StackOverflowError when version ranges are unsolvable unsolvable and graph contains a cycle
[
https://issues.apache.org/jira/browse/MNG-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MNG-6737:
-
Description:
Maven throws StackOverflowError when version ranges are unsolvable and the
dependency graph contains a cycle.
{code:java}
[INFO] --< suztomo:module-c >--
[INFO] Building module-c 1.0
[INFO] [ jar ]-
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.406 s
[INFO] Finished at: 2019-08-16T12:10:30-04:00
[INFO]
...
Exception in thread "main" java.lang.StackOverflowError
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
...(omitting many lines)...
{code}
h1. Example
Example project to reproduce the issue:
[https://github.com/suztomo/maven-cyclic-dependency-with-range]
h1. Diagnosis
In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
1.16.1),
[org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
the exception PathRecordingDependencyVisitor visits nodes in the dependency
graph and the graph contains a cycle. The visitor goes to infinite recursion in
visiting the cyclic path, resulting in StackOverflowError.
{code:java}
private UnsolvableVersionConflictException newFailure( final ConflictContext
context )
{
...
PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
filter );
context.getRoot().accept( visitor );
return new UnsolvableVersionConflictException( visitor.getPaths() );
}{code}
The cycle in the graph consists of module-a and module-b as illustrated below:
{code:java}
module-c:1.0.0
+- module-b:2.0.0
+- module-a:1.0.0
+- module-b:0.0.1
+- module-b:1.0.0
| +- module-a:1.0.0
| +- module-b:0.0.1
| +- module-b:1.0.0
...{code}
was:
Maven throws StackOverflowError when version ranges are unsolvable and the
dependency graph contains a cycle.
{code:java}
[INFO] --< suztomo:module-c >--
[INFO] Building module-c 1.0
[INFO] [ jar ]-
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.406 s
[INFO] Finished at: 2019-08-16T12:10:30-04:00
[INFO]
...
Exception in thread "main" java.lang.StackOverflowError
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
...(omitting many lines)...
{code}
h1. Example
Example project to reproduce the issue:
[https://github.com/suztomo/maven-cyclic-dependency-with-range]
h1. Diagnosis
In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
1.16.1),
[org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
the exception PathRecordingDependencyVisitor visits nodes in the dependency
graph and the graph contains a cycle. The visitor goes to infinite recursion in
visiting the cyclic path, resulting in
[jira] [Created] (MNG-6737) StackOverflowError when version ranges are unsolvable unsolvable and graph contains a cycle
Tomo Suzuki created MNG-6737:
Summary: StackOverflowError when version ranges are unsolvable
unsolvable and graph contains a cycle
Key: MNG-6737
URL: https://issues.apache.org/jira/browse/MNG-6737
Project: Maven
Issue Type: Improvement
Affects Versions: 3.6.1
Reporter: Tomo Suzuki
Maven throws StackOverflowError when version ranges are unsolvable and the
dependency graph contains a cycle.
{code:java}
[INFO] --< suztomo:module-c >--
[INFO] Building module-c 1.0
[INFO] [ jar ]-
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.406 s
[INFO] Finished at: 2019-08-16T12:10:30-04:00
[INFO]
...
Exception in thread "main" java.lang.StackOverflowError
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:341)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:345)
...(omitting many lines)...
{code}
h1. Example
Example project to reproduce the issue:
[https://github.com/suztomo/maven-cyclic-dependency-with-range]
h1. Diagnosis
In the example above, because of a version conflict on grpc-core (1.21.0 v.s.
1.16.1),
[org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure|https://github.com/apache/maven-resolver/blob/maven-resolver-1.4.0/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/transformer/NearestVersionSelector.java#L158]
tries to throw UnsolvableVersionConflictExceptoin. However, before throwing
the exception PathRecordingDependencyVisitor visits nodes in the dependency
graph and the graph contains a cycle. The visitor goes to infinite recursion in
visiting the cyclic path, resulting in StackOverflowError.
private UnsolvableVersionConflictException newFailure( final ConflictContext
context )
{
...
PathRecordingDependencyVisitor visitor = new PathRecordingDependencyVisitor(
filter );
context.getRoot().accept( visitor );
return new UnsolvableVersionConflictException( visitor.getPaths() );
}
The cyclic path consists of module-a and module-b as illustrated below:
{code:java}
module-c:1.0.0
+- module-b:2.0.0
+- module-a:1.0.0
+- module-b:0.0.1
+- module-b:1.0.0
| +- module-a:1.0.0
| +- module-b:0.0.1
| +- module-b:1.0.0
...{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
[ https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated MNG-6732: - Summary: DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException (was: DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException) > DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon > ArtifactTransferException > - > > Key: MNG-6732 > URL: https://issues.apache.org/jira/browse/MNG-6732 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Tomo Suzuki >Priority: Major > Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > h1. Problem > Sometimes my Maven enforcer rule does not receive resolved artifact list > because of missing artifact even when the missing artifact does not appear in > the final dependency graph. > h1. Background > Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. > My enforcer rule can retrieve artifact list when applied to > [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] > project even though it outputs "[WARNING] The POM for > xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". > On the other hand, the enforcer rule fails to retrieve artifact list when > applied to > [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] > because of the missing xerces:xerces-impl:2.6.2. > > [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] > h1. Diagnosis > Currently DefaultArtifactDescriptorReader.loadPom method checks > "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon > ArtifactNotFoundException. This allows > DefaultProjectDependenciesResolver.resolve calls > repoSystem.resolveDependencies to obtain partially resolved artifact list > even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) > However, when there is a retired Maven repository is involved (such as > [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom > method throws ArtifactDescriptorException without checking > "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus > DefaultProjectDependenciesResolver.resolve does not return partially resolved > artifact list. > > Example project to demonstrate the diagnosis: > [https://github.com/suztomo/maven-missing-artifact] . Even though module-b > and module-c have the same dependency section, module-c fails to run Maven > because of repository section. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException
[ https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated MNG-6732: - Description: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the diagnosis: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c have the same dependency section, module-c fails to run Maven. was: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the diagnosis: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c there have the same dependency section, module-c fails to run Maven. > DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon > ArtifactTransferException > - > > Key: MNG-6732 > URL: https://issues.apache.org/jira/browse/MNG-6732 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Tomo Suzuki >Priority: Major > Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png > > > h1. Problem > Sometimes my Maven enforcer rule does not receive resolved artifact list > because of missing artifact even when the missing artifact does not appear in > the final dependency graph. > h1. Background > Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. > My enforcer rule can retrieve artifact list when applied to > [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] > project even though it outputs "[WARNING] The POM for >
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException
[ https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated MNG-6732: - Description: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the diagnosis: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c have the same dependency section, module-c fails to run Maven because of repository section. was: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the diagnosis: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c have the same dependency section, module-c fails to run Maven. > DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon > ArtifactTransferException > - > > Key: MNG-6732 > URL: https://issues.apache.org/jira/browse/MNG-6732 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Tomo Suzuki >Priority: Major > Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png > > > h1. Problem > Sometimes my Maven enforcer rule does not receive resolved artifact list > because of missing artifact even when the missing artifact does not appear in > the final dependency graph. > h1. Background > Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. > My enforcer rule can retrieve artifact list when applied to > [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] > project even though it outputs "[WARNING] The
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException
[ https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated MNG-6732: - Description: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the diagnosis: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c there have the same dependency section, module-c fails to run Maven. was: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the finding: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c there have the same dependency section, module-c fails to run Maven. > DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon > ArtifactTransferException > - > > Key: MNG-6732 > URL: https://issues.apache.org/jira/browse/MNG-6732 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Tomo Suzuki >Priority: Major > Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png > > > h1. Problem > Sometimes my Maven enforcer rule does not receive resolved artifact list > because of missing artifact even when the missing artifact does not appear in > the final dependency graph. > h1. Background > Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. > My enforcer rule can retrieve artifact list when applied to > [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] > project even though it outputs "[WARNING] The POM for >
[jira] [Updated] (MNG-6732) DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException
[ https://issues.apache.org/jira/browse/MNG-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated MNG-6732: - Description: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. Example project to demonstrate the finding: [https://github.com/suztomo/maven-missing-artifact] . Even though module-b and module-c there have the same dependency section, module-c fails to run Maven. was: h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. I will create example Maven projects to compare. > DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon > ArtifactTransferException > - > > Key: MNG-6732 > URL: https://issues.apache.org/jira/browse/MNG-6732 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.6.1 >Reporter: Tomo Suzuki >Priority: Major > Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png > > > h1. Problem > Sometimes my Maven enforcer rule does not receive resolved artifact list > because of missing artifact even when the missing artifact does not appear in > the final dependency graph. > h1. Background > Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. > My enforcer rule can retrieve artifact list when applied to > [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] > project even though it outputs "[WARNING] The POM for > xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". > On the other hand, the enforcer rule fails to retrieve artifact list when >
[jira] [Created] (MNG-6732) DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException
Tomo Suzuki created MNG-6732: Summary: DefaultArtifactDescriptorReader to check IGNORE_MISSING policy upon ArtifactTransferException Key: MNG-6732 URL: https://issues.apache.org/jira/browse/MNG-6732 Project: Maven Issue Type: Improvement Components: core Affects Versions: 3.6.1 Reporter: Tomo Suzuki Attachments: 62884438-89260580-bd04-11e9-8c4a-897d4b736dc7.png h1. Problem Sometimes my Maven enforcer rule does not receive resolved artifact list because of missing artifact even when the missing artifact does not appear in the final dependency graph. h1. h1. Background Artifact xerces:xerces-impl:2.6.2 is not published in Maven Central. My enforcer rule can retrieve artifact list when applied to [https://github.com/suztomo/spring-cloud-gcp/tree/v1.1.2-linkage-checker] project even though it outputs "[WARNING] The POM for xerces:xerces-impl:jar:2.6.2 is missing, no dependency information available". On the other hand, the enforcer rule fails to retrieve artifact list when applied to [grpc-java-by-example/chat-example/chat-vaadin-client|https://github.com/saturnism/grpc-java-by-example/tree/master/chat-example/chat-vaadin-client] because of the missing xerces:xerces-impl:2.6.2. [https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/834] h1. Diagnosis Currently DefaultArtifactDescriptorReader.loadPom method checks "ArtifactDescriptorPolicy.IGNORE_MISSING" policy upon ArtifactNotFoundException. This allows DefaultProjectDependenciesResolver.resolve calls repoSystem.resolveDependencies to obtain partially resolved artifact list even when there is a missing artifact (such as xerces:xerces-impl:2.6.2) However, when there is a retired Maven repository is involved (such as [http://repository.codehaus.org/] ), DefaultArtifactDescriptorReader.loadPom method throws ArtifactDescriptorException without checking "ArtifactDescriptorPolicy.IGNORE_MISSING" policy, and thus DefaultProjectDependenciesResolver.resolve does not return partially resolved artifact list. I will create example Maven projects to compare. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824520#comment-16824520
]
Tomo Suzuki edited comment on MNG-6357 at 4/23/19 8:58 PM:
---
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | +- suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | +- suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
was (Author: suztomo):
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | - suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | - suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824520#comment-16824520
]
Tomo Suzuki edited comment on MNG-6357 at 4/23/19 8:58 PM:
---
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | - suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | - suztomo:artifact5}}
{{ +- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
was (Author: suztomo):
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | - suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | - suztomo:artifact5}}
{{ \- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[
https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824520#comment-16824520
]
Tomo Suzuki commented on MNG-6357:
--
I encountered this issue today. I had an assumption that Maven exec plugin
builds a class path in "nearest first" manner, but it actually treats it in
"depth first" manner.
Code to reproduce: [https://github.com/suztomo/triangle-linkage-error] .
Given this tree of transitive dependencies Artifact 1 - 5.
{{ suztomo:main:jar:0.0.1-SNAPSHOT}}
{{ +- suztomo:artifact1}}
{{ | - suztomo:artifact4}}
{{ +- suztomo:artifact2}}
{{ | - suztomo:artifact5}}
{{ \- suztomo:artifact3}}
I expected Maven exec plugin to build a class path of "artifact1, artifact2,
artifact3, artifact4, artifact5". However it builds a class path of "artifact1,
artifact*4*, artifact2, artifact*5*, artifact3".
In Github discussion [https://github.com/mojohaus/exec-maven-plugin/issues/91],
rfscholte wrote
_>Hervé confirmed that the "nearest wins" is only about version selection and
not about dependency order. This order is simply done by tree-walking. However,
we agreed that it would make sense to compile based on the direct dependencies
first, followed by first level, second level, etc._
Thank you. I also think that's intuitive behavior, in line with Maven's
dependency mediation algorithm.
> Dependency order should be nearest first
> -
>
> Key: MNG-6357
> URL: https://issues.apache.org/jira/browse/MNG-6357
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>
> In case of version conflicts, the nearest wins. However, the dependency order
> is simply based on tree walking. In the rare that a transitive dependency of
> the first direct dependency contains the same class as a latter direct
> dependency, the code is compiled against the first one, which is odd.
> It would make more sense if direct dependencies are the first ones on the
> classpath, followed by the first level transitive dependencies, etc. This
> will make the explanation equal to version conflict resolution: nearest wins.
> I don't expect real issues due to this change, otherwise we would have had
> this issue much earlier. This should become the new default order, however
> there should be a system property to get the original order, just in case
> somebody needs it.
>
> Current workaround: make the critical dependency the first direct dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-331) Maven-enforcer-plugin's use of aether-util in transitive dependency
Tomo Suzuki created MENFORCER-331: - Summary: Maven-enforcer-plugin's use of aether-util in transitive dependency Key: MENFORCER-331 URL: https://issues.apache.org/jira/browse/MENFORCER-331 Project: Maven Enforcer Plugin Issue Type: Dependency upgrade Components: Standard Rules Reporter: Tomo Suzuki Hi Maven developers, (following "Contributing" section of [maven-enforcer-plugin|https://github.com/apache/maven-enforcer#contributing]) I'm thinking to raise a PR to fix an issue below, so that maven-enforcer-plugin can work with maven-resolver-util without explicit "exclusion" element. Let me know what you think! While writing a custom enforcer rule, I encountered NoSuchMethodError org.eclipse.aether.util.ConfigUtils.getFloat. I believe it is caused by transitive dependency in org.eclipse.aether:aether-util. The class is also in org.apache.maven.resolver:maven-resolver-util:1.3.1. [A workaround with exclusion element|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/enforcer-rules/pom.xml#L64] just worked fine for me but I'd like to contribute to fix the root cause if possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
