[jira] [Commented] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520260#comment-17520260 ] wei cai commented on MRESOLVER-133: --- [~michael-o] It already gets all versions from metadata.xml as defined in chronological order when creating the VersionRangeRequest, the most obsolete one comes the first. And the patch in above PR just reverse the list _*(Collections.reverse( versions ))*_ so the latest deployed will come first (could be 2.9.x or 3.1.x depends on the deploy timestamp). > Improve resolver performance by using breadth-first search > -- > > Key: MRESOLVER-133 > URL: https://issues.apache.org/jira/browse/MRESOLVER-133 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.4.2 >Reporter: Gregory Ducharme >Priority: Major > Attachments: mvnbaddeps.zip > > > > I believe the maven resolver is unnecessarily inefficient because it performs > a depth-first search of components to resolve dependencies. Consider the case > when dependencies use version ranges, the user intent is for maven to resolve > with the highest versions of dependencies that satisfy all constraints. If > maven were to use a breadth-first search (and terminate searching as soon as > a solution is found) then in many cases a valid set of dependencies can be > resolved (at the top of the version ranges) without requiring that all > historical versions are resolvable. One should get the same answer with both > depth-first and breadth first strategies, but with the breadth-first approach > not being vulnerable to a missing parent POM somewhere in history making it > impossible to build the head of code. Additionally, I suspect that > breadth-first would be faster and use less memory than depth first. > > Additionally the depth-first approach has a weakness that when ny version of > a parent pom of a component referenced in a dependency tree of another > component is missing maven fails to resolve dependencies. One get a message > of the form: > Failed to execute goal on project module: Could not resolve dependencies for > project baddepdemo.project2:module:jar:1: Failed to collect dependencies ... > > Currently the only way to resolve this issue is one of three ways: > 1) restore a missing parent POM into the repository history, or > 2) delete all modules associated with the missing parent POM from the > repository > 3) manually adjust version ranges in consumer dependencies to exclude the > bad versions of dependencies that refer to the missing parent POM. > > What I would like is a configuration switch that would allow one to select > between the two search strategies So that the manual interventions described > above are not required. > > I have include a zip file that include the minimal projects needed to > demonstrate the dependency resolution problem: > project 1 has a module and parent pom. > project 2 is a single pom that has a dependency on the module in project 1. > Project 2 uses a dependency range [1,) that indicates that the latest version > of project1's module is to be used. > If one builds two versions (1 and 2) of project 1, project2 will resolve to > use version 2 as expected. However if you delete the parent pom of project1 > from the repository maven cannot resolve dependencies and fails. If the > version range in project 2 is changed to [2,) then the expected behavior is > observed. > The zip file contains a shell script (demo.sh) that can be run without > parameters to demonstrate the behavior when all versions are present in the > repository. Run it with 1 as a parameter (the lower end of the version range > used in project2) and the script will delete the parent pom from project 1 > and the error condition will be demonstrated. Run it with 2 and maven will > resolve dependencies as version1 of project1 is explicitly excluded from the > dependency resolution process. > > I am also willing to look at the source and propose a patch, but I would need > guidance on which modules/source I should look at. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Pearce updated SUREFIRE-2068:
Description:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with `./mvnw -Pjunit5 test` or `./mvnw -Pjunit4 test` both produce
the same output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
was:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with `./mvnw -Pjunit5 test` or ./mvnw -Pjunit4 test both produce the
same output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with `./mvnw -Pjunit5 test` or `./mvnw -Pjunit4 test` both produce
> the same output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at
[jira] [Updated] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Pearce updated SUREFIRE-2068:
Description:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with `./mvnw -Pjunit5 test` or ./mvnw -Pjunit4 test both produce the
same output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
was:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with ./mvnw -Pjunit5 test or ./mvnw -Pjunit4 test both produce the
same output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with `./mvnw -Pjunit5 test` or ./mvnw -Pjunit4 test both produce
> the same output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at
[jira] [Updated] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Pearce updated SUREFIRE-2068:
Description:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with ./mvnw -Pjunit5 test or ./mvnw -Pjunit4 test both produce the
same output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
was:
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with ./mvnw -Pjunit5 or ./mvnw -Pjunit4 test both produce the same
output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with ./mvnw -Pjunit5 test or ./mvnw -Pjunit4 test both produce the
> same output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at
[jira] [Updated] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Pearce updated SUREFIRE-2068:
Attachment: surefire-buffer-overflow.zip
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with ./mvnw -Pjunit5 or ./mvnw -Pjunit4 test both produce the same
> output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
> at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2068) System.out.println() causes BufferOverflow
[
https://issues.apache.org/jira/browse/SUREFIRE-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Pearce updated SUREFIRE-2068:
Attachment: (was: Archive.zip)
> System.out.println() causes BufferOverflow
> --
>
> Key: SUREFIRE-2068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Steven Pearce
>Priority: Minor
> Attachments: surefire-buffer-overflow.zip
>
>
> Using the SUREFIRE-1614 minimal project as a starting point I've added the
> line
> {noformat}
> System.out.println();
> {noformat}
> at line 16 of CustomRunner.class
> I've also updated the dependancies, but it mostly remains the same.
> I've attached the reproducible example
> Executing with ./mvnw -Pjunit5 or ./mvnw -Pjunit4 test both produce the same
> output.
> Downgrading to 3.0.0-M5 no longer causes the issue.
> This will now trigger the exception
> {noformat}
> java.nio.BufferOverflowException
> at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
> at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
> at
> org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
> at
> org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
> at
> org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
> at
> org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
> at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2068) System.out.println() causes BufferOverflow
Steven Pearce created SUREFIRE-2068:
---
Summary: System.out.println() causes BufferOverflow
Key: SUREFIRE-2068
URL: https://issues.apache.org/jira/browse/SUREFIRE-2068
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, JUnit 5.x support
Affects Versions: 3.0.0-M6
Reporter: Steven Pearce
Attachments: Archive.zip
Using the SUREFIRE-1614 minimal project as a starting point I've added the line
{noformat}
System.out.println();
{noformat}
at line 16 of CustomRunner.class
I've also updated the dependancies, but it mostly remains the same.
I've attached the reproducible example
Executing with ./mvnw -Pjunit5 or ./mvnw -Pjunit4 test both produce the same
output.
Downgrading to 3.0.0-M5 no longer causes the issue.
This will now trigger the exception
{noformat}
java.nio.BufferOverflowException
at java.base/java.nio.Buffer.nextPutIndex(Buffer.java:722)
at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:209)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeString(AbstractStreamEncoder.java:127)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encodeStringData(AbstractStreamEncoder.java:171)
at
org.apache.maven.surefire.api.stream.AbstractStreamEncoder.encode(AbstractStreamEncoder.java:157)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.encodeMessage(EventChannelEncoder.java:398)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.setOutErr(EventChannelEncoder.java:188)
at
org.apache.maven.surefire.booter.spi.EventChannelEncoder.testOutput(EventChannelEncoder.java:183)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:113)
at
org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:44)
at
org.apache.maven.surefire.junitplatform.RunListenerAdapter.writeTestOutput(RunListenerAdapter.java:379)
at
org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:144)
at com.example.demo.CustomRunner.createTestClass(CustomRunner.java:16)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slachiewicz commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
slachiewicz commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1094377026 @slawekjaranowski -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2067) Improve site configuration
[
https://issues.apache.org/jira/browse/SUREFIRE-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520223#comment-17520223
]
Slawomir Jaranowski commented on SUREFIRE-2067:
---
[~hboutemy] your opinion will be appreciated here
> Improve site configuration
> --
>
> Key: SUREFIRE-2067
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
> taken from parent.
> Currently we have old Maven logo on documentation site.
> We have also enabled {{topBar}} which is not enabled on other Maven project,
> so it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2067) Improve site configuration
Slawomir Jaranowski created SUREFIRE-2067:
-
Summary: Improve site configuration
Key: SUREFIRE-2067
URL: https://issues.apache.org/jira/browse/SUREFIRE-2067
Project: Maven Surefire
Issue Type: Improvement
Components: documentation
Reporter: Slawomir Jaranowski
Configuration like: {{bannerLeft}}, {{bannerRight}}, skin version should be
taken from parent.
Currently we have old Maven logo on documentation site.
We have also enabled {{topBar}} which is not enabled on other Maven project, so
it is some of inconsistent.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
Tibor17 commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1094347033 @sbabcoc @SykApps @slachiewicz Now the OOP looks better in the latest commit. WDYT? We can better concentrate on the details implemented in both methods. @slachiewicz This would help us when we would perform the removal of TestNG 5.x and we can much better merge the logic in a new objective design across the version 6.x and 7.x. Currently, some options, like `setJunit`, are lost and that's we did not controll Configuration in pull requests, we only accepted and that's the penalty. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520185#comment-17520185 ] Michael Osipov commented on MRESOLVER-133: -- The most important question: Is the versions array totally sorted? Consider you are maintaining 2.9.x and 3.0.x branches. The following releases have happened in chronological order: 2.9.1, 2.9.2, 3.0.0, 3.0.1, 2.9.3, 3.1.0, 3.0.2, 3.1.1, 2.9.4. > Improve resolver performance by using breadth-first search > -- > > Key: MRESOLVER-133 > URL: https://issues.apache.org/jira/browse/MRESOLVER-133 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.4.2 >Reporter: Gregory Ducharme >Priority: Major > Attachments: mvnbaddeps.zip > > > > I believe the maven resolver is unnecessarily inefficient because it performs > a depth-first search of components to resolve dependencies. Consider the case > when dependencies use version ranges, the user intent is for maven to resolve > with the highest versions of dependencies that satisfy all constraints. If > maven were to use a breadth-first search (and terminate searching as soon as > a solution is found) then in many cases a valid set of dependencies can be > resolved (at the top of the version ranges) without requiring that all > historical versions are resolvable. One should get the same answer with both > depth-first and breadth first strategies, but with the breadth-first approach > not being vulnerable to a missing parent POM somewhere in history making it > impossible to build the head of code. Additionally, I suspect that > breadth-first would be faster and use less memory than depth first. > > Additionally the depth-first approach has a weakness that when ny version of > a parent pom of a component referenced in a dependency tree of another > component is missing maven fails to resolve dependencies. One get a message > of the form: > Failed to execute goal on project module: Could not resolve dependencies for > project baddepdemo.project2:module:jar:1: Failed to collect dependencies ... > > Currently the only way to resolve this issue is one of three ways: > 1) restore a missing parent POM into the repository history, or > 2) delete all modules associated with the missing parent POM from the > repository > 3) manually adjust version ranges in consumer dependencies to exclude the > bad versions of dependencies that refer to the missing parent POM. > > What I would like is a configuration switch that would allow one to select > between the two search strategies So that the manual interventions described > above are not required. > > I have include a zip file that include the minimal projects needed to > demonstrate the dependency resolution problem: > project 1 has a module and parent pom. > project 2 is a single pom that has a dependency on the module in project 1. > Project 2 uses a dependency range [1,) that indicates that the latest version > of project1's module is to be used. > If one builds two versions (1 and 2) of project 1, project2 will resolve to > use version 2 as expected. However if you delete the parent pom of project1 > from the repository maven cannot resolve dependencies and fails. If the > version range in project 2 is changed to [2,) then the expected behavior is > observed. > The zip file contains a shell script (demo.sh) that can be run without > parameters to demonstrate the behavior when all versions are present in the > repository. Run it with 1 as a parameter (the lower end of the version range > used in project2) and the script will delete the parent pom from project 1 > and the error condition will be demonstrated. Run it with 2 and maven will > resolve dependencies as version1 of project1 is explicitly excluded from the > dependency resolution process. > > I am also willing to look at the source and propose a patch, but I would need > guidance on which modules/source I should look at. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (SUREFIRE-2066) Wrong documentation "List of System properties to pass to the JUnit tests." of systemProperties and systemPropertyVariables
[
https://issues.apache.org/jira/browse/SUREFIRE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2066.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=f6be3e648938414b222b50907b1db2d6a3cc977b
> Wrong documentation "List of System properties to pass to the JUnit tests."
> of systemProperties and systemPropertyVariables
> ---
>
> Key: SUREFIRE-2066
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2066
> Project: Maven Surefire
> Issue Type: Improvement
> Components: documentation
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M7
>
>
> The configuration parameters {{systemProperties}} and
> {{systemPropertyVariables}} have wrong JavaDoc:
> {noformat}
> List of System properties to pass to the JUnit tests.
> {noformat}
> The problem is with targeting "JUnit tests".
> Both parameters have general purpose.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-2066) Wrong documentation "List of System properties to pass to the JUnit tests." of systemProperties and systemPropertyVariables
Tibor Digana created SUREFIRE-2066:
--
Summary: Wrong documentation "List of System properties to pass to
the JUnit tests." of systemProperties and systemPropertyVariables
Key: SUREFIRE-2066
URL: https://issues.apache.org/jira/browse/SUREFIRE-2066
Project: Maven Surefire
Issue Type: Improvement
Components: documentation
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.0.0-M7
The configuration parameters {{systemProperties}} and
{{systemPropertyVariables}} have wrong JavaDoc:
{noformat}
List of System properties to pass to the JUnit tests.
{noformat}
The problem is with targeting "JUnit tests".
Both parameters have general purpose.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520153#comment-17520153
]
wei cai edited comment on MRESOLVER-133 at 4/10/22 11:18 AM:
-
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equivalent to
https://issues.apache.org/jira/browse/MNG-7049, right? We just need to fix the
unnecessary poms downloadings when comes to resolve a dependency with version
range?
The BFS + Skipper is in BFDependencyCollector, as you can see with below code,
it will do skip resolution of lower versions, however it does not help skip
pom/descriptor downloadings.
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498]
To fix the unnecessary pom/descriptor downloadings, let's check the code:
1. Maven downloads metadata.xml to figure out all available versions for the
version range
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384]
2. Download all poms/descriptors one by one
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394]
The issue is in #2. Maven just downloads all poms matching thee version range,
as Ivan pointed out in above threads, we can just reverse the version list and
then break if any of the version (newer version comes first) is resolved
successfully.
Fired initial PR for discussion:
[https://github.com/apache/maven-resolver/pull/163]
Added you access, feel free to edit the PR if you would like to modify.
Verified the patch by adding below dependency in my project and now only poms
of gson-parent and gson 2.9.0 are downloaded.
{code:java}
com.google.code.gson
gson
[0.0.1,3.0.0)
{code}
was (Author: wecai):
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equals to
https://issues.apache.org/jira/browse/MNG-7049, right? Just to fix the
unnecessary poms downloadings when comes to resolve a version range?
The BFS + Skipper is in BFDependencyCollector, as you can see with below code,
it will do skip resolution of lower versions, however it does not help skip
pom downloadings.
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498]
To fix the unnecessary pom downloadings, let's check the code:
# maven downloads metadata.xml to figure out all available versions for the
version range
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384]
# Download all poms one by one
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394]
The issue is in #2. Maven just downloads all poms matching thee version range,
as Ivan pointed out in above threads, we can just reverse the version list and
then break if a version is resolved successfully.
Fired initial PR:
[https://github.com/apache/maven-resolver/pull/163]
Feel free to edit the PR if you would like to modify.
Verified by adding below dependency in my project and only poms of gson parent
and gson 2.9.0 are downloaded.
{code:java}
com.google.code.gson
gson
[0.0.1,3.0.0)
{code}
> Improve resolver performance by using breadth-first search
> --
>
> Key: MRESOLVER-133
> URL: https://issues.apache.org/jira/browse/MRESOLVER-133
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.4.2
>Reporter: Gregory Ducharme
>Priority: Major
> Attachments: mvnbaddeps.zip
>
>
>
> I believe the maven resolver is unnecessarily inefficient because it performs
> a depth-first search of components to resolve dependencies. Consider the case
> when dependencies use version ranges, the user intent is for maven to resolve
> with the highest versions of dependencies that satisfy all constraints. If
> maven were to use a breadth-first search (and terminate searching as soon as
> a solution is found) then in many cases a valid set of dependencies can be
> resolved (at the top
[GitHub] [maven-resolver] caiwei-ebay commented on pull request #163: MRESOLVER-133 unnessary poms downloadings for dependency using versio…
caiwei-ebay commented on PR #163: URL: https://github.com/apache/maven-resolver/pull/163#issuecomment-1094248189 @michael-o @cstamas @ibabiankou @cannucklehead This is the draft PR for MRESOLVER-133. The idea is below as referenced from Ivan's comments in the ticket: > Below loop should iterate over reversed list of versions, it should only try to get artifact descriptor and break as soon as got one successfully. https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394 The same changes applied to original DF solution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[
https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520153#comment-17520153
]
wei cai edited comment on MRESOLVER-133 at 4/10/22 10:53 AM:
-
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equals to
https://issues.apache.org/jira/browse/MNG-7049, right? Just to fix the
unnecessary poms downloadings when comes to resolve a version range?
The BFS + Skipper is in BFDependencyCollector, as you can see with below code,
it will do skip resolution of lower versions, however it does not help skip
pom downloadings.
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498]
To fix the unnecessary pom downloadings, let's check the code:
# maven downloads metadata.xml to figure out all available versions for the
version range
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384]
# Download all poms one by one
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394]
The issue is in #2. Maven just downloads all poms matching thee version range,
as Ivan pointed out in above threads, we can just reverse the version list and
then break if a version is resolved successfully.
Fired initial PR:
[https://github.com/apache/maven-resolver/pull/163]
Feel free to edit the PR if you would like to modify.
Verified by adding below dependency in my project and only poms of gson parent
and gson 2.9.0 are downloaded.
{code:java}
com.google.code.gson
gson
[0.0.1,3.0.0)
{code}
was (Author: wecai):
[~michael-o] [~cannucklehead] [~ibabiankou]
I think this ticket is now equals to
https://issues.apache.org/jira/browse/MNG-7049, right? Just to fix the
unnecessary poms downloadings when comes to resolve a version range?
The BFS + Skipper is in BFDependencyCollector, as you can see below it will
do skip resolution of lower versions, however it does not help skip pom
downloadings.
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498]
To fix the unnecessary pom downloadings, let's check the code:
# maven downloads metadata.xml to figure out all available versions for the
version range
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384]
# Download all poms one by one
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394]
The issue is in #2. Maven just downloads all poms matching thee version range,
as Ivan pointed out in above threads, we can just reverse the version list and
then break if a version is resolved sucessfully.
Fired initial PR:
[https://github.com/apache/maven-resolver/pull/163]
Feel free to edit the PR if you would like to modify.
> Improve resolver performance by using breadth-first search
> --
>
> Key: MRESOLVER-133
> URL: https://issues.apache.org/jira/browse/MRESOLVER-133
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.4.2
>Reporter: Gregory Ducharme
>Priority: Major
> Attachments: mvnbaddeps.zip
>
>
>
> I believe the maven resolver is unnecessarily inefficient because it performs
> a depth-first search of components to resolve dependencies. Consider the case
> when dependencies use version ranges, the user intent is for maven to resolve
> with the highest versions of dependencies that satisfy all constraints. If
> maven were to use a breadth-first search (and terminate searching as soon as
> a solution is found) then in many cases a valid set of dependencies can be
> resolved (at the top of the version ranges) without requiring that all
> historical versions are resolvable. One should get the same answer with both
> depth-first and breadth first strategies, but with the breadth-first approach
> not being vulnerable to a missing parent POM somewhere in history making it
> impossible to build the head of code.
[jira] [Commented] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520153#comment-17520153 ] wei cai commented on MRESOLVER-133: --- [~michael-o] [~cannucklehead] [~ibabiankou] I think this ticket is now equals to https://issues.apache.org/jira/browse/MNG-7049, right? Just to fix the unnecessary poms downloadings when comes to resolve a version range? The BFS + Skipper is in BFDependencyCollector, as you can see below it will do skip resolution of lower versions, however it does not help skip pom downloadings. [https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L498] To fix the unnecessary pom downloadings, let's check the code: # maven downloads metadata.xml to figure out all available versions for the version range [https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L384] # Download all poms one by one [https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L404|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L394] The issue is in #2. Maven just downloads all poms matching thee version range, as Ivan pointed out in above threads, we can just reverse the version list and then break if a version is resolved sucessfully. Fired initial PR: [https://github.com/apache/maven-resolver/pull/163] Feel free to edit the PR if you would like to modify. > Improve resolver performance by using breadth-first search > -- > > Key: MRESOLVER-133 > URL: https://issues.apache.org/jira/browse/MRESOLVER-133 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.4.2 >Reporter: Gregory Ducharme >Priority: Major > Attachments: mvnbaddeps.zip > > > > I believe the maven resolver is unnecessarily inefficient because it performs > a depth-first search of components to resolve dependencies. Consider the case > when dependencies use version ranges, the user intent is for maven to resolve > with the highest versions of dependencies that satisfy all constraints. If > maven were to use a breadth-first search (and terminate searching as soon as > a solution is found) then in many cases a valid set of dependencies can be > resolved (at the top of the version ranges) without requiring that all > historical versions are resolvable. One should get the same answer with both > depth-first and breadth first strategies, but with the breadth-first approach > not being vulnerable to a missing parent POM somewhere in history making it > impossible to build the head of code. Additionally, I suspect that > breadth-first would be faster and use less memory than depth first. > > Additionally the depth-first approach has a weakness that when ny version of > a parent pom of a component referenced in a dependency tree of another > component is missing maven fails to resolve dependencies. One get a message > of the form: > Failed to execute goal on project module: Could not resolve dependencies for > project baddepdemo.project2:module:jar:1: Failed to collect dependencies ... > > Currently the only way to resolve this issue is one of three ways: > 1) restore a missing parent POM into the repository history, or > 2) delete all modules associated with the missing parent POM from the > repository > 3) manually adjust version ranges in consumer dependencies to exclude the > bad versions of dependencies that refer to the missing parent POM. > > What I would like is a configuration switch that would allow one to select > between the two search strategies So that the manual interventions described > above are not required. > > I have include a zip file that include the minimal projects needed to > demonstrate the dependency resolution problem: > project 1 has a module and parent pom. > project 2 is a single pom that has a dependency on the module in project 1. > Project 2 uses a dependency range [1,) that indicates that the latest version > of project1's module is to be used. > If one builds two versions (1 and 2) of project 1, project2 will resolve to > use version 2 as expected. However if you delete the parent pom of project1 > from the repository maven cannot resolve dependencies and fails. If the > version range in project 2 is changed to [2,) then the expected behavior is > observed. > The zip file contains a shell script (demo.sh) that can be run without > parameters to
[GitHub] [maven-resolver] caiwei-ebay opened a new pull request, #163: MRESOLVER-133 unnessary poms downloadings for dependency using versio…
caiwei-ebay opened a new pull request, #163: URL: https://github.com/apache/maven-resolver/pull/163 …n range -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520123#comment-17520123 ] Dan Tran edited comment on MNG-7433 at 4/10/22 8:58 AM: per my finding, i updated my mdev:sonar ( the one that spins another mvn, invoker style) to nonagregating mojo, and can see the build runs more steps further at the other module running in another thread until it steps on one of its aggregating mojo (such as buildnumber-m-p) and stuck. And just follow the same pattern to push more steps. This means I need to ensure no aggregating mojos ( my own internal company mojo, and the ones from outside company) was (Author: dantran): per my finding, i updated my mdev:sonar ( the one that spins another mvn, invoker style) to nonagregating mojo, and can see the build runs more steps further at the other module running in another thread until it steps one of its aggregating mojo (such as buildnumber-m-p) and stuck. And just follow the same pattern to push more steps. This means I need to ensure no aggregating mojos ( my own internal company mojo, and the ones from outside company) > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520123#comment-17520123 ] Dan Tran commented on MNG-7433: --- per my finding, i updated my mdev:sonar ( the one that spins another mvn, invoker style) to nonagregating mojo, and can see the build runs more steps further at the other module running in another thread until it steps one of its aggregating mojo (such as buildnumber-m-p) and stuck. And just follow the same pattern to push more steps. This means I need to ensure no aggregating mojos ( my own internal company mojo, and the ones from outside company) > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7049) Version range resolution downloads all poms, not just the highest version
[ https://issues.apache.org/jira/browse/MNG-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520122#comment-17520122 ] Michael Osipov commented on MNG-7049: - [~jhughes], since you want to verify that all versions have been downloaded to satisfy your request, I guess your IT needs to contain a file-based repository, the project itself and the verification code traverses the IT local repo for all POM from the metadata. WDYT? > Version range resolution downloads all poms, not just the highest version > - > > Key: MNG-7049 > URL: https://issues.apache.org/jira/browse/MNG-7049 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Moti Nisenson-Ken >Priority: Major > > When specifying a version range for a dependency, maven will download and try > to resolve all poms in that range which satisfy the range. The usage however > is only to use the highestVersion. This causes two issues: > # Performance - it's downloading numerous poms that aren't needed. > # Fragility - if the version range covers any "bad" poms, then the build > will fail. For example, consider that for a specific version, the parent of a > pom is not present in the repository. This is enough to fail any build with a > version range covering that specific version, as the range resolution stage > will not complete. This is particularly harmful when that version would not > be selected as the highest, anyway. > Recommend to have a system property to control the desired behavior - it > should be possible to short-circuit loading all the versions and to just to > load the highest version. > For another user report of this see: > [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOLVER-216) [ERROR] Malformed \uxxxx encoding.
[
https://issues.apache.org/jira/browse/MRESOLVER-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520120#comment-17520120
]
Michael Osipov commented on MRESOLVER-216:
--
[~flo...@usa.net], I recommend to try to reproduce either with Maven 3.9.x from
source, our follow my comment here:
https://issues.apache.org/jira/browse/MRESOLVER-216?focusedCommentId=17424958=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17424958
> [ERROR] Malformed \u encoding.
> --
>
> Key: MRESOLVER-216
> URL: https://issues.apache.org/jira/browse/MRESOLVER-216
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Lado Kumsiashvili
>Assignee: Michael Osipov
>Priority: Major
> Attachments: Screenshot 2021-12-26 at 14.44.41.png, Screenshot
> 2021-12-26 at 14.44.50.png, consoleText.txt
>
>
> We do still experience this "supposed to be fixed" Bug in maven resolver in
> our team. We use maven 3.8.2 and I guess it is packaged with 1.6.3 resolver.
> It occurs sometimes and never with
> {code:java}
> -Daether.metadataResolver.threads=1 {code}
>
> {code:java}
> Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f)
> Maven home: /usr/local/Cellar/maven/3.8.2/libexec
> Java version: 1.8.0_301, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" {code}
>
> This is how the maven run with
> {code:java}
> mvn -X install {code}
> fails
> {code:java}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 8.035 s
> [INFO] Finished at: 2021-10-06T10:04:20+02:00
> [INFO]
>
> [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:574)
> at java.util.Properties.load0 (Properties.java:391)
> at java.util.Properties.load (Properties.java:341)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
> org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at
> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion
> (DefaultVersionResolver.java:213)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
> (DefaultArtifactDescriptorReader.java:204)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
> (DefaultArtifactDescriptorReader.java:171)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
> (DefaultDependencyCollector.java:538)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
> (DefaultDependencyCollector.java:523)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:410)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:506)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:458)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
[jira] [Commented] (MRESOLVER-62) Resolver can skip cyclic dependencies underneath removed nodes
[
https://issues.apache.org/jira/browse/MRESOLVER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520118#comment-17520118
]
Michael Osipov commented on MRESOLVER-62:
-
[~wecai], thanks for the analysis. I wanted to evaluate this issue with your
work whether it covers it. Since your knowledge in graph theory is much better
than mine I'd like this to your judgement whether or not to provide a
patch/improvement.
> Resolver can skip cyclic dependencies underneath removed nodes
> --
>
> Key: MRESOLVER-62
> URL: https://issues.apache.org/jira/browse/MRESOLVER-62
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Toby Hammett
>Priority: Critical
> Labels: intern
> Attachments: maven-resolver-cycle-underneath-removed-node.patch
>
>
> While updating dependencies in one of my company's Maven projects, I got a
> StackOverflowError involving infinite recursion at
> {{org.apache.maven.RepositoryUtils#toArtifacts}}. After some investigation, I
> believe I have traced the issue to a bug in ConflictResolver which can occur
> when encountering multiple dependency cycles. Specifically, I think the
> criteria for failure are:
> * One cycle appears nearer to the root than the other cycle as a child of a
> node that will be removed.
> * That cycle is also a child of the other cycle elsewhere in the dependency
> graph.
> For example, here is a dependency graph analogous to the one I was working
> with when I encountered the StackOverflowError:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> +- gid:b:1
> | +- gid:c:1
> | \- gid:d:1 (d)
> |\- ^x
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> \- gid:p:2
> \- ^d
> {noformat}
> This graph has a cycle ({{x}} and {{y}}) underneath a node that is removed
> from the tree ({{a:1}}). This cycle also appears as a child of another cycle.
> Specifically, {{q}} and {{p}} depends on {{d}}, which depends on {{x}}.
> After conflicts are resolved in this graph, the node for {{gid:y:1}} still
> has a reference to {{gid:x:1}}, although I believe it should have been
> removed. This cycle in the graph led to the StackOverflowError I observed.
> Another example, derived from the first, shows a slightly different problem:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> |- gid:p:2
> \- ^x
> {noformat}
> In this case, as with the first, there is a cycle underneath a node that will
> be removed. That cycle ({{x}} and {{y}}) is also a dependency of node
> {{gid:q:2}}, which is itself a member of a cycle with {{p}}. When conflicts
> are resolved in this case, the resulting graph does not contain {{gid:x:1}}
> at all!
>
> A potential workaround for this issue is to declare a direct dependency on
> one of the artifacts in the cycle that is not handled correctly.
>
> I have attached a patch for maven-resolver-util which adds both of the
> preceding examples as unit tests. Please let me know if there's any other
> information I can provide.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520117#comment-17520117 ] Michael Osipov commented on MNG-7433: - But that doesn't sound wrong, no? > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-site] michael-o merged pull request #298: docs: add missing word on What Is Maven page
michael-o merged PR #298: URL: https://github.com/apache/maven-site/pull/298 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520115#comment-17520115 ] Tamás Cservenák edited comment on MNG-7433 at 4/10/22 8:19 AM: --- As far as I understand, it is not two Maven instances locking up, but Dan has an aggregator mojo that spawns a child process (another mvn process) and BLOCKS on it until child process done. But, as mojo doing this is an aggregator, it halts the whole build (until spawned child is done). was (Author: cstamas): As far as I understand, it is not two Maven instances locking up, but Dain has an aggregator mojo that spawns a child process (another mvn process) and BLOCKS on it until child process done. But, as mojo doing this is an aggregator, it halts the whole build (until spawned child is done). > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520115#comment-17520115 ] Tamás Cservenák edited comment on MNG-7433 at 4/10/22 8:19 AM: --- As far as I understand, it is not two Maven instances locking up, but Dain has an aggregator mojo that spawns a child process (another mvn process) and BLOCKS on it until child process done. But, as mojo doing this is an aggregator, it halts the whole build (until spawned child is done). was (Author: cstamas): As far as I understand, it is not to Maven instances locking up, but Dain has an aggregator mojo that spawns a child process (another mvn process) and BLOCKS on it until child process done. But, as mojo doing this is an aggregator, it halts the whole build (until spawned child is done). > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520115#comment-17520115 ] Tamás Cservenák commented on MNG-7433: -- As far as I understand, it is not to Maven instances locking up, but Dain has an aggregator mojo that spawns a child process (another mvn process) and BLOCKS on it until child process done. But, as mojo doing this is an aggregator, it halts the whole build (until spawned child is done). > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520114#comment-17520114 ] Michael Osipov commented on MRESOLVER-133: -- [~cannucklehead], yes. Install Resolver from master, package Maven 3.9.x from master with Resolver 1.8.0-SNAPSHOT and test. > Improve resolver performance by using breadth-first search > -- > > Key: MRESOLVER-133 > URL: https://issues.apache.org/jira/browse/MRESOLVER-133 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.4.2 >Reporter: Gregory Ducharme >Priority: Major > Attachments: mvnbaddeps.zip > > > > I believe the maven resolver is unnecessarily inefficient because it performs > a depth-first search of components to resolve dependencies. Consider the case > when dependencies use version ranges, the user intent is for maven to resolve > with the highest versions of dependencies that satisfy all constraints. If > maven were to use a breadth-first search (and terminate searching as soon as > a solution is found) then in many cases a valid set of dependencies can be > resolved (at the top of the version ranges) without requiring that all > historical versions are resolvable. One should get the same answer with both > depth-first and breadth first strategies, but with the breadth-first approach > not being vulnerable to a missing parent POM somewhere in history making it > impossible to build the head of code. Additionally, I suspect that > breadth-first would be faster and use less memory than depth first. > > Additionally the depth-first approach has a weakness that when ny version of > a parent pom of a component referenced in a dependency tree of another > component is missing maven fails to resolve dependencies. One get a message > of the form: > Failed to execute goal on project module: Could not resolve dependencies for > project baddepdemo.project2:module:jar:1: Failed to collect dependencies ... > > Currently the only way to resolve this issue is one of three ways: > 1) restore a missing parent POM into the repository history, or > 2) delete all modules associated with the missing parent POM from the > repository > 3) manually adjust version ranges in consumer dependencies to exclude the > bad versions of dependencies that refer to the missing parent POM. > > What I would like is a configuration switch that would allow one to select > between the two search strategies So that the manual interventions described > above are not required. > > I have include a zip file that include the minimal projects needed to > demonstrate the dependency resolution problem: > project 1 has a module and parent pom. > project 2 is a single pom that has a dependency on the module in project 1. > Project 2 uses a dependency range [1,) that indicates that the latest version > of project1's module is to be used. > If one builds two versions (1 and 2) of project 1, project2 will resolve to > use version 2 as expected. However if you delete the parent pom of project1 > from the repository maven cannot resolve dependencies and fails. If the > version range in project 2 is changed to [2,) then the expected behavior is > observed. > The zip file contains a shell script (demo.sh) that can be run without > parameters to demonstrate the behavior when all versions are present in the > repository. Run it with 1 as a parameter (the lower end of the version range > used in project2) and the script will delete the parent pom from project 1 > and the error condition will be demonstrated. Run it with 2 and maven will > resolve dependencies as version1 of project1 is explicitly excluded from the > dependency resolution process. > > I am also willing to look at the source and propose a patch, but I would need > guidance on which modules/source I should look at. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MRESOLVER-133) Improve resolver performance by using breadth-first search
[ https://issues.apache.org/jira/browse/MRESOLVER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520023#comment-17520023 ] Michael Osipov edited comment on MRESOLVER-133 at 4/10/22 8:17 AM: --- Is there a way for me to obtain the proposed resolver and test with my own use cases? was (Author: cannucklehead): Is there a way for me to obtain the proposed resolver and test with my own use cases? > Improve resolver performance by using breadth-first search > -- > > Key: MRESOLVER-133 > URL: https://issues.apache.org/jira/browse/MRESOLVER-133 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: 1.4.2 >Reporter: Gregory Ducharme >Priority: Major > Attachments: mvnbaddeps.zip > > > > I believe the maven resolver is unnecessarily inefficient because it performs > a depth-first search of components to resolve dependencies. Consider the case > when dependencies use version ranges, the user intent is for maven to resolve > with the highest versions of dependencies that satisfy all constraints. If > maven were to use a breadth-first search (and terminate searching as soon as > a solution is found) then in many cases a valid set of dependencies can be > resolved (at the top of the version ranges) without requiring that all > historical versions are resolvable. One should get the same answer with both > depth-first and breadth first strategies, but with the breadth-first approach > not being vulnerable to a missing parent POM somewhere in history making it > impossible to build the head of code. Additionally, I suspect that > breadth-first would be faster and use less memory than depth first. > > Additionally the depth-first approach has a weakness that when ny version of > a parent pom of a component referenced in a dependency tree of another > component is missing maven fails to resolve dependencies. One get a message > of the form: > Failed to execute goal on project module: Could not resolve dependencies for > project baddepdemo.project2:module:jar:1: Failed to collect dependencies ... > > Currently the only way to resolve this issue is one of three ways: > 1) restore a missing parent POM into the repository history, or > 2) delete all modules associated with the missing parent POM from the > repository > 3) manually adjust version ranges in consumer dependencies to exclude the > bad versions of dependencies that refer to the missing parent POM. > > What I would like is a configuration switch that would allow one to select > between the two search strategies So that the manual interventions described > above are not required. > > I have include a zip file that include the minimal projects needed to > demonstrate the dependency resolution problem: > project 1 has a module and parent pom. > project 2 is a single pom that has a dependency on the module in project 1. > Project 2 uses a dependency range [1,) that indicates that the latest version > of project1's module is to be used. > If one builds two versions (1 and 2) of project 1, project2 will resolve to > use version 2 as expected. However if you delete the parent pom of project1 > from the repository maven cannot resolve dependencies and fails. If the > version range in project 2 is changed to [2,) then the expected behavior is > observed. > The zip file contains a shell script (demo.sh) that can be run without > parameters to demonstrate the behavior when all versions are present in the > repository. Run it with 1 as a parameter (the lower end of the version range > used in project2) and the script will delete the parent pom from project 1 > and the error condition will be demonstrated. Run it with 2 and maven will > resolve dependencies as version1 of project1 is explicitly excluded from the > dependency resolution process. > > I am also willing to look at the source and propose a patch, but I would need > guidance on which modules/source I should look at. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOLVER-62) Resolver can skip cyclic dependencies underneath removed nodes
[
https://issues.apache.org/jira/browse/MRESOLVER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520113#comment-17520113
]
wei cai commented on MRESOLVER-62:
--
This issue should be resolved by the Skipper. Like below, the ^x dependent by
y:1 would be simply skipped as x:1 is already resolved before with a shallower
depth.
{noformat}
+- gid:a:1
| \- gid:x:1 (x)
| \- gid:y:1
|\- ^x{noformat}
However the tests did not pass though (applied the patch). This is because:
* In my ticket, we use skipper to resolve the least tree (with conflicts
skipped) and then delegate to ConflictResolver to resolve conflicts. This means
Skipper handles most of the conflicts (except the scope conflicts among
duplicate nodes) in advance for ConflictResolver.
* For this ticket, it is expecting a fix in ConflictResolver. And the tests
provided in this ticket is testing NearestVersionSelector which is part of
ConflictResolver.
[~michael-o]
This might be still an issue in ConflictResolver, If skipper is proved to be
helpful for the issue in this post, then we can say skipper may workaround such
issues however the fault/bug might be still there in ConflictResolver.
May I know your concern? If you need my help to prove Skipper can fix issue in
this post, then I can modify the tests patch provided in this post.
> Resolver can skip cyclic dependencies underneath removed nodes
> --
>
> Key: MRESOLVER-62
> URL: https://issues.apache.org/jira/browse/MRESOLVER-62
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Toby Hammett
>Priority: Critical
> Labels: intern
> Attachments: maven-resolver-cycle-underneath-removed-node.patch
>
>
> While updating dependencies in one of my company's Maven projects, I got a
> StackOverflowError involving infinite recursion at
> {{org.apache.maven.RepositoryUtils#toArtifacts}}. After some investigation, I
> believe I have traced the issue to a bug in ConflictResolver which can occur
> when encountering multiple dependency cycles. Specifically, I think the
> criteria for failure are:
> * One cycle appears nearer to the root than the other cycle as a child of a
> node that will be removed.
> * That cycle is also a child of the other cycle elsewhere in the dependency
> graph.
> For example, here is a dependency graph analogous to the one I was working
> with when I encountered the StackOverflowError:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> +- gid:b:1
> | +- gid:c:1
> | \- gid:d:1 (d)
> |\- ^x
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> \- gid:p:2
> \- ^d
> {noformat}
> This graph has a cycle ({{x}} and {{y}}) underneath a node that is removed
> from the tree ({{a:1}}). This cycle also appears as a child of another cycle.
> Specifically, {{q}} and {{p}} depends on {{d}}, which depends on {{x}}.
> After conflicts are resolved in this graph, the node for {{gid:y:1}} still
> has a reference to {{gid:x:1}}, although I believe it should have been
> removed. This cycle in the graph led to the StackOverflowError I observed.
> Another example, derived from the first, shows a slightly different problem:
> {noformat}
> (null)
> +- gid:a:1
> | \- gid:x:1 (x)
> | \- gid:y:1
> |\- ^x
> +- gid:a:2
> \- gid:m:1
>\- gid:n:1
> +- gid:p:1
> | \- gid:q:1
> \- gid:q:2
> |- gid:p:2
> \- ^x
> {noformat}
> In this case, as with the first, there is a cycle underneath a node that will
> be removed. That cycle ({{x}} and {{y}}) is also a dependency of node
> {{gid:q:2}}, which is itself a member of a cycle with {{p}}. When conflicts
> are resolved in this case, the resulting graph does not contain {{gid:x:1}}
> at all!
>
> A potential workaround for this issue is to declare a direct dependency on
> one of the artifacts in the cycle that is not handled correctly.
>
> I have attached a patch for maven-resolver-util which adds both of the
> preceding examples as unit tests. Please let me know if there's any other
> information I can provide.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7449:
Fix Version/s: wontfix-candidate
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
>
[jira] (MSKINS-174) Render breadcrumbs div conditionally
[ https://issues.apache.org/jira/browse/MSKINS-174 ] Michael Osipov deleted comment on MSKINS-174: --- was (Author: JIRAUSER287581): Of Det Contreely Behind Success Of moring Date By Free Sins > Render breadcrumbs div conditionally > > > Key: MSKINS-174 > URL: https://issues.apache.org/jira/browse/MSKINS-174 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.9 >Reporter: Konrad Windszus >Priority: Major > Attachments: breadcrumb-div.png > > > Currently the breadcrumb div is always rendered even if it is empty > (https://github.com/apache/maven-fluido-skin/blob/dda45e9236f90dc8493fcc917a99716212825573/src/main/resources/META-INF/maven/site.vm#L202). > That leads to the issue that a grey bar is rendered in case the publish date > is not rendered at the top (left or right): !breadcrumb-div.png! > That div should be rendered only conditionally in case there is > # at least one breadcrumb item or > # the publish date is positioned "left" or "right" -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7433) [REGRESSION] Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520108#comment-17520108 ] Michael Osipov commented on MNG-7433: - Here is the list of commits. https://github.com/apache/maven/compare/maven-3.8.4...maven-3.8.5 I'd recommend to remove offending commits and see whether it makes a different. But I agree with [~cstamas], there is no way that two instances can lock up each either because all locks are in-JVM. > [REGRESSION] Multiple maven instances working on same source tree can lock > each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7445: Fix Version/s: 3.8.6 > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.6, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7445: Fix Version/s: (was: 3.8.x-candidate) > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-mvnd] hboutemy commented on pull request #574: Refactor build and release workflows
hboutemy commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1094197350 the process is here https://maven.apache.org/developers/release/maven-project-release-procedure.html it should not change much even if JReleaser helps at automating a few parts (or we'll discover where it still requires future improvements) What is important is to execute the vote for minimum 72h on a release candidate available somewhere in source-release archive form (be it Apache's repository or anywhere else) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
