[jira] [Comment Edited] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519869#comment-17519869 ] Alexander Kriegisch edited comment on MSHADE-124 at 4/9/22 4:45 AM: Like I said several times, both here and in MSHADE-145: The supposed blocker problem does not exist! Maybe it used to, but this issue here can be implemented without any problems or need for "better plan". Someone just claimed without any proof that there was a potential problem, and even that information was hearsay. If there is in fact a problem which I never found in my own research I documented in MSHADE-145, maybe someone can come up with proof, e.g. a failing integration test or so. I *always* put that file into the target directory without any issues. was (Author: kriegaex): Like I said several times, both here and in MSHADE-145: The supposed blocker problem does not exist! Maybe it used to, but this issue here can be implemented without any problems or need for "better plan". Someone just claimed without any proof that there was a potential problem, and even that information was hearsay. If there is infact a problem which I never found in my own research I documented in MSHADE-145, maybe someone can come up with proof, e.g. a failing integration test or so. > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[
https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331518#comment-17331518
]
Alexander Kriegisch edited comment on MSHADE-124 at 4/9/22 4:45 AM:
If this has ben an issue for 9 years, maybe some new ideas would help? I use
Maven Flatten Plugin in order to create POMs not unlike the dependency-reduced
POMs created by Maven Shade POM. I am unaware of any issues, placing them into
the build output directory (usually {{target}} like this:
{code:xml}
${project.build.directory}
flattened-pom.xml
{code}
Maybe a MSHADE maintainer wants to take a look at how Maven Flatten does that.
was (Author: kriegaex):
If this has ben an issue for 9 years, maybe some new ideas would help? I use
Maven Flatten Plugin in order to create POMs not unlike the dependency-reduced
POMs created by Maven Shade POM. I am unaware of any issues, placing them into
the build output directory (usually {{target}} like this:
{code:xml}
${project.build.directory}
flattened-pom.xml
{code}
Maybe an MSHADE maintainer wants to take a look at how Maven Flatten does that.
> Need better plan for getting dependency-reduced-pom.xml out of basedir
> --
>
> Key: MSHADE-124
> URL: https://issues.apache.org/jira/browse/MSHADE-124
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.7.1
>Reporter: Benson Margulies
>Priority: Major
>
> MSHADE-123 reported that putting the d-r-p into some location other
> than 'basedir' causes 'basedir' to follow it around, which can break builds.
> This is hard to fix, given the core maven definition of basedir as 'the dir
> containing the pom' with no option to change it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519869#comment-17519869 ] Alexander Kriegisch edited comment on MSHADE-124 at 4/9/22 4:44 AM: Like I said several times, both here and in MSHADE-145: The supposed blocker problem does not exist! Maybe it used to, but this issue here can be implemented without any problems or need for "better plan". Someone just claimed without any proof that there was a potential problem, and even that information was hearsay. If there is infact a problem which I never found in my own research I documented in MSHADE-145, maybe someone can come up with proof, e.g. a failing integration test or so. was (Author: kriegaex): Like I said several times, both here and in MSHADE-145: The supposed blocker problem does not exist! Maybe it used to, but this issue here can be implemented without any problems or need for "better plan". Someone just claimed without any proof that there was a potential problem, and even that information was hearsay. > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://issues.apache.org/jira/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519869#comment-17519869 ] Alexander Kriegisch commented on MSHADE-124: Like I said several times, both here and in MSHADE-145: The supposed blocker problem does not exist! Maybe it used to, but this issue here can be implemented without any problems or need for "better plan". Someone just claimed without any proof that there was a potential problem, and even that information was hearsay. > Need better plan for getting dependency-reduced-pom.xml out of basedir > -- > > Key: MSHADE-124 > URL: https://issues.apache.org/jira/browse/MSHADE-124 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.7.1 >Reporter: Benson Margulies >Priority: Major > > MSHADE-123 reported that putting the d-r-p into some location other > than 'basedir' causes 'basedir' to follow it around, which can break builds. > This is hard to fix, given the core maven definition of basedir as 'the dir > containing the pom' with no option to change it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] sbabcoc commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1093547234 @Tibor17 Here are my revisions to enable support for TestNG 7.4+ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] sbabcoc commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1093534299 Fixes #339 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resources-plugin] patpatpat123 commented on pull request #17: Bump mavenVersion from 3.1.0 to 3.8.5
patpatpat123 commented on PR #17: URL: https://github.com/apache/maven-resources-plugin/pull/17#issuecomment-1093532097 Hello Team, Is it possible to help on this one please? **maven-core-3.1.0.jar** is known to carry the vulnerability CVE-2021-26291 Having this bump will ensure a safer version of this widely used plugin. Thank you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resources-plugin] patpatpat123 commented on pull request #12: Bump commons-io from 2.6 to 2.11.0
patpatpat123 commented on PR #12: URL: https://github.com/apache/maven-resources-plugin/pull/12#issuecomment-1093530217 Hello Team, Is it possible to help on this one please? **commons-io-2.6.jar** is known to **carry the vulnerability CVE-2021-29425** Having this bump will ensure a safer version of this widely used plugin. Thank you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a diff in pull request #505: [SUREFIRE-2055] Always show random seed
Tibor17 commented on code in PR #505:
URL: https://github.com/apache/maven-surefire/pull/505#discussion_r846545476
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -3114,9 +3114,8 @@ protected void warnIfIllegalFailOnFlakeCount() throws
MojoFailureException
private void printDefaultSeedIfNecessary()
{
-if ( getRunOrderRandomSeed() == null && getRunOrder().equals(
RunOrder.RANDOM.name() ) )
+if ( getRunOrder().equals( RunOrder.RANDOM.name() ) )
{
-setRunOrderRandomSeed( System.nanoTime() );
Review Comment:
I think you wanted to have the following:
```
if ( getRunOrderRandomSeed() == null )
{
setRunOrderRandomSeed( System.nanoTime() );
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #516: [SUREFIRE-2065] Test Reports Inconsistencies with Parameterized and junit4
Tibor17 commented on PR #516: URL: https://github.com/apache/maven-surefire/pull/516#issuecomment-1093484047 What happens if you run the command `$ mvn clean install`? We have Mac in Github Actions and it does not any problems like this. -- 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] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519764#comment-17519764
]
Daniel Subelman edited comment on SUREFIRE-2063 at 4/8/22 10:32 PM:
[~mthmulders], I uploaded to GitHub a minimal [sample
project|https://github.com/dsubelman/surefire-bug] that reproduces the bug.
was (Author: dsubel):
[~mthmulders], I uploaded a minimal sample
[project|https://github.com/dsubelman/surefire-bug] that reproduces the bug:
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519764#comment-17519764
]
Daniel Subelman edited comment on SUREFIRE-2063 at 4/8/22 10:31 PM:
[~mthmulders], I uploaded a minimal sample
[project|https://github.com/dsubelman/surefire-bug] that reproduces the bug:
was (Author: dsubel):
[~mthmulders], I'll try to create a project that replicates the bug.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-jlink-plugin] slachiewicz merged pull request #103: Bump actions/setup-java from 2 to 3
slachiewicz merged PR #103: URL: https://github.com/apache/maven-jlink-plugin/pull/103 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] dependabot[bot] opened a new pull request, #103: Bump actions/setup-java from 2 to 3
dependabot[bot] opened a new pull request, #103: URL: https://github.com/apache/maven-jlink-plugin/pull/103 Bumps [actions/setup-java](https://github.com/actions/setup-java) from 2 to 3. Release notes Sourced from https://github.com/actions/setup-java/releases;>actions/setup-java's releases. v3.0.0 In scope of this release we changed version of the runtime Node.js for the setup-java action and updated package-lock.json file to v2. Breaking Changes With the update to Node 16 in https://github-redirect.dependabot.com/actions/setup-java/pull/290;>#290, all scripts will now be run with Node 16 rather than Node 12. v2.5.0 In scope of this pull request we add support for Microsoft Build of OpenJDK (https://github-redirect.dependabot.com/actions/setup-java/pull/252;>actions/setup-java#252). steps: - name: Checkout uses: actions/checkout@v2 - name: Setup-java uses: actions/setup-java@v2 with: distribution: microsoft java-version: 11 Supported distributions Currently, the following distributions are supported: Keyword Distribution Official site License temurin Eclipse Temurin https://adoptium.net/;>Link https://adoptium.net/about.html;>Link zulu Zulu OpenJDK https://www.azul.com/downloads/zulu-community/?package=jdk;>Link https://www.azul.com/products/zulu-and-zulu-enterprise/zulu-terms-of-use/;>Link adopt or adopt-hotspot Adopt OpenJDK Hotspot https://adoptopenjdk.net/;>Link https://adoptopenjdk.net/about.html;>Link adopt-openj9 Adopt OpenJDK OpenJ9 https://adoptopenjdk.net/;>Link https://adoptopenjdk.net/about.html;>Link liberica Liberica JDK https://bell-sw.com/;>Link https://bell-sw.com/liberica_eula/;>Link microsoft Microsoft Build of OpenJDK https://www.microsoft.com/openjdk;>Link https://docs.microsoft.com/java/openjdk/faq;>Link v2.4.0 In scope of this pull request we add support for Liberica JDK (https://github-redirect.dependabot.com/actions/setup-java/pull/225;>actions/setup-java#225). steps: - name: Checkout uses: actions/checkout@v2 - name: Setup-java uses: actions/setup-java@v2 with: distribution: liberica java-version: 11 Supported distributions Currently, the following distributions are supported: Keyword Distribution Official site License zulu Zulu OpenJDK https://www.azul.com/downloads/zulu-community/?package=jdk;>Link https://www.azul.com/products/zulu-and-zulu-enterprise/zulu-terms-of-use/;>Link adopt or adopt-hotspot Adopt OpenJDK Hotspot https://adoptopenjdk.net/;>Link https://adoptopenjdk.net/about.html;>Link adopt-openj9 Adopt OpenJDK OpenJ9 https://adoptopenjdk.net/;>Link https://adoptopenjdk.net/about.html;>Link temurin Eclipse Temurin https://adoptium.net/;>Link https://adoptium.net/about.html;>Link ... (truncated) Commits https://github.com/actions/setup-java/commit/0aa6f2a84f8634ac1a1bd81dfdf6d5aab98c70f1;>0aa6f2a Bump minimist from 1.2.5 to 1.2.6 (https://github-redirect.dependabot.com/actions/setup-java/issues/303;>#303) https://github.com/actions/setup-java/commit/dc1a9f27915005c4867178213f98cc27415de97a;>dc1a9f2 Caching on GHES (https://github-redirect.dependabot.com/actions/setup-java/issues/308;>#308) https://github.com/actions/setup-java/commit/e886040dc21d1d2c3f71482e1b6518445ef5e620;>e886040 Update zulu-installer.test.ts (https://github-redirect.dependabot.com/actions/setup-java/issues/310;>#310) https://github.com/actions/setup-java/commit/efbea1411b18823f99d704f247a3090511af93db;>efbea14 Update util.ts https://github.com/actions/setup-java/commit/c41070eda4f4d598540a89ad4a0e333b2b5bba07;>c41070e Update util.ts https://github.com/actions/setup-java/commit/f69f00b5e5324696b07f6b1c92f0470a6df00780;>f69f00b Update lockfileVersion (https://github-redirect.dependabot.com/actions/setup-java/issues/293;>#293) https://github.com/actions/setup-java/commit/2e1dfa1fb43424fa6465aaeacd047e9ef2f69961;>2e1dfa1 Update Default runtime to node16 (https://github-redirect.dependabot.com/actions/setup-java/issues/290;>#290) https://github.com/actions/setup-java/commit/a12e082d834968c1847f782019214fadd20719f6;>a12e082 Merge pull request https://github-redirect.dependabot.com/actions/setup-java/issues/224;>#224 from KengoTODA/remove-husky https://github.com/actions/setup-java/commit/04d53533c260c5d4b63a5c354d85d12ee217ebd6;>04d5353 Merge pull request https://github-redirect.dependabot.com/actions/setup-java/issues/215;>#215 from beatngu13/update-readme-cache-key https://github.com/actions/setup-java/commit/d8da887cad432a14fdb5025b0f7ebde23972b258;>d8da887 Merge pull request
[GitHub] [maven-surefire] sbabcoc commented on a diff in pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc commented on code in PR #517: URL: https://github.com/apache/maven-surefire/pull/517#discussion_r846510472 ## surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java: ## @@ -37,33 +35,45 @@ * * @since 3.0.0-M6 */ -public class TestNG740Configurator extends TestNG60Configurator +public class TestNG740Configurator +extends TestNG60Configurator Review Comment: This is the style employed by **all** of the other classes in this project. -- 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=17519781#comment-17519781 ] Dan Tran edited comment on MNG-7433 at 4/8/22 9:39 PM: --- Thanks for the suggestion regarding 'aggregating mojo', I found the consistent pattern where * after sonar-analysis module execution invoked mdev:sonar ( aggregating mojo which spins a maven instance to run sonar:sonar), other thread is blocked when it runs any aggregating mojos. we have a number of internal mojos with 'aggregator = true' set at @Mojo annotation used during the build process. We set it this way so that it is not running in reactor mode in default My guess here is I need to update all internal mojos with aggregator=false. btw buildnumber-m-p from MojoHaus is also in the same category is it something the Maven team can fix in 3.9? was (Author: dantran): Thanks for the suggestion regarding 'aggregating mojo', I found the consistent pattern where * after sonar-analysis module execution invoked mdev:sonar ( aggregating mojo which spins a maven instance to run sonar:sonar), other thread is blocked when it runs any aggregating mojos. Attempt to make mdev:sonar as non 'aggregating mojo' don't seem to help we have a number of internal mojos with 'aggregator = true' set at @Mojo annotation used during the build process. We set it this way so that it is not running in reactor mode in default My guess here is I need to update all internal mojos with aggregator=false. btw buildnumber-m-p also in same category is it something Maven team can fix in 3.9? > [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-mvnd] aalmiray commented on pull request #574: Refactor build and release workflows
aalmiray commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1093379215 Once merged, the `early-access.yml` workflow will kick in and generate a prerelease title "Release early-access" with the latest binaries. This is independent of the Apache Maven release process. Then, for a regular release, a release candidate must be voted. Manually trigger the `release-candidate-stage1.yml` workflow to generate the binaries. This workflow creates a git release in prerelase mode if not mistaken. Once the vote passes then manually trigger the `release.yml` workflow. **BUT** before you do trigger please review the settings for Homebrew and Sdkman. A personal Git access token is required to push the formula to the target Git repository. My suggestion would be to merge this PR and let the early-access release do its work. We can then discuss the steps to post a release following the Apache Maven release process (of which I've never been a party of). We might need the help of an Apache Maven guide (@hboutemy?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] SykApps commented on a diff in pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
SykApps commented on code in PR #517: URL: https://github.com/apache/maven-surefire/pull/517#discussion_r846501870 ## surefire-providers/surefire-testng/src/main/java/org/apache/maven/surefire/testng/conf/TestNG740Configurator.java: ## @@ -37,33 +35,45 @@ * * @since 3.0.0-M6 */ -public class TestNG740Configurator extends TestNG60Configurator +public class TestNG740Configurator +extends TestNG60Configurator Review Comment: Nit: can you put the extends back on the same line as the class. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on pull request #574: Refactor build and release workflows
gnodet commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1093373132 > @gnodet are there any plans to release any time soon? Yes, a release is long overdue. What's the process now ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-315) Upgrade Maven Clean Plugin from 3.1.0 to 3.2.0
Slawomir Jaranowski created MPOM-315: Summary: Upgrade Maven Clean Plugin from 3.1.0 to 3.2.0 Key: MPOM-315 URL: https://issues.apache.org/jira/browse/MPOM-315 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Fix For: ASF-26 h1. Release Notes - Maven Clean Plugin - Version 3.2.0 h2. New Feature * [MCLEAN-95] - Provide a fast deletion option h2. Improvement * [MCLEAN-89] - Add GitHub Information * [MCLEAN-90] - Custom search broken on pages rendered using Fluido Skin 1.7 * [MCLEAN-91] - Upgrade maven-plugins to 34 * [MCLEAN-98] - Upgrade maven-plugin parent to 35 h2. Task * [MCLEAN-94] - Update plugin dependencies * [MCLEAN-97] - Require Java 8 h2. Dependency upgrade * [MCLEAN-87] - Upgrade maven-plugins parent to version 32 * [MCLEAN-92] - Require Maven 3.1.1 (drop dependency to Maven 3.0) * [MCLEAN-96] - Require Maven 3.2.5+ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #712: Use of the propsed ArtifactTransformer in Maven
slawekjaranowski commented on code in PR #712:
URL: https://github.com/apache/maven/pull/712#discussion_r846466166
##
maven-core/src/main/java/org/apache/maven/internal/aether/ConsumerPomArtifactTransformer.java:
##
@@ -0,0 +1,94 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Provider;
+import javax.inject.Singleton;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.UncheckedIOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.nio.file.Paths;
+import java.nio.file.StandardCopyOption;
+import java.util.Collection;
+import java.util.Collections;
+
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.model.building.TransformerContext;
+import org.codehaus.plexus.util.xml.pull.XmlPullParserException;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.transform.ArtifactTransformer;
+
+@Named( ConsumerPomArtifactTransformer.NAME )
+@Singleton
+public class ConsumerPomArtifactTransformer implements ArtifactTransformer
+{
+public static final String NAME = "consumer-pom";
+
+private final Provider mavenSessionProvider;
+
+@Inject
+public ConsumerPomArtifactTransformer( Provider
mavenSessionProvider )
+{
+this.mavenSessionProvider = mavenSessionProvider;
+}
+
+@Override
+public Collection transformArtifact( Artifact artifact )
+{
+MavenSession mavenSession = mavenSessionProvider.get();
+TransformerContext context = (TransformerContext) mavenSession
+.getRepositorySession().getData().get( TransformerContext.KEY
);
+if ( "pom".equals( artifact.getExtension() ) && context != null )
+{
+// TODO: fix this, make it target rather
+Path buildOutputDirectory = Paths.get(
+
mavenSession.getCurrentProject().getBuild().getTestOutputDirectory() );
Review Comment:
getTestOutputDirectory - ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] delanym commented on a diff in pull request #505: [SUREFIRE-2055] Always show random seed
delanym commented on code in PR #505:
URL: https://github.com/apache/maven-surefire/pull/505#discussion_r846487634
##
surefire-its/src/test/java/org/apache/maven/surefire/its/RunOrderIT.java:
##
@@ -97,7 +97,17 @@ public void testRandomJUnit4SameSeed()
}
}
}
-
+
+@Test
+public void testRandomJUnit4PrintSeed()
+{
+long seed = 0L;
+OutputValidator validator = executeWithRandomOrder( "junit4", seed );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
+validator = executeWithRandomOrder( "junit4" );
+validator.verifyTextInLog( "To reproduce ordering use flag" );
Review Comment:
Have I done that right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] sbabcoc commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1093350407 I've completely re-implemented the **TestNG740Configurator** class. The new implementation... * ... overrides the handling of the [parallel] option to resolve the incompatibility with TestNG 7.4+. * ... acquires the default value of the [threadcount] option to avoid superclass hardcoding to 1. * ... invokes the superclass handler to allow processing of other supported options. I retained code from the existing implementation to load the **ParallelMode** enumeration, convert the specified option to its corresponding constant, and set the **XmlSuite** parallel mode setting. I added exception handling and conditional blocks to toughen it up. -- 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=17519781#comment-17519781 ] Dan Tran edited comment on MNG-7433 at 4/8/22 8:21 PM: --- Thanks for the suggestion regarding 'aggregating mojo', I found the consistent pattern where * after sonar-analysis module execution invoked mdev:sonar ( aggregating mojo which spins a maven instance to run sonar:sonar), other thread is blocked when it runs any aggregating mojos. Attempt to make mdev:sonar as non 'aggregating mojo' don't seem to help we have a number of internal mojos with 'aggregator = true' set at @Mojo annotation used during the build process. We set it this way so that it is not running in reactor mode in default My guess here is I need to update all internal mojos with aggregator=false. btw buildnumber-m-p also in same category is it something Maven team can fix in 3.9? was (Author: dantran): Thanks for the suggestion regarding 'aggregating mojo', I found the consistent pattern where * after sonar-analysis module execution invoked mdev:sonar ( aggregating mojo which spins a maven instance to run sonar:sonar), other thread is blocked when it runs any aggregating mojos we have a number of internal mojos with 'aggregator = true' set at @Mojo annotation used during the build process. We set it this way so that it is not running in reactor mode in default My guess here is I need to update all internal mojos with aggregator=false. btw buildnumber-m-p also in same category is it something Maven team can fix in 3.9? > [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=17519781#comment-17519781 ] Dan Tran commented on MNG-7433: --- Thanks for the suggestion regarding 'aggregating mojo', I found the consistent pattern where * after sonar-analysis module execution invoked mdev:sonar ( aggregating mojo which spins a maven instance to run sonar:sonar), other thread is blocked when it runs any aggregating mojos we have a number of internal mojos with 'aggregator = true' set at @Mojo annotation used during the build process. We set it this way so that it is not running in reactor mode in default My guess here is I need to update all internal mojos with aggregator=false. btw buildnumber-m-p also in same category is it something Maven team can fix in 3.9? > [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-mvnd] ppalaga commented on pull request #574: Refactor build and release workflows
ppalaga commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1093293098 @gnodet are there any plans to release any time soon? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on pull request #574: Refactor build and release workflows
ppalaga commented on PR #574: URL: https://github.com/apache/maven-mvnd/pull/574#issuecomment-1093292310 Looks good, thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas opened a new pull request, #712: Use of the propsed ArtifactTransformer in Maven
cstamas opened a new pull request, #712: URL: https://github.com/apache/maven/pull/712 To implement Consumer POM. There are a lot of shortcuts but the code is not worse that master had (left few TODOs). All the ITs locally pass with this build. To work, requires resolver artifact-transformer branch. https://github.com/apache/maven-resolver/pull/162 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas opened a new pull request, #162: Proposed replacement for OOM-prone FileTransformer API.
cstamas opened a new pull request, #162: URL: https://github.com/apache/maven-resolver/pull/162 The new ArtifactTransformer is as it's name says: for given artifact it can return zero, one or more (transformed or same or whatever) artifacts. All the work is delegated away from resolver, as transformer implementor does all the work, no magic happens in resolver. -- 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-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519764#comment-17519764
]
Daniel Subelman commented on SUREFIRE-2063:
---
[~mthmulders], I'll try to create a project that replicates the bug.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
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=17519762#comment-17519762 ] Jim Hughes commented on MRESOLVER-133: -- Is there an example of a test which already does that? It sounds brittle as a test approach. > 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-2065) Test Reports Inconsistencies with Parameterized and junit4
[ https://issues.apache.org/jira/browse/SUREFIRE-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Marquez Grabia updated SUREFIRE-2065: --- Summary: Test Reports Inconsistencies with Parameterized and junit4 (was: JUnit4 Parameterized Tests Grouping Incorrectly) > Test Reports Inconsistencies with Parameterized and junit4 > -- > > Key: SUREFIRE-2065 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2065 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5, 3.0.0-M6, 3.0.0-M7 >Reporter: Christian Marquez Grabia >Priority: Minor > > Running parameterized tests with the junit-platform provider causes tests to > be counted as single test (unlike using junit4 provider). This makes the > tests to be marked as 'Flaky' and marks the build as successful if the retry > failed count is greater than zero. Reports also show a single test run even > if there were multiple tests with different parameters. > For a sample project with the problem see > [surefire-flaky-issue|https://github.com/chalmagr/surefire-flaky-report] > This is also a possibly related to issue SUREFIRE-2010 and may help in the > resolution of it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2065) JUnit4 Parameterized Tests Grouping Incorrectly
Christian Marquez Grabia created SUREFIRE-2065: -- Summary: JUnit4 Parameterized Tests Grouping Incorrectly Key: SUREFIRE-2065 URL: https://issues.apache.org/jira/browse/SUREFIRE-2065 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 3.0.0-M6, 3.0.0-M5, 3.0.0-M7 Reporter: Christian Marquez Grabia Running parameterized tests with the junit-platform provider causes tests to be counted as single test (unlike using junit4 provider). This makes the tests to be marked as 'Flaky' and marks the build as successful if the retry failed count is greater than zero. Reports also show a single test run even if there were multiple tests with different parameters. For a sample project with the problem see [surefire-flaky-issue|https://github.com/chalmagr/surefire-flaky-report] This is also a possibly related to issue SUREFIRE-2010 and may help in the resolution of it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on pull request #635: [Experiment] Maven w/ transport-http
cstamas commented on PR #635: URL: https://github.com/apache/maven/pull/635#issuecomment-1093100054 Superseded by https://github.com/apache/maven/pull/711 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas closed pull request #635: [Experiment] Maven w/ transport-http
cstamas closed pull request #635: [Experiment] Maven w/ transport-http URL: https://github.com/apache/maven/pull/635 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas opened a new pull request, #711: [MNG-7454] Include resolver-transport-http in Maven
cstamas opened a new pull request, #711: URL: https://github.com/apache/maven/pull/711 But keep Wagon as default transport. This PR merely includes resolver http and file transport and switches wagon-http to non-shaded one. Changes: * switch to non-shaded wagon-http (as httpClient is now shared) * include resolver http and file transport * override resolver default behaviour (native transport preferred over wagon, when both on classpath) * provide simplistic means to choose transport The chosen transport can be seen in debug (-X) output on line `[DEBUG] Using transporter XXX...` The `-Dmaven.transport` simplistic switch can be used to choose transport: * not set: default, that is Wagon * `wagon`: explicitly sets Wagon * `resolver`: explicitly sets resolver native transports (file and http) * `auto`: relies on resolver "auto discovery" (priorities, etc). This is MUST to keep transport pluggable with 3rd party transports. In fact, this was the default so far in Maven, along with the fact that native resolver transports were not included (as resolver prefers native ones over Wagon). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas commented on pull request #710: [MNG-7454] Include resolver-transport-http in Maven
cstamas commented on PR #710: URL: https://github.com/apache/maven/pull/710#issuecomment-1093084247 Branch maven-3.9.x is fixed in the mean time, so now all ITs needs to pass. -- 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-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519708#comment-17519708
]
Maarten Mulders commented on SUREFIRE-2063:
---
[~dsubel], would it be possible for you to isolate the problem in a minimal
sample project? If it's indeed a bug, that sample could also serve as future
test case to prevent the bug from happening again.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7447) Several Improvements by using Stream API
[ https://issues.apache.org/jira/browse/MNG-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519705#comment-17519705 ] Hudson commented on MNG-7447: - Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #14 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/14/ > Several Improvements by using Stream API > > > Key: MNG-7447 > URL: https://issues.apache.org/jira/browse/MNG-7447 > Project: Maven > Issue Type: Sub-task >Affects Versions: 3.9.0, 4.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.9.0, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7447) Several Improvements by using Stream API
[ https://issues.apache.org/jira/browse/MNG-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519701#comment-17519701 ] Hudson commented on MNG-7447: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-710 #4 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-710/4/ > Several Improvements by using Stream API > > > Key: MNG-7447 > URL: https://issues.apache.org/jira/browse/MNG-7447 > Project: Maven > Issue Type: Sub-task >Affects Versions: 3.9.0, 4.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.9.0, 4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MJAVADOC-709) JDK 17 support
[
https://issues.apache.org/jira/browse/MJAVADOC-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MJAVADOC-709:
-
Fix Version/s: waiting-for-feedback
> JDK 17 support
> --
>
> Key: MJAVADOC-709
> URL: https://issues.apache.org/jira/browse/MJAVADOC-709
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.2
>Reporter: Gili
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal
> I get the following error:
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 61.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:37)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:90)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:38)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:364)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:135)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5232)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2213)
> at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
> (JavadocJar.java:189)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:2041)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 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:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> 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:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> 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)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
> Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MJAVADOC-709) JDK 17 support
[
https://issues.apache.org/jira/browse/MJAVADOC-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519693#comment-17519693
]
Slawomir Jaranowski commented on MJAVADOC-709:
--
Version *3.3.2* of {{m-javadoc-p}} use {{asm:9.2}} so Java 17 and 18 should be
supported.
https://asm.ow2.io/versions.html
Please provide simple minimal project which reproduce your issue.
You can check output of {{mvn -V javadoc:jar -X}}, should contains lines:
{code}
[DEBUG] org.apache.maven.plugins:maven-javadoc-plugin:jar:3.3.2
...
[DEBUG]org.codehaus.plexus:plexus-java:jar:1.1.0:compile
[DEBUG] org.ow2.asm:asm:jar:9.2:compile
...
[DEBUG] Populating class realm
plugin>org.apache.maven.plugins:maven-javadoc-plugin:3.3.2
...
[DEBUG] Included: org.codehaus.plexus:plexus-java:jar:1.1.0
[DEBUG] Included: org.ow2.asm:asm:jar:9.2
{code}
> JDK 17 support
> --
>
> Key: MJAVADOC-709
> URL: https://issues.apache.org/jira/browse/MJAVADOC-709
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.2
>Reporter: Gili
>Priority: Blocker
>
> The latest release of the Javadoc plugin is 3.3.2. When I run the `jar` goal
> I get the following error:
> {code:java}
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported
> major.minor version 61.0
> at jdk.internal.module.ModuleInfo.invalidModuleDescriptor
> (ModuleInfo.java:1091)
> at jdk.internal.module.ModuleInfo.doRead (ModuleInfo.java:195)
> at jdk.internal.module.ModuleInfo.read (ModuleInfo.java:131)
> at java.lang.module.ModuleDescriptor.read (ModuleDescriptor.java:2487)
> at org.codehaus.plexus.languages.java.jpms.BinaryModuleInfoParser.parse
> (BinaryModuleInfoParser.java:37)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:90)
> at
> org.codehaus.plexus.languages.java.jpms.AbstractBinaryModuleInfoParser.getModuleDescriptor
> (AbstractBinaryModuleInfoParser.java:38)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:364)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:135)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5232)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2213)
> at org.apache.maven.plugins.javadoc.JavadocJar.doExecute
> (JavadocJar.java:189)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:2041)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 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:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> 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:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> 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)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47){code}
> Please add JDK 17 and 18 support now that the latter is out.
--
This message was sent by Atlassian
[GitHub] [maven] cstamas merged pull request #709: [MNG-7447] Fix ReactorReader unintended change
cstamas merged PR #709: URL: https://github.com/apache/maven/pull/709 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] sbabcoc commented on pull request #517: [SUREFIRE-2064] Allow all supported values of [parallel] option
sbabcoc commented on PR #517: URL: https://github.com/apache/maven-surefire/pull/517#issuecomment-1093056148 In this PR, I fixed issues with handling of the [parallel] option in the existing implementation. However, I've since noticed that this class lacks implementation that would produce corresponding command line options for the options it supports. Also, no handling was provided for potential `NumberFormatException` failures. Finally, no unit tests were implemented for this class. These were potentially skipped because the version of TestNG specified by this project's dependencies (v5.10) pre-dates the introduction of the supported features. These deficiencies should be addressed to maintain the quality of the Surefire project. I'll switch this PR to "draft" mode and see what I can do about the unit test issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] chalmagr commented on pull request #516: Test Reports Inconsistencies with Parameterized and junit4
chalmagr commented on PR #516: URL: https://github.com/apache/maven-surefire/pull/516#issuecomment-1093047652 > @chalmagr How can I reproduce the first issue with `ClassNotFoundException`? This issue happens when I try to build the maven-surefire project in my laptop - I don't have the problem when running the tests in the other test project ```bash $ mvn --version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: ... Java version: 1.8.0_92, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" ``` ```bash $ mvn clean install site site:stage -P reporting,run-its ... [INFO] Reactor Summary for Apache Maven Surefire 3.0.0-M7-SNAPSHOT: [INFO] [INFO] Apache Maven Surefire .. SUCCESS [ 20.238 s] [INFO] Surefire Shared Utils .. SUCCESS [ 6.816 s] [INFO] SureFire Logger API SUCCESS [ 16.375 s] [INFO] SureFire API ... FAILURE [ 5.184 s] ... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on project surefire-api: There are test failures. [ERROR] [ERROR] Please refer to /Users/chalmagr/projects/maven-surefire/surefire-api/target/surefire-reports for the individual test results. [ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream. [ERROR] The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd /Users/chalmagr/projects/maven-surefire/surefire-api && /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/java -Xms32m -Xmx144m -XX:SoftRefLRUPolicyMSPerMB=50 -Djava.awt.headless=true -Djdk.net.URLClassPath.disableClassPathURLCheck=true '-javaagent:/Users/chalmagr/.m2/repository/org/jacoco/org.jacoco.agent/0.8.7/org.jacoco.agent-0.8.7-runtime.jar=destfile=/Users/chalmagr/projects/maven-surefire/surefire-api/target/jacoco.exec,includes=**/failsafe/*:**/failsafe/**/*:**/surefire/*:**/surefire/**/*,excludes=**/HelpMojo.class:**/shadefire/**/*:org/jacoco/**/*:com/vladium/emma/rt/*' org.apache.maven.shadefire.surefire.booter.ForkedBooter /Users/chalmagr/projects/maven-surefire/surefire-api/target/surefire 2022-04-08T10-40-14_147-jvmRun1 surefire5745983445816295292tmp surefire_0369998306054510421tmp ... ``` The log file contains the below ``` # Created at 2022-04-08T10:40:14.589 objc[11846]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/bin/java (0x10ab474c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10ad154e0). One of the two will be used. Which one is undefined. # Created at 2022-04-08T10:40:14.751 Error: Could not find or load main class org.apache.maven.shadefire.surefire.booter.ForkedBooter ``` Hope this helps... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519643#comment-17519643
]
Hudson commented on MNG-7441:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » PR-509 #12
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-509/12/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519644#comment-17519644 ] Hudson commented on MNG-7432: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-509 #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-509/12/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519635#comment-17519635
]
Hudson commented on MNG-7441:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » PR-635 #16
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-635/16/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519636#comment-17519636 ] Hudson commented on MNG-7432: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-635 #16 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-635/16/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519634#comment-17519634 ] Hudson commented on MNG-7432: - Build failed in Jenkins: Maven » Maven TLP » maven » PR-394 #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-394/13/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519633#comment-17519633
]
Hudson commented on MNG-7441:
-
Build failed in Jenkins: Maven » Maven TLP » maven » PR-394 #13
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-394/13/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519623#comment-17519623
]
Hudson commented on MNG-7441:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-565 #12
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-565/12/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519624#comment-17519624 ] Hudson commented on MNG-7432: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-565 #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-565/12/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- 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=17519618#comment-17519618
]
Tamás Cservenák edited comment on MNG-7433 at 4/8/22 3:04 PM:
--
And what arguments are used to invoke the original build. And now I see, it is
not the "other" maven that locks here, but the blocking wait within
sonar:sonar, that I guess WAITS for the spawned process to finish...
Also, both mojos you'd run, sonar and puppet-config are {_}aggregating
mojos{_}? As aggregating mojos, when running in parallel, may become loose
cannon, and that lock is in place exactly to allow only one aggregating mojo to
run at same time Also, maven has no idea WHAT mojo would do, it seems it's
only aggregating.
was (Author: cstamas):
And what arguments are used to invoke the original build. And now I see, it is
not the "other" maven that locks here, but the blocking wait within
sonar:sonar, that I guess WAITS for the spawned process to finish...
> [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-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519620#comment-17519620 ] Hudson commented on MNG-7432: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-600 #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-600/12/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519619#comment-17519619
]
Hudson commented on MNG-7441:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-600 #12
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-600/12/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
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=17519618#comment-17519618 ] Tamás Cservenák commented on MNG-7433: -- And what arguments are used to invoke the original build. And now I see, it is not the "other" maven that locks here, but the blocking wait within sonar:sonar, that I guess WAITS for the spawned process to finish... > [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-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519608#comment-17519608 ] Hudson commented on MNG-7432: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-700 #6 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-700/6/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519607#comment-17519607
]
Hudson commented on MNG-7441:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » PR-700 #6
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-700/6/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7452) Remove JDK7 run on Maven 3.9.X Branch
[ https://issues.apache.org/jira/browse/MNG-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519606#comment-17519606 ] Hudson commented on MNG-7452: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-700 #6 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-700/6/ > Remove JDK7 run on Maven 3.9.X Branch > - > > Key: MNG-7452 > URL: https://issues.apache.org/jira/browse/MNG-7452 > Project: Maven > Issue Type: Task >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Resolver session contains non-MavenWorkspaceReader
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519610#comment-17519610 ] Hudson commented on MNG-7432: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-705 #4 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-705/4/ > [REGRESSION] Resolver session contains non-MavenWorkspaceReader > --- > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Assignee: Tamás Cservenák >Priority: Critical > Fix For: 3.8.6, 3.9.0, 4.0.0 > > > As Resolver session contains non-MavenWorkspaceReader, the reactor models > (already resolved w/ profiles applied) are re-built when using Resolver > within Mojo, instead to get them via ReactorReader as expected. The rebuilt > models will lack explicit (-P on CLI) profiles applied, as resolver itself is > not maven aware, hence there is no way to "tell" resolver to apply them. > Building reactor models w/ profiles applied is NOT done using resolver, but > by Maven when loading up reactor, as profiles are NOT applied for downstream > transitive dependencies (see discussion on MNG-1388 why). > --- > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7441) Update Version of Logback to Address CVE-2021-42550
[
https://issues.apache.org/jira/browse/MNG-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519609#comment-17519609
]
Hudson commented on MNG-7441:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-705 #4
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-705/4/
> Update Version of Logback to Address CVE-2021-42550
> ---
>
> Key: MNG-7441
> URL: https://issues.apache.org/jira/browse/MNG-7441
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.8.5
>Reporter: Mac Hale
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.8.6, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> [CVE-2021-42550|https://nvd.nist.gov/vuln/detail/CVE-2021-42550] is present
> in Logback versions 1.2.7 and earlier. Maven uses v 1.2.1. Please update to
> Logback 1.2.9, which includes a fix as per
> [https://jira.qos.ch/browse/LOGBACK-1591|[https://jira.qos.ch/browse/LOGBACK-1591].]
> I see ch.qos.logback 1.2.1 in {{./pom.xml}} and ch.qos.logback without a
> version specified in {{./maven-embedder/pom.xml}}
> But I'm no expert on this code base so it's possible there are other
> versioned references.
> Edit: One could argue, as the Logback team has done, that the CVE is
> unimportant since in order to exploit it one must already have compromised
> the system. However, security scanners pick this up as an issue, causing
> unnecessary work and justifications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Subelman updated SUREFIRE-2063:
--
Priority: Blocker (was: Major)
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] cstamas commented on pull request #710: [MNG-7454] Include resolver-transport-http in Maven
cstamas commented on PR #710: URL: https://github.com/apache/maven/pull/710#issuecomment-1092934252 As master is broken until https://github.com/apache/maven/pull/709 merged, MNG6090 ITs are expected to fail, but Wagon ancient (plexus XML and other) ITs should succeed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #516: Test Reports Inconsistencies with Parameterized and junit4
Tibor17 commented on PR #516: URL: https://github.com/apache/maven-surefire/pull/516#issuecomment-1092933166 @chalmagr How can I reproduce the first issue with `ClassNotFoundException`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #516: Test Reports Inconsistencies with Parameterized and junit4
Tibor17 commented on PR #516: URL: https://github.com/apache/maven-surefire/pull/516#issuecomment-1092929095 We should separate this problem in two. I can see the first problem with `ClassNotFoundException`, and the second issue with junit4. Let me reproduce the issues with your project. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7454) Include resolver-transport-http in Maven
[ https://issues.apache.org/jira/browse/MNG-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MNG-7454: Assignee: Tamás Cservenák > Include resolver-transport-http in Maven > > > Key: MNG-7454 > URL: https://issues.apache.org/jira/browse/MNG-7454 > Project: Maven > Issue Type: New Feature > Components: Dependencies >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0 > > > We should include maven-resolver-transport-http (along with existing > maven-resolver-transport-wagon) but retain Wagon as default transport, while > offer ability for users to use http transport to utilize new resolver > features like "smart checksums". > On positive side, this will finally get rid of shaded httpClient and > wagon-http-shaded as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas opened a new pull request, #710: [MNG-7454] Include resolver-transport-http in Maven
cstamas opened a new pull request, #710: URL: https://github.com/apache/maven/pull/710 But keep Wagon as default transport. This PR merely includes resolver http and file transport and switches wagon-http to non-shaded one. Changes: * switch to non-shaded wagon-http (as httpClient is now shared) * include resolver http and file transport * override resolver default behaviour (native transport preferred over wagon, when both on classpath) * provide simplistic means to choose transport The chosen transport can be seen in debug (-X) output on line `[DEBUG] Using transporter XXX...` The `-Dmaven.traport` simplistic switch can be used to choose tranport: * not set: default, that is Wagon * `wagon`: explicitly sets Wagon * `resolver`: explicitly sets resolver native transports (file and http) * `auto`: relies on resolver "auto discovery" (priorities, etc). This is MUST to keep transport pluggable with 3rd party transports. Note: resolver by default, if both wagon and native transports are present on classpath, would prefer native ones. Hence, to retain "wagon as default" this extra config bit is a must in Maven. -- 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=17519584#comment-17519584 ] Gregory Ducharme commented on MRESOLVER-133: Well, an ugly way to test this would be to override the maven logger and capture the output since maven does log everything it downloads. You would need to use an empty local repo. Then you could just add some logic to see if the optimal set of files was downloaded. > 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-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=17519576#comment-17519576 ] Jim Hughes commented on MRESOLVER-133: -- [~michael-o] I'm interested in this ticket as well. When I looked at this related issue, I couldn't find an obvious way to write an integration test to show the issue with range resolution downloading all the dependencies in the range. If the recent work in the resolver hasn't addressed that issue, can you suggest some way to test the necessary changes? https://issues.apache.org/jira/browse/MNG-7049 > 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)
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #150: Use old version of m-enforcer-p for JDK 1.7
slawekjaranowski merged PR #150: URL: https://github.com/apache/maven-integration-testing/pull/150 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas commented on pull request #709: Fix ReactorReader unintended change
cstamas commented on PR #709: URL: https://github.com/apache/maven/pull/709#issuecomment-1092795801 The problem is shown by maven-3.9.x branch, where these two IT fails ``` Error: Errors: Error: MavenITmng6090CIFriendlyTest>AbstractMavenIntegrationTestCase.runTest:265->testitShouldResolveTheDependenciesWithBuildConsumer:105 » Verification Error: MavenITmng6090CIFriendlyTest>AbstractMavenIntegrationTestCase.runTest:265->testitShouldResolveTheDependenciesWithoutBuildConsumer:76 » Verification ``` See https://github.com/apache/maven/commit/263cf9542b4f137c59ab19fb4fae9f0d61ce2afa -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas opened a new pull request, #709: Fix ReactorReader unintended change
cstamas opened a new pull request, #709: URL: https://github.com/apache/maven/pull/709 The commit c604db3c3a103e2212f4628d8e2a997017fe579e changed ReactorReader to use MavenSession#getAllProjects() instead of deprecated MavenSession#getProjectMap() that is equivalent of MavenSession#getProjects(). This undoes this unintended change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7453) Upgrade Maven Resolver to 1.8.0
[ https://issues.apache.org/jira/browse/MNG-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7453: Fix Version/s: 4.0.0-alpha-1 > Upgrade Maven Resolver to 1.8.0 > --- > > Key: MNG-7453 > URL: https://issues.apache.org/jira/browse/MNG-7453 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > Maven Resolver 1.8 will bring multiple improvements in many area: extensible > checksum algorithms, provided checksum, ability for signature resolution, > smart checksum, new BF collection along with "old" DF collector, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #149: Skip mng7045 DropUselessAndOutdatedCdiApiTest on JDK 1.7
slawekjaranowski merged PR #149: URL: https://github.com/apache/maven-integration-testing/pull/149 -- 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=17519531#comment-17519531 ] Michael Osipov commented on MRESOLVER-133: -- [~ibabiankou], [~wecai], we have now merged a lot. Does it change the state of this ticket in any regard? > 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-224) DefaultVersionResolver is inflicting ArtifactNotFoundException for classifiers with SNAPSHOT version
[
https://issues.apache.org/jira/browse/MRESOLVER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519529#comment-17519529
]
Michael Osipov commented on MRESOLVER-224:
--
Still waiting for a sample.
> DefaultVersionResolver is inflicting ArtifactNotFoundException for
> classifiers with SNAPSHOT version
>
>
> Key: MRESOLVER-224
> URL: https://issues.apache.org/jira/browse/MRESOLVER-224
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Tuomas Kiviaho
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I use classifier artifact along with the artifact itself as a dependency in a
> Maven Invoker Plugin project. The project that calls the invoker has the
> artifact itself as a dependency, but no reference to the classifier.
> This causes resolving of the maven-metadata.xml for the project itself plus
> downloading of the dependency artifact.When invoker is called the artifact is
> already downloaded to the local repo and cached with SNAPSHOT key.
> This causes the DefaultVersionResolver to merge the version information of
> the SNAPSHOT:jar artifact that is now being resolved with the
> already downloaded SNAPSHOT key. Since the local version is newer than the
> repo version the DefaultVersionResolver thinks SNAPSHOT:jar to
> be outdated thus overriding it with local repo.
> Since the SNAPSHOT:jar doesn't exist in the local repo there
> are no remote report left to try the DefaultArtifactResolver fails ultimately
> to ArtifactNotFoundException since there was no download task.
> {code:java}
> [INFO] [DEBUG] Resolving artifact
> .:jar::-SNAPSHOT from
> []{code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-178) Introduce a simple inter-process SyncContext
[ https://issues.apache.org/jira/browse/MRESOLVER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519528#comment-17519528 ] Michael Osipov commented on MRESOLVER-178: -- Can this be closed? We have a file-based approach in place. > Introduce a simple inter-process SyncContext > - > > Key: MRESOLVER-178 > URL: https://issues.apache.org/jira/browse/MRESOLVER-178 > Project: Maven Resolver > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MRESOLVER-247) Avoid unnecessary dependency resolution by a Skip solution based on BFS
[
https://issues.apache.org/jira/browse/MRESOLVER-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-247.
Resolution: Fixed
Fixed with
[0dd06936464ebd917f4115554c283bd676f477f4|https://gitbox.apache.org/repos/asf?p=maven-resolver.git=commit=0dd06936464ebd917f4115554c283bd676f477f4].
> Avoid unnecessary dependency resolution by a Skip solution based on BFS
> ---
>
> Key: MRESOLVER-247
> URL: https://issues.apache.org/jira/browse/MRESOLVER-247
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: wei cai
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: exclusion-matters.png, skip-duplicate.png,
> skip-version-conflicts.png
>
>
> h1. *Background*
> This Jira is related with MRESOLVER-240 and MRESOLVER-228
> There were discussions about the DFS or BFS algorithm for maven resolver in
> MRESOLVER-228, Changing to BFS would make MRESOLVER-228 & MRESOLVER-7 much
> easier to implement. Here is the plan for multiple changes requested recently:
> * DFS > BFS - preparation for parallel download
> * Skip approach - avoid unnecessary version resolution （Covered in this JIRA）
> * Download descriptors in parallel (MRESOLVER-7)
> h1. *The phenomenon*
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
>
> !exclusion-matters.png!
>
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children (D & E in this case) need to be
> recalculated. Recalculating all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> h1. Solution
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip approach to avoid unnecessary dependency resolution.
> h2. *CASE 1: Skip duplicate node (omitted duplicate case in dependency tree)*
> !skip-duplicate.png!
> From above figure:
> * The R#3 is resolved at depth 2, in the BFS solution, we already know R#3
> is the winner.
> * The R#5 won't be the winner, however here we force resolved this node as
> it is more left than the last resolved R#3 node. This is because maven picks
> up widest scope present among conflicting dependencies (scopes of the
> conflicts may differ), we need to *retain the conflict paths* by using a
> strategy like:
> ** R#3 locates in coordinate (2 - depth, 2 - sequence in given depth) while
> R#5 locates in (3,1), R#5 is more left than R#3, so we need to force resolve
> R#5.
> ** If there is a R#6 which is more left than R#5, then need to force resolve
> R#6.
> * The R#8 is at depth 3 and the R#12 at depth 4 are simply skipped as R#3 is
> already resolved at depth 2. This is because the same node with deeper depth
> won't be picked up by maven as maven employs a "nearest transitive dependency
> in the tree depth and the first in resolution" strategy.
> h2. *CASE 2: Skip version conflict (omitted conflict case in dependency tree)*
> *!skip-version-conflicts.png!*
> In above figure.
> * The D1 (D with version 1, #4) is resolved, in the BFS solution, we already
> know D1 is the winner
> * When comes to resolve D2 (D with version 2, after #4), we know D2 is
> having a different version and it conflicts with D1, D2 will be skipped as it
> won't be picked up by maven, all D2's children *won't be resolved* then.
> After we enabled the resolver patch in maven, we are seeing 10% ~70% build
> time reduced for different projects depend on how complex the dependencies
> are, and the result of *mvn
[jira] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521 ] Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/8/22 11:30 AM: [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators, e.g. by managing contributions in a different, more collaborative and less tiresome way, maximising the work *not* done by yourself and accepting contributions, even if it means that you might have to do some more polishing. That would still be quicker than micro-managing contributors until they changed every detail the way you would have implemented it yourself. You would get more work done per time unit like that. If PRs would be less time-consuming and bureaucratic, the danger of disheartening contibutors and making them stop contributing after the first few tries would also be smaller. Not everyone can afford to focus so much on this project as you can, i.e. if PR reviews require many iterations, you only get one-time contributors. That does not scale well. People who contribute more often also tend to learn and improve the quality of contributions over time. For yourself, many iterations of reviewing, discussing and re-reviewing is also wasteful, because each iteration requires a context switch from what you did before and what you want to do next. You lose focus. It would be better to get a PR off the table quickly, actively helping to finish it. When it is merged, it is off the table, does not dangle around for weeks or months, having to be rebased often or ending with an ugly merge. You can forget about it and focus on your next piece of work. The ratio of touch time vs. cycle time for each given piece of work should be as small as possible, everything else is waste. Can you afford waste, given your limited resources? P.S.: I know that reading this also costs some of your precious time. You do not need to reply at all. Just read it and think about it. It is not important whether I am right or wrong, whether my idea is good or bad. It is just an idea, I mean no harm, and you decide if you want to forget about it or implement (part of) it. I am saying all this with the utmost respect to you, dear Tibor. was (Author: kriegaex): [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that,
[jira] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521 ] Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/8/22 11:29 AM: [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators, e.g. by managing contributions in a different, more collaborative and less tiresome way, maximising the work *not* done by yourself and accepting contributions, even if it means that you might have to do some more polishing. That would still be quicker than micro-managing contributors until they changed every detail the way you would have implemented it yourself. You would get more work done per time unit like that. If PRs would be less time-consuming and bureaucratic, the danger of disheartening contibutors and making them stop contributing after the first few tries would also be smaller. Not everyone can afford to focus so much on this project as you can, i.e. if PR reviews require many iterations, you only get one-time contributors. That does not scale well. People who contribute more often also tend to learn and improve the quality of contributions over time. For yourself, many iterations of reviewing, discussing and re-reviewing is also wasteful, because each iteration requires a context switch from what you did before and what you want to do next. You lose focus. It would be better to get a PR off the table quickly, actively helping to finish it. When it is merged, it is off the table, does not dangle around for weeks or months, having to be rebased often or ending with an ugly merge. You can forget about it and focus on your next piece of work. The ratio of touch time vs. cycle time for each given piece of work should be as small as possible, everything else is waste. Can you afford waste, given your limited resources? P.S.: I know that reading this also costs some of your precious time. You do not need to reply at all. Just read it and think about it. It is not important whether I am right or wrong, whether my idea is good or bad. It is just an idea, and you decide if you want to forget about it or implement (part of) it. I am saying all this with the utmost respect to you, dear Tibor. was (Author: kriegaex): [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback
[jira] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521 ] Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/8/22 11:26 AM: [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators, e.g. by managing contributions in a different, more collaborative and less tiresome way, maximising the work *not* done by yourself and accepting contributions, even if it means that you might have to do some more polishing. That would still be quicker than micro-managing contributors until they changed every detail the way you would have implemented it yourself. You would get more work done per time unit like that. If PRs would be less time-consuming and bureaucratic, the danger of disheartening contibutors and making them stop contributing after the first few tries would also be smaller. Not everyone can afford to focus so much on this project as you can, i.e. if PR reviews require many iterations, you only get one-time contributors. That does not scale well. People who contribute more often also tend to learn and improve the quality of contributions over time. For yourself, many iterations of reviewing, discussing and re-reviewing is also wasteful, because each iteration requires a context switch from what you did before and what you want to do next. You lose focus. It would be better to get a PR off the table quickly, actively helping to finish it. When it is merged, it is off the table, does not dangle around for weeks or months, having to be rebased often or ending with an ugly merge. You can forget about it and focus on your next piece of work. The ratio of touch time vs. cycle time for each given piece of work should be as small as possible, everything else is waste. Can you afford waste, given your limited resources? was (Author: kriegaex): [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release
[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=17519524#comment-17519524
]
Michael Osipov commented on MRESOLVER-62:
-
[~wecai], is this somehow affected, solved by your tickets?
> 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] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521 ] Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/8/22 11:24 AM: [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. *I am simply assuming that your decision to keep it out of M6 was correct,* because you know the code base better than anything else currently active in this project. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators, e.g. by managing contributions in a different, more collaborative and less tiresome way, maximising the work *not* done by yourself and accepting contributions, even if it means that you might have to do some more polishing. That would still be quicker than micro-managing contributors until they changed every detail the way you would have implemented it yourself. You would get more work done per time unit like that. If PRs would be less time-consuming and bureaucratic, the danger of disheartening contibutors and making them stop contributing after the first few tries would also be smaller. Not everyone can afford to focus so much on this project as you can, i.e. if PR reviews require many iterations, you only get one-time contributors. That does not scale well. People who contribute more often also tend to learn and improve the quality of contributions over time. For yourself, many iterations of reviewing, discussing and re-reviewing is also wasteful, because each iteration requires a context switch from what you did before and what you want to do next. You lose focus. It would be better to get a PR off the table quickly, actively helping to finish it. When it is merged, it is off the table, does not dangle around for weeks or months, having to be rebased often or ending with an ugly merge. You can forget about it and focus on your next piece of work. The ration of touch time vs. cycle time for each given piece of work should be as small as possible, everything else is waste. Can you afford waste, given your limited resources? was (Author: kriegaex): [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. I am simply assuming that your decision to keep it out of M6 was correct. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback,
[GitHub] [maven-integration-testing] michael-o commented on a diff in pull request #149: Skip mng7045 DropUselessAndOutdatedCdiApiTest on JDK 1.7
michael-o commented on code in PR #149:
URL:
https://github.com/apache/maven-integration-testing/pull/149#discussion_r846013508
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7045DropUselessAndOutdatedCdiApiTest.java:
##
@@ -38,6 +38,9 @@ public MavenITmng7045DropUselessAndOutdatedCdiApiTest()
public void testShouldNotLeakCdiApi()
throws IOException, VerificationException
{
+// in test groovy 4.x is used which require jdk 1.8, so simply skip it
for older jdk
Review Comment:
in test Groovy 4.x is used which requires JDK 1.8, so simply skip it for
older JDKs
--
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] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[ https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521 ] Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/8/22 11:23 AM: [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. I am simply assuming that your decision to keep it out of M6 was correct. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators, e.g. by managing contributions in a different, more collaborative and less tiresome way, maximising the work *not* done by yourself and accepting contributions, even if it means that you might have to do some more polishing. That would still be quicker than micro-managing contributors until they changed every detail the way you would have implemented it yourself. You would get more work done per time unit like that. If PRs would be less time-consuming and bureaucratic, the danger of disheartening contibutors and making them stop contributing after the first few tries would also be smaller. Not everyone can afford to focus so much on this project as you can, i.e. if PR reviews require many iterations, you only get one-time contributors. That does not scale well. People who contribute more often also tend to learn and improve the quality of contributions over time. For yourself, many iterations of reviewing, discussing and re-reviewing is also wasteful, because each iteration requires a context switch from what you did before and what you want to do next. You lose focus. It would be better to get a PR off the table quickly, actively helping to finish it. When it is merged, it is off the table, does not dangle around for weeks or months, having to be rebased often or ending with an ugly merge. You can forget about it and focus on your next piece of work. The ration of touch time vs. cycle time for each given piece of work should be as small as possible, everything else is waste. Can you afford waste, given your limited resources? was (Author: kriegaex): [~tibordigana], I did *not* say the issue has anything to do with long release cycles. I said that due to those long cycles, chances are that a release fixing this issue is still far away, because it did not get in before the M6 cut-off date. My statement does not say anything about your work load - I see you fixed 111 issues for M6, which is impressive - or how high a priority this issue has for you. I simply expressed my sympathy and understanding for another person who tried to get it into M6, because I was in the same situation of having to wait long for a release with some of my own Surefire issues. Of course, you do not want to make a long-awaited milestone release unstable at the last minute by introducing an unstable fix. We all appreciate your diligence and quality focus as a Surefire maintainer. Having said that, smaller feedback cycles and more frequent releases would still be good. If a milestone takes almost two years to finish, even if (and also because) you are only one person, it is simply too big. You work as fast and high-quality as you can, no doubt about that. Therefore, you can do at least two things (maybe even both at the same time): * Make your milestones smaller. "Release early, release often", the good old Linux principle. You can benefit from more frequent user feedback, amplifying your learning process for the next release and simultaneously providing business value to users in smaller increments. Win-win. * Involve more collaborators,
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519521#comment-17519521
]
Alexander Kriegisch commented on SUREFIRE-2004:
---
[~tibordigana], I did *not* say the issue has anything to do with long release
cycles. I said that due to those long cycles, chances are that a release fixing
this issue is still far away, because it did not get in before the M6 cut-off
date. My statement does not say anything about your work load - I see you fixed
111 issues for M6, which is impressive - or how high a priority this issue has
for you. I simply expressed my sympathy and understanding for another person
who tried to get it into M6, because I was in the same situation of having to
wait long for a release with some of my own Surefire issues.
Of course, you do not want to make a long-awaited milestone release unstable at
the last minute by introducing an unstable fix. We all appreciate your
diligence and quality focus as a Surefire maintainer. Having said that, smaller
feedback cycles and more frequent releases would still be good. If a milestone
takes almost two years to finish, even if (and also because) you are only one
person, it is simply too big. You work as fast and high-quality as you can, no
doubt about that. Therefore, you can do at least two things (maybe even both at
the same time):
* Make your milestones smaller. "Release early, release often", the good old
Linux principle. You can benefit from more frequent user feedback, amplifying
your learning process for the next release and simultaneously providing
business value to users in smaller increments. Win-win.
* Involve more collaborators, e.g. by managing contributions in a different,
more collaborative and less tiresome way, maximising the work *not* done by
yourself and accepting contributions, even if it means that you might have to
do some more polishing. That would still be quicker than micro-managing
contributors until they changed every detail the way you would have implemented
it yourself. You would get more work done per time unit like that. If PRs would
be less time-consuming and bureaucratic, the danger of disheartening
contibutors and making them stop contributing after the first few tries would
also be smaller. Not everyone can afford to focus so much on this project as
you can, i.e. if PR reviews require many iterations, you only get one-time
contributors. That does not scale well. People who contribute more often also
tend to learn and improve the quality of contributions over time. For yourself,
many iterations of reviewing, discussing and re-reviewing is also wasteful,
because each iteration requires a context switch from what you did before and
what you want to do next. You lose focus. It would be better to get a PR off
the table quickly, actively helping to finish it. When it is merged, it is off
the table, does not dangle around for weeks or months, having to be rebased
often or ending with an ugly merge. You can forget about it and focus on your
next piece of work. The ration of touch time vs. cycle time for each given
piece of work should be as small as possible, everything else is waste. Can you
afford waste, given your limited resources?
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML
[jira] [Commented] (MRESOLVER-248) Make DF and BF collector implementations coexist
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519519#comment-17519519
]
Hudson commented on MRESOLVER-248:
--
Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #17
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/17/
> Make DF and BF collector implementations coexist
>
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MRESOLVER-248) Make DF and BF collector implementations coexist
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MRESOLVER-248.
-
> Make DF and BF collector implementations coexist
>
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (MRESOLVER-248) Make DF and BF collector implementations coexist
[
https://issues.apache.org/jira/browse/MRESOLVER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák resolved MRESOLVER-248.
---
Resolution: Fixed
> Make DF and BF collector implementations coexist
>
>
> Key: MRESOLVER-248
> URL: https://issues.apache.org/jira/browse/MRESOLVER-248
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.0
>
>
> There is ongoing work to fundamentally change {{DependencyCollector}}
> implementation in resolver.
> Resolver was from beginning building dependency graph by doing "depth first"
> (df) approach, and was downloading POMs sequentially during collection.
> With work happing under MRESOLVER-240, MRESOLVER-247 and MRESOLVER-7,
> collector is altered: is doing now "breadth first" (bf), implements
> skip-reconcile and will have parallel POM download implemented, and maybe
> even more (like inter collection cache?).
> Still, IMHO letting both (original "df" and new "bf") coexists is technically
> simple, and would allow us not only simpler comparison of the performance of
> the two, but there is a possibility that there will be no "one size fit all"
> solution, so having both knives in drawer is just a win-win. Also, this way
> we do have a "baseline" to compare with easily: the "df" (original) collector
> vs "bf" collector.
> Ultimately, we MAY prove superiority of one over another, essentially leaving
> only one collector implementation, as in that case this issue (and the
> "coexistence indirection") should be just removed, and not enlist it in
> release notes of upcoming 1.8.0 version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-resolver] cstamas merged pull request #161: [MRESOLVER-248] Make DF and BF collector implementations coexist
cstamas merged PR #161: URL: https://github.com/apache/maven-resolver/pull/161 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161: URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845968926 ## maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollectorTest.java: ## @@ -111,7 +111,7 @@ public void setup() public void setupCollector( boolean useSkip ) Review Comment: fixed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845947122
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/df/DfDependencyCollector.java:
##
@@ -246,9 +246,12 @@ public CollectResult collectDependencies(
RepositorySystemSession session, Colle
}
long time3 = System.nanoTime();
-stats.put( "DefaultDependencyCollector.collectTime", time2 - time1 );
-stats.put( "DefaultDependencyCollector.transformTime", time3 - time2 );
-logger.debug( "Dependency collection stats {}", stats );
+if ( logger.isDebugEnabled() )
+{
+stats.put( "BfDependencyCollector.collectTime", time2 - time1 );
+stats.put( "BfDependencyCollector.transformTime", time3 - time2 );
Review Comment:
Yes, you can easily enable with SLF4J Simple, if necessary
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845945218
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/df/DfDependencyCollector.java:
##
@@ -246,9 +246,12 @@ public CollectResult collectDependencies(
RepositorySystemSession session, Colle
}
long time3 = System.nanoTime();
-stats.put( "DefaultDependencyCollector.collectTime", time2 - time1 );
-stats.put( "DefaultDependencyCollector.transformTime", time3 - time2 );
-logger.debug( "Dependency collection stats {}", stats );
+if ( logger.isDebugEnabled() )
+{
+stats.put( "BfDependencyCollector.collectTime", time2 - time1 );
+stats.put( "BfDependencyCollector.transformTime", time3 - time2 );
Review Comment:
am unsure does Maven uses "standard" layout w/ classes as log names... is
it? I'd just don't bother :smile:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845945218
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/df/DfDependencyCollector.java:
##
@@ -246,9 +246,12 @@ public CollectResult collectDependencies(
RepositorySystemSession session, Colle
}
long time3 = System.nanoTime();
-stats.put( "DefaultDependencyCollector.collectTime", time2 - time1 );
-stats.put( "DefaultDependencyCollector.transformTime", time3 - time2 );
-logger.debug( "Dependency collection stats {}", stats );
+if ( logger.isDebugEnabled() )
+{
+stats.put( "BfDependencyCollector.collectTime", time2 - time1 );
+stats.put( "BfDependencyCollector.transformTime", time3 - time2 );
Review Comment:
am unsure does Maven uses "standard" layout w/ classes... is it? I'd just
don't bother :smile:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845943773
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/df/DfDependencyCollector.java:
##
@@ -246,9 +246,12 @@ public CollectResult collectDependencies(
RepositorySystemSession session, Colle
}
long time3 = System.nanoTime();
-stats.put( "DefaultDependencyCollector.collectTime", time2 - time1 );
-stats.put( "DefaultDependencyCollector.transformTime", time3 - time2 );
-logger.debug( "Dependency collection stats {}", stats );
+if ( logger.isDebugEnabled() )
+{
+stats.put( "BfDependencyCollector.collectTime", time2 - time1 );
+stats.put( "BfDependencyCollector.transformTime", time3 - time2 );
Review Comment:
Stupid question: If you already have the logger class name in the ouput, if
necessary, why print it again here?
##
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollectorTest.java:
##
@@ -111,7 +111,7 @@ public void setup()
public void setupCollector( boolean useSkip )
Review Comment:
`useSkip` => `useSkipper`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on code in PR #161: URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845939599 ## maven-resolver-impl/src/main/java/org/eclipse/aether/impl/guice/AetherModule.java: ## @@ -132,8 +135,14 @@ protected void configure() .to( DefaultRepositorySystem.class ).in( Singleton.class ); bind( ArtifactResolver.class ) // .to( DefaultArtifactResolver.class ).in( Singleton.class ); + bind( DependencyCollector.class ) // .to( DefaultDependencyCollector.class ).in( Singleton.class ); +bind( DependencyCollectorDelegate.class ).annotatedWith( Names.named( BfDependencyCollector.NAME ) ) Review Comment: Makes sense, -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
michael-o commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845939991
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/df/DfDependencyCollector.java:
##
@@ -0,0 +1,866 @@
+package org.eclipse.aether.internal.impl.collect.df;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import static java.util.Objects.requireNonNull;
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import org.eclipse.aether.DefaultRepositorySystemSession;
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.artifact.ArtifactProperties;
+import org.eclipse.aether.collection.CollectRequest;
+import org.eclipse.aether.collection.CollectResult;
+import org.eclipse.aether.collection.DependencyCollectionException;
+import org.eclipse.aether.collection.DependencyGraphTransformer;
+import org.eclipse.aether.collection.DependencyManagement;
+import org.eclipse.aether.collection.DependencyManager;
+import org.eclipse.aether.collection.DependencySelector;
+import org.eclipse.aether.collection.DependencyTraverser;
+import org.eclipse.aether.collection.VersionFilter;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.graph.Exclusion;
+import org.eclipse.aether.impl.ArtifactDescriptorReader;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+import org.eclipse.aether.impl.VersionRangeResolver;
+import org.eclipse.aether.internal.impl.collect.CachingArtifactTypeRegistry;
+import org.eclipse.aether.internal.impl.collect.DataPool;
+import
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollectionContext;
+import org.eclipse.aether.internal.impl.collect.DefaultDependencyCycle;
+import
org.eclipse.aether.internal.impl.collect.DefaultDependencyGraphTransformationContext;
+import org.eclipse.aether.internal.impl.collect.DefaultVersionFilterContext;
+import org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate;
+import org.eclipse.aether.repository.ArtifactRepository;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.resolution.ArtifactDescriptorException;
+import org.eclipse.aether.resolution.ArtifactDescriptorRequest;
+import org.eclipse.aether.resolution.ArtifactDescriptorResult;
+import org.eclipse.aether.resolution.VersionRangeRequest;
+import org.eclipse.aether.resolution.VersionRangeResolutionException;
+import org.eclipse.aether.resolution.VersionRangeResult;
+import org.eclipse.aether.spi.locator.Service;
+import org.eclipse.aether.util.ConfigUtils;
+import org.eclipse.aether.util.graph.manager.DependencyManagerUtils;
+import org.eclipse.aether.util.graph.transformer.TransformationContextKeys;
+import org.eclipse.aether.version.Version;
+
+/**
+ * Depth-first {@link org.eclipse.aether.impl.DependencyCollector} (the
"original" default). Originally
+ * this class was located a package higher (as "default" implementation).
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named( DfDependencyCollector.NAME )
+public class DfDependencyCollector
+extends DependencyCollectorDelegate implements Service
+{
+public static final String NAME = "df";
+
+public DfDependencyCollector()
+{
+// enables default constructor
+}
+
+@Inject
+DfDependencyCollector( RemoteRepositoryManager remoteRepositoryManager,
+ ArtifactDescriptorReader artifactDescriptorReader,
+ VersionRangeResolver versionRangeResolver )
+{
+super( remoteRepositoryManager, artifactDescriptorReader,
versionRangeResolver );
+}
+
+@SuppressWarnings( "checkstyle:methodlength" )
+public CollectResult collectDependencies(
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845930087
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/DependencyResolutionSkipper.java:
##
@@ -0,0 +1,359 @@
+package org.eclipse.aether.internal.impl.collect.bf;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.util.artifact.ArtifactIdUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.util.HashMap;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * A skipper that determines whether to skip resolving given node during the
dependency collection.
+ * Internal helper for {@link BfDependencyCollector}.
+ *
+ * @since 1.8.0
+ */
+abstract class DependencyResolutionSkipper
+{
+/**
+ * Check whether the resolution of current node can be skipped before
resolving.
+ *
+ * @param nodeCurrent node
+ * @param parents All parent nodes of current node
+ *
+ * @return {@code true} if the node can be skipped for resolution, {@code
false} if resolution required.
+ */
+abstract boolean skipResolution( DependencyNode node, List
parents );
+
+/**
+ * Cache the resolution result when a node is resolved by @See
DependencyCollector after resolution.
Review Comment:
fixed
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -0,0 +1,893 @@
+package org.eclipse.aether.internal.impl.collect.bf;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Queue;
+
+import org.eclipse.aether.DefaultRepositorySystemSession;
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.artifact.ArtifactProperties;
+import org.eclipse.aether.collection.CollectRequest;
+import org.eclipse.aether.collection.CollectResult;
+import org.eclipse.aether.collection.DependencyCollectionException;
+import org.eclipse.aether.collection.DependencyGraphTransformer;
+import org.eclipse.aether.collection.DependencyManagement;
+import org.eclipse.aether.collection.DependencyManager;
+import org.eclipse.aether.collection.DependencySelector;
+import org.eclipse.aether.collection.DependencyTraverser;
+import org.eclipse.aether.collection.VersionFilter;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.graph.Exclusion;
+import org.eclipse.aether.impl.ArtifactDescriptorReader;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+import org.eclipse.aether.impl.VersionRangeResolver;
+import org.eclipse.aether.internal.impl.collect.CachingArtifactTypeRegistry;
+import
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #161: [MRESOLVER-248] Make BF and DF collectors coexists
cstamas commented on code in PR #161:
URL: https://github.com/apache/maven-resolver/pull/161#discussion_r845930430
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java:
##
@@ -0,0 +1,893 @@
+package org.eclipse.aether.internal.impl.collect.bf;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Queue;
+
+import org.eclipse.aether.DefaultRepositorySystemSession;
+import org.eclipse.aether.RepositoryException;
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.RequestTrace;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.artifact.ArtifactProperties;
+import org.eclipse.aether.collection.CollectRequest;
+import org.eclipse.aether.collection.CollectResult;
+import org.eclipse.aether.collection.DependencyCollectionException;
+import org.eclipse.aether.collection.DependencyGraphTransformer;
+import org.eclipse.aether.collection.DependencyManagement;
+import org.eclipse.aether.collection.DependencyManager;
+import org.eclipse.aether.collection.DependencySelector;
+import org.eclipse.aether.collection.DependencyTraverser;
+import org.eclipse.aether.collection.VersionFilter;
+import org.eclipse.aether.graph.DefaultDependencyNode;
+import org.eclipse.aether.graph.Dependency;
+import org.eclipse.aether.graph.DependencyNode;
+import org.eclipse.aether.graph.Exclusion;
+import org.eclipse.aether.impl.ArtifactDescriptorReader;
+import org.eclipse.aether.impl.RemoteRepositoryManager;
+import org.eclipse.aether.impl.VersionRangeResolver;
+import org.eclipse.aether.internal.impl.collect.CachingArtifactTypeRegistry;
+import org.eclipse.aether.internal.impl.collect.DataPool;
+import
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollectionContext;
+import org.eclipse.aether.internal.impl.collect.DefaultDependencyCycle;
+import
org.eclipse.aether.internal.impl.collect.DefaultDependencyGraphTransformationContext;
+import org.eclipse.aether.internal.impl.collect.DefaultVersionFilterContext;
+import org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate;
+import org.eclipse.aether.repository.ArtifactRepository;
+import org.eclipse.aether.repository.RemoteRepository;
+import org.eclipse.aether.resolution.ArtifactDescriptorException;
+import org.eclipse.aether.resolution.ArtifactDescriptorRequest;
+import org.eclipse.aether.resolution.ArtifactDescriptorResult;
+import org.eclipse.aether.resolution.VersionRangeRequest;
+import org.eclipse.aether.resolution.VersionRangeResolutionException;
+import org.eclipse.aether.resolution.VersionRangeResult;
+import org.eclipse.aether.spi.locator.Service;
+import org.eclipse.aether.util.ConfigUtils;
+import org.eclipse.aether.util.graph.manager.DependencyManagerUtils;
+import org.eclipse.aether.util.graph.transformer.TransformationContextKeys;
+import org.eclipse.aether.version.Version;
+
+import static java.util.Objects.requireNonNull;
+import static
org.eclipse.aether.internal.impl.collect.DefaultDependencyCycle.find;
+
+/**
+ * Breadth-first {@link org.eclipse.aether.impl.DependencyCollector}
+ *
+ * @since 1.8.0
+ */
+@Singleton
+@Named( BfDependencyCollector.NAME )
+public class BfDependencyCollector
+extends DependencyCollectorDelegate implements Service
+{
+public static final String NAME = "bf";
+
+/**
+ * The key in the repository session's {@link
RepositorySystemSession#getConfigProperties()
+ * configuration properties} used to store a {@link Boolean} flag
controlling the resolver's skip mode.
+ *
+ * @since 1.8.0
+ */
+public static final String CONFIG_PROP_USE_SKIP =
"aether.dependencyCollector.bf.useSkip";
Review Comment:
fixed
--
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
