[GitHub] [maven-doxia-converter] dependabot[bot] opened a new pull request, #44: Bump slf4j-api from 1.7.36 to 2.0.7
dependabot[bot] opened a new pull request, #44: URL: https://github.com/apache/maven-doxia-converter/pull/44 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.7. Commits https://github.com/qos-ch/slf4j/commit/d6a21ae68f8a996bc24526f82ec46907e6688bc0";>d6a21ae update javadoc plugin to version 3.0.5 https://github.com/qos-ch/slf4j/commit/13950e51a62893eae6a5f6d9f842fe5554b7d4f4";>13950e5 prepare release 2.0.7 https://github.com/qos-ch/slf4j/commit/122e0c18dd59c1c7ef425e89e6097c07ee2358b9";>122e0c1 add LICENSE.txt files to all modules, rename LICENSE as LICENSE.txt when appr... https://github.com/qos-ch/slf4j/commit/2a8ca99cafe8a20c2dc57ed7297ec68c574b0b94";>2a8ca99 add license file to jar https://github.com/qos-ch/slf4j/commit/b363bb31ed08d3ad9761ccdca5e51bb2327c3287";>b363bb3 SLF4J-579: Export client packages of slf4j-api in version 1 https://github.com/qos-ch/slf4j/commit/2235d3c69829caf19e38ea980a86042cc3ffd1f3";>2235d3c Fully automate OSGi metadata creation and fix brocken OSGi-metadata in slf4j-... https://github.com/qos-ch/slf4j/commit/a5540ad51066b4b15132fdf27ead630519541d35";>a5540ad setup-java v3 https://github.com/qos-ch/slf4j/commit/1ed084cbc061f0bcbc9250867771550684be25fa";>1ed084c add missing distribution instruction to github action https://github.com/qos-ch/slf4j/commit/b2cb0174225d1163730a209a6a433068fa281903";>b2cb017 update github action versions https://github.com/qos-ch/slf4j/commit/fa6721a53eb4b2d13491400908f9ca76c7997300";>fa6721a add JDK 19 to CI build Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.7";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-indexer] dependabot[bot] opened a new pull request, #306: Bump modernizer-maven-plugin from 2.5.0 to 2.6.0
dependabot[bot] opened a new pull request, #306: URL: https://github.com/apache/maven-indexer/pull/306 Bumps [modernizer-maven-plugin](https://github.com/gaul/modernizer-maven-plugin) from 2.5.0 to 2.6.0. Release notes Sourced from https://github.com/gaul/modernizer-maven-plugin/releases";>modernizer-maven-plugin's releases. Modernizer Maven Plugin 2.6.0 Add violations for Java 17, 18, and 19 https://redirect.github.com/gaul/modernizer-maven-plugin/issues/115";>#115 Recommend Optional::orElseThrow instead of get https://redirect.github.com/gaul/modernizer-maven-plugin/issues/147";>#147 Remove usage of plexus StringUtils for compatibility with newer Maven https://redirect.github.com/gaul/modernizer-maven-plugin/issues/170";>#170 Upgrade to ASM 9.4 for Java 20 compatibility https://redirect.github.com/gaul/modernizer-maven-plugin/issues/154";>#154 Thanks https://github.com/Harmelodic";>@Harmelodic, https://github.com/krzyk";>@krzyk, and https://github.com/mattnelson";>@mattnelson sending pull requests to improve Modernizer! Commits https://github.com/gaul/modernizer-maven-plugin/commit/0eaf84f416a89b8c2f6328e891929f8a3590a78a";>0eaf84f modernizer-maven-plugin 2.6.0 release https://github.com/gaul/modernizer-maven-plugin/commit/6fd3a5d92e1f52649bbacd7648c93dc7223fdc34";>6fd3a5d Upgrade to Groovy 4.0.10 https://github.com/gaul/modernizer-maven-plugin/commit/92c5c8f231bc46e3696336358afea8eb4046c8c2";>92c5c8f Bump maven-invoker-plugin from 3.2.1 to 3.5.0 https://github.com/gaul/modernizer-maven-plugin/commit/b33c2b0ff87f41ea580d74a2b9c645c791e369c0";>b33c2b0 Bump groovy-all from 3.0.2 to 3.0.15 https://github.com/gaul/modernizer-maven-plugin/commit/ddc160d8104c0d21dae07e65ccb7e11d439b3d31";>ddc160d Bump maven-compiler-plugin from 3.10.1 to 3.11.0 https://github.com/gaul/modernizer-maven-plugin/commit/fc45915c42b37128f7c21fe8662019a8ac8b1cb8";>fc45915 Remove usage of plexus StringUtils https://github.com/gaul/modernizer-maven-plugin/commit/e653d64e12271cfec9793cd48cca8b155afa21b9";>e653d64 Bump modulemaker-maven-plugin from 1.7 to 1.9 https://github.com/gaul/modernizer-maven-plugin/commit/17bfd824dc5cd1b805a022c2b8a6673f17eea2ed";>17bfd82 Bump maven-source-plugin from 3.0.1 to 3.2.1 https://github.com/gaul/modernizer-maven-plugin/commit/3414e790828e18478a993b5afbea0775a3c1790d";>3414e79 Bump maven-deploy-plugin from 2.8.2 to 3.0.0 https://github.com/gaul/modernizer-maven-plugin/commit/3b607f038cf62ec1add42d78a3a1363e3d0e7556";>3b607f0 Bump maven-jar-plugin from 3.2.0 to 3.3.0 Additional commits viewable in https://github.com/gaul/modernizer-maven-plugin/compare/modernizer-maven-plugin-2.5.0...modernizer-maven-plugin-2.6.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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...@
[GitHub] [maven-doxia-converter] dependabot[bot] opened a new pull request, #43: Bump slf4j-simple from 1.7.36 to 2.0.7
dependabot[bot] opened a new pull request, #43: URL: https://github.com/apache/maven-doxia-converter/pull/43 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.36 to 2.0.7. Commits https://github.com/qos-ch/slf4j/commit/d6a21ae68f8a996bc24526f82ec46907e6688bc0";>d6a21ae update javadoc plugin to version 3.0.5 https://github.com/qos-ch/slf4j/commit/13950e51a62893eae6a5f6d9f842fe5554b7d4f4";>13950e5 prepare release 2.0.7 https://github.com/qos-ch/slf4j/commit/122e0c18dd59c1c7ef425e89e6097c07ee2358b9";>122e0c1 add LICENSE.txt files to all modules, rename LICENSE as LICENSE.txt when appr... https://github.com/qos-ch/slf4j/commit/2a8ca99cafe8a20c2dc57ed7297ec68c574b0b94";>2a8ca99 add license file to jar https://github.com/qos-ch/slf4j/commit/b363bb31ed08d3ad9761ccdca5e51bb2327c3287";>b363bb3 SLF4J-579: Export client packages of slf4j-api in version 1 https://github.com/qos-ch/slf4j/commit/2235d3c69829caf19e38ea980a86042cc3ffd1f3";>2235d3c Fully automate OSGi metadata creation and fix brocken OSGi-metadata in slf4j-... https://github.com/qos-ch/slf4j/commit/a5540ad51066b4b15132fdf27ead630519541d35";>a5540ad setup-java v3 https://github.com/qos-ch/slf4j/commit/1ed084cbc061f0bcbc9250867771550684be25fa";>1ed084c add missing distribution instruction to github action https://github.com/qos-ch/slf4j/commit/b2cb0174225d1163730a209a6a433068fa281903";>b2cb017 update github action versions https://github.com/qos-ch/slf4j/commit/fa6721a53eb4b2d13491400908f9ca76c7997300";>fa6721a add JDK 19 to CI build Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.36...v_2.0.7";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-indexer] dependabot[bot] opened a new pull request, #305: Bump spring-core from 5.3.25 to 5.3.26 in /indexer-examples/indexer-examples-spring
dependabot[bot] opened a new pull request, #305: URL: https://github.com/apache/maven-indexer/pull/305 Bumps [spring-core](https://github.com/spring-projects/spring-framework) from 5.3.25 to 5.3.26. Release notes Sourced from https://github.com/spring-projects/spring-framework/releases";>spring-core's releases. v5.3.26 :star: New Features Improve diagnostics in SpEL for matches operator https://redirect.github.com/spring-projects/spring-framework/issues/30145";>#30145 Improve diagnostics in SpEL for repeated text https://redirect.github.com/spring-projects/spring-framework/issues/30143";>#30143 Increase scope of regex pattern cache for the SpEL matches operator https://redirect.github.com/spring-projects/spring-framework/issues/30141";>#30141 Minor updates in HandlerMappingIntrospector https://redirect.github.com/spring-projects/spring-framework/issues/30128";>#30128 Allow SnakeYaml 2.0 runtime compatibility https://redirect.github.com/spring-projects/spring-framework/issues/30097";>#30097 Add missing @Nullable annotations to LogMessage.format methods https://redirect.github.com/spring-projects/spring-framework/issues/30009";>#30009 ASM upgrade for JDK 20/21 support https://redirect.github.com/spring-projects/spring-framework/issues/29966";>#29966 Allow MockRest to match header/queryParam value list with one Matcher https://redirect.github.com/spring-projects/spring-framework/issues/29964";>#29964 Add MockMvc.multipart() Kotlin extensions with HttpMethod https://redirect.github.com/spring-projects/spring-framework/issues/29941";>#29941 Release R2DBC connection when cleanup fails in transaction https://redirect.github.com/spring-projects/spring-framework/issues/29925";>#29925 org.springframework.web.context.ContextLoader should lazily load ContextLoader.properties https://redirect.github.com/spring-projects/spring-framework/issues/29909";>#29909 Improve generated default name for @JmsListener subscription https://redirect.github.com/spring-projects/spring-framework/issues/29902";>#29902 Include all Hibernate query methods in SharedEntityManagerCreator's queryTerminatingMethods set https://redirect.github.com/spring-projects/spring-framework/issues/29888";>#29888 SQL supplier in R2DBC DatabaseClient is eagerly invoked https://redirect.github.com/spring-projects/spring-framework/issues/29887";>#29887 Spring Framework 5.3.x is incompatible with Jetty 10 (Client) https://redirect.github.com/spring-projects/spring-framework/issues/29867";>#29867 Possible infinite forward loop with MockMvcWebConnection https://redirect.github.com/spring-projects/spring-framework/issues/29866";>#29866 Refine Jackson2ObjectMapperBuilder#configureFeature exception handling https://redirect.github.com/spring-projects/spring-framework/issues/29860";>#29860 Fix R2dbcTransactionManager debug log: don't log a Mono https://redirect.github.com/spring-projects/spring-framework/issues/29824";>#29824 :lady_beetle: Bug Fixes RequestedContentTypeResolver does not ignore quality factor when filtering */* media types https://redirect.github.com/spring-projects/spring-framework/issues/30121";>#30121 SpEL: cannot call methods declared in java.lang.Object on a JDK proxy https://redirect.github.com/spring-projects/spring-framework/issues/30118";>#30118 CaffeineCacheManager getCache method cause thread block https://redirect.github.com/spring-projects/spring-framework/issues/30085";>#30085 Protect JMS connection creation against prepareConnection errors https://redirect.github.com/spring-projects/spring-framework/issues/30051";>#30051 ReactorServerHttpRequest does not reflect forwarded host and port when forwarding-header-strategy=native or cloud platform detected https://redirect.github.com/spring-projects/spring-framework/issues/29974";>#29974 WebSocket stats not updated correctly when sessions cleared https://redirect.github.com/spring-projects/spring-framework/issues/29947";>#29947 Explicit target ClassLoader for interface-based proxies in MvcUriComponentsBuilder https://redirect.github.com/spring-projects/spring-framework/issues/29914";>#29914 Closing an ApplicationContext leads to Exception at ExecutorServiceAdapter https://redirect.github.com/spring-projects/spring-framework/issues/29908";>#29908 Invalid Accept header results in IllegalStateException https://redirect.github.com/spring-projects/spring-framework/issues/29836";>#29836 JettyWebSocketCreator referenced from a method is not visible from class loader with Jetty10RequestUpgradeStrategy https://redirect.github.com/spring-projects/spring-framework/issues/29256";>#29256 :notebook_with_decorative_cover: Documentation Fix minor spacings in webflux docs https://redirect.github.com/spring-projects/spring-framework/issues/30095";>#30095 @AspectJ argument name resolution algorithm is outdated in reference manual https://redirect.github.co
[GitHub] [maven-mvnd] gzm55 opened a new pull request, #827: native image: hardening csu for old glibc
gzm55 opened a new pull request, #827: URL: https://github.com/apache/maven-mvnd/pull/827 Workround of return-to-csu problem for old glibc, use non-initialized static variables instead of the stack ones. See workround 2 of https://i.blackhat.com/briefings/asia/2018/asia-18-Marco-return-to-csu-a-new-method-to-bypass-the-64-bit-Linux-ASLR-wp.pdf -- 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] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704377#comment-17704377
]
Delany commented on MWRAPPER-101:
-
Anyway, not the issue here. pls close
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-105) mvnd distributionURL support for mvn qualifiers
Delany created MWRAPPER-105: --- Summary: mvnd distributionURL support for mvn qualifiers Key: MWRAPPER-105 URL: https://issues.apache.org/jira/browse/MWRAPPER-105 Project: Maven Wrapper Issue Type: Bug Affects Versions: 3.2.0 Reporter: Delany The wrapper cannot determine the correct URL for mvnd's new qualified form which allows selecting the mvn version, for instance mvn wrapper:3.2.0:wrapper -Dmvnd=1.0-m6-m39 -Dtype=only-script [https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0-m6/maven-mvnd-1.0-m6-m39-bin.zip] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704373#comment-17704373
]
Michael Osipov commented on MNG-7705:
-
The first point is not correct. We did this for a reason: external sync is
required which we have introduced. For Compat and friends: we can add
additional logging and see.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDepen
[jira] [Comment Edited] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704348#comment-17704348
]
Tamas Cservenak edited comment on MNG-7705 at 3/23/23 9:39 PM:
---
Seems we missed few details:
* we had file locking (custom tailored) in TrackingFileManager (way before it
was made into component). It seemed without any reason, and we did remove it
[https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27]
* but, it turns out, we have some nice duplication in this area as well, and
surprise, with same custom file locking:
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L204]
and
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L116]
* Given we all triple-checked resolver (alone, not maven-compat), the
lastUpdated files WITHIN resolver are well protected (assuming locking is
correct). But this is a real game changer, as in a moment something within
build reaches for some compat (maven2 compatibility layer), clash may occur (as
this access happens completely outside of resolver locking)
So, this issue becomes searching the stuff in build that may trigger code in
maven-compat.
was (Author: cstamas):
Seems we missed few details:
* we had file locking (custom tailored) in TrackingFileManager (way before it
was made into component). It seemed without any reason, and we did remote it
[https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27]
* but, it turns out, we have some nice duplication in this area as well:
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L204]
and
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L116]
* Given we all triple-checked resolver (alone, not maven-compat), the
lastUpdated files WITHIN resolver are well protected (assuming locking is
correct).
So, this issue becomes searching the stuff in build that may trigger code in
maven-compat.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvide
[jira] [Commented] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704367#comment-17704367 ] Tamas Cservenak commented on MPOM-344: -- Ongoing PR is here, that should fix several issues [https://github.com/apache/maven-remote-resources-plugin/pull/26] But, there is a related discussion here: https://lists.apache.org/thread/bhtozf6w2nknvfzbfc1jb76fr6rqpkbx > Update maven-remote-resources-plugin to 3.1.0 > - > > Key: MPOM-344 > URL: https://issues.apache.org/jira/browse/MPOM-344 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-29 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MENFORCER-474) Filtering dependency tree by scope
[
https://issues.apache.org/jira/browse/MENFORCER-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MENFORCER-474.
-
Resolution: Fixed
> Filtering dependency tree by scope
> --
>
> Key: MENFORCER-474
> URL: https://issues.apache.org/jira/browse/MENFORCER-474
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.3.0
>
>
> In current implementation we change default {{dependencySelector}}
> for {{repositorySystemSession}}
> It has an impacts for whole dependency tree resolving.
> We should filter dependencies scopes on project level, for transitive
> dependency tree we should not change defaults selectors.
>
> It is cause of issues as:
> - MENFORCER-467 - no scope filtering - everything is resolved in every scope
> - MENFORCER-466
> - MENFORCER-470 - when we allow changing scope we will have impacts on whole
> tree
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #256: [MENFORCER-474] Filter dependency by scope on project level
slawekjaranowski merged PR #256: URL: https://github.com/apache/maven-enforcer/pull/256 -- 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-345) Conflict resolution in verbose mode is sensitive to version ordering
[
https://issues.apache.org/jira/browse/MRESOLVER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704362#comment-17704362
]
ASF GitHub Bot commented on MRESOLVER-345:
--
slawekjaranowski commented on code in PR #271:
URL: https://github.com/apache/maven-resolver/pull/271#discussion_r1146862457
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/DependencyGraphDumper.java:
##
@@ -31,25 +31,27 @@
import org.eclipse.aether.util.graph.manager.DependencyManagerUtils;
import org.eclipse.aether.util.graph.transformer.ConflictResolver;
+import static java.util.Objects.requireNonNull;
+
/**
- * A dependency visitor that dumps the graph to the console.
+ * A dependency visitor that dumps the graph to any {@link Consumer}.
Meant for diagnostic and testing, as
+ * it may output the graph to standard output, error or even some logging
interface.
+ *
+ * @since 1.9.8
*/
-public class ConsoleDependencyGraphDumper implements DependencyVisitor {
+public class DependencyGraphDumper implements DependencyVisitor {
Review Comment:
👍 - we have similar implementation in many places
> Conflict resolution in verbose mode is sensitive to version ordering
>
>
> Key: MRESOLVER-345
> URL: https://issues.apache.org/jira/browse/MRESOLVER-345
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.8
>
>
> It all started with MENFORCER-426. In short, if we have layout of
> dependencies like this below (ranges are key here), *conflict resolution in
> verbose mode* will misbehave, is sensitive on version ordering in the "dirty
> tree" (collected graph, output of DependencyCollector).
> {noformat}
> A -> B -> C[1..2]
> \--> C[1..2] {noformat}
> (explained: A depends on B and C[1..2] range, and B depends on C[1..2] as
> well)
> As when "dirty tree" is being collected by DependencyCollector (and we have
> two, old DF and new BF), the ranges are turned into series of artifacts with
> versions discovered (by VersionRangeResolver), so the input above while
> collecting A from above would yield some tree like this (in this example
> {{some-group:c:jar}} has versions 1.0 and 2.0 ):
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> This "dirty tree" is then transformed using {{ConflictResolver}} into final
> graph. Conflict resolver in "normal" mode works OK and produces stable
> outputs, that is not sensitive to ordering, this is OK.
> But, conflict resolver supports so called "verbose" mode as well, mostly used
> to perform some "analysis" on graph (like for example "dependency
> convergence" is). Conflict resolver in "verbose" mode {*}is version ordering
> sensitive{*}.
> Conflict resolver in "verbose" mode would transform that dirty tree above
> into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:1.0 [compile] (conflicts 2.0)
> \- some-group:c:jar:2.0 [compile] {noformat}
> And for analysis like "dependency convergence", this would mean *divergency
> is found* (error condition), as there are conflicts. But, if you look more
> closely on input "dirty tree", you can notice that {{b}} depends on {{c:2.0}}
> as well (as b depends on range {{{}[1,2]{}}}.
> Moreover, that dirty tree above is output of resolver standard DF collector.
> BF on the other hand, produces dirty tree like this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:c:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:1.0 [compile] {noformat}
> (the order of c dependencies are sorted descending).
> In other words, DF produces tree with versions in order as discovered
> (essentially metadata based), the BF explicitly sorts versions in descending
> order (to maximize skipper effect, but that is BF internal detail).
> Same conflict resolver in "verbose" mode transforms BF dirty tree into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> And in this case, {*}there is no divergence found{*}. Again, this is same
> input, but collected with DF and BF collectors, then applied conflict
> resolution, and once we have divergence, and once we have no divergence. The
> difference between two inputs is only the order of versions (produced from
> discovered versions that were resolved from metadata, but new BF explicitly
>
[GitHub] [maven-resolver] slawekjaranowski commented on a diff in pull request #271: [MRESOLVER-345] Conflict resolution in verbose mode is sensitive to version ordering
slawekjaranowski commented on code in PR #271:
URL: https://github.com/apache/maven-resolver/pull/271#discussion_r1146862457
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/DependencyGraphDumper.java:
##
@@ -31,25 +31,27 @@
import org.eclipse.aether.util.graph.manager.DependencyManagerUtils;
import org.eclipse.aether.util.graph.transformer.ConflictResolver;
+import static java.util.Objects.requireNonNull;
+
/**
- * A dependency visitor that dumps the graph to the console.
+ * A dependency visitor that dumps the graph to any {@link Consumer}.
Meant for diagnostic and testing, as
+ * it may output the graph to standard output, error or even some logging
interface.
+ *
+ * @since 1.9.8
*/
-public class ConsoleDependencyGraphDumper implements DependencyVisitor {
+public class DependencyGraphDumper implements DependencyVisitor {
Review Comment:
👍 - we have similar implementation in many places
--
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] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704355#comment-17704355 ] Lenny Primak commented on MPOM-344: --- Same here. This plugin is not compatible with maven 3.9.x so please bump > Update maven-remote-resources-plugin to 3.1.0 > - > > Key: MPOM-344 > URL: https://issues.apache.org/jira/browse/MPOM-344 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-29 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704354#comment-17704354
]
Slawomir Jaranowski commented on MENFORCER-426:
---
Another workaround is to exclude problematic artifacts:
In your case configuration can look like:
{code}
com.trib3:graphql
{code}
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704348#comment-17704348
]
Tamas Cservenak commented on MNG-7705:
--
Seems we missed few details:
* we had file locking (custom tailored) in TrackingFileManager (way before it
was made into component). It seemed without any reason, and we did remote it
[https://github.com/apache/maven-resolver/commit/fcb6be59c5a5855573886b09c70dab80074a1d27]
* but, it turns out, we have some nice duplication in this area as well:
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.java#L204]
and
[https://github.com/apache/maven/blob/maven-3.9.x/maven-compat/src/main/java/org/apache/maven/repository/legacy/DefaultWagonManager.java#L116]
* Given we all triple-checked resolver (alone, not maven-compat), the
lastUpdated files WITHIN resolver are well protected (assuming locking is
correct).
So, this issue becomes searching the stuff in build that may trigger code in
maven-compat.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.ma
[jira] [Comment Edited] (MNG-7744) Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
[
https://issues.apache.org/jira/browse/MNG-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704347#comment-17704347
]
Tamas Cservenak edited comment on MNG-7744 at 3/23/23 8:13 PM:
---
Thanks for confirmation! Just to recap, this is plugin issue not Maven issue:
the plugin, while uses plexus-utils classes does NOT declare it as dependency.
Maven2 was auto injecting plexus-utils into ANY plugin realm, Maven 3.x
continued doing this (for backward compatibility reasons), but Maven 3.9.x is
stopping doing this, as one of it's main goal is to nudge users toward Maven3
plugins.
was (Author: cstamas):
Thanks for confirmation! Just to recap, this is plugin issue not Maven issue:
the plugin, while uses plexus-utils classes does NOT declare it as dependency.
Maven2 was auto injecting plexus-utils into ANY plugin realm, Maven 3.x
continued doing this, but Maven 3.9.x is stopping doing this.
> Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
> -
>
> Key: MNG-7744
> URL: https://issues.apache.org/jira/browse/MNG-7744
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1
>Reporter: Gary D. Gregory
>Priority: Major
>
> The following works fine with 3.8.7:
> # git clone [https://gitbox.apache.org/repos/asf/mina-sshd.git]
> # cd mina-sshd
> # mvn -V clean install javadoc:javadoc
> {noformat}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\java\apache-maven-3.9.0
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 32.853 s
> [INFO] Finished at: 2023-03-20T09:14:04-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort (sort-imports) on project
> sshd-common: Execution sort-imports of goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort failed: A required class was
> missing while executing net.revelc.code:impsort-maven-plugin:1.6.2:sort:
> org/codehaus/plexus/util/DirectoryScanner
> [ERROR] -
> [ERROR] realm =plugin>net.revelc.code:impsort-maven-plugin:1.6.2
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/ggregory/.m2/repository/net/revelc/code/impsort-maven-plugin/1.6.2/impsort-maven-plugin-1.6.2.jar
> [ERROR] urls[1] =
> file:/C:/Users/ggregory/.m2/repository/com/github/javaparser/javaparser-core/3.22.1/javaparser-core-3.22.1.jar
> [ERROR] urls[2] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/guava/30.1.1-jre/guava-30.1.1-jre.jar
> [ERROR] urls[3] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar
> [ERROR] urls[4] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> [ERROR] urls[5] =
> file:/C:/Users/ggregory/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar
> [ERROR] urls[6] =
> file:/C:/Users/ggregory/.m2/repository/org/checkerframework/checker-qual/3.8.0/checker-qual-3.8.0.jar
> [ERROR] urls[7] =
> file:/C:/Users/ggregory/.m2/repository/com/google/errorprone/error_prone_annotations/2.5.1/error_prone_annotations-2.5.1.jar
> [ERROR] urls[8] =
> file:/C:/Users/ggregory/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm
> ClassRealm[project>org.apache.sshd:sshd:2.9.3-SNAPSHOT, parent:
> ClassRealm[maven.api, parent: null]]]
> [ERROR]
> [ERROR] -
> [ERROR] : org.codehaus.plexus.util.DirectoryScanner
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :sshd-common
> {noformat}
>
[jira] [Closed] (MNG-7744) Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
[
https://issues.apache.org/jira/browse/MNG-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-7744.
Resolution: Won't Fix
Thanks for confirmation! Just to recap, this is plugin issue not Maven issue:
the plugin, while uses plexus-utils classes does NOT declare it as dependency.
Maven2 was auto injecting plexus-utils into ANY plugin realm, Maven 3.x
continued doing this, but Maven 3.9.x is stopping doing this.
> Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
> -
>
> Key: MNG-7744
> URL: https://issues.apache.org/jira/browse/MNG-7744
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1
>Reporter: Gary D. Gregory
>Priority: Major
>
> The following works fine with 3.8.7:
> # git clone [https://gitbox.apache.org/repos/asf/mina-sshd.git]
> # cd mina-sshd
> # mvn -V clean install javadoc:javadoc
> {noformat}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\java\apache-maven-3.9.0
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 32.853 s
> [INFO] Finished at: 2023-03-20T09:14:04-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort (sort-imports) on project
> sshd-common: Execution sort-imports of goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort failed: A required class was
> missing while executing net.revelc.code:impsort-maven-plugin:1.6.2:sort:
> org/codehaus/plexus/util/DirectoryScanner
> [ERROR] -
> [ERROR] realm =plugin>net.revelc.code:impsort-maven-plugin:1.6.2
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/ggregory/.m2/repository/net/revelc/code/impsort-maven-plugin/1.6.2/impsort-maven-plugin-1.6.2.jar
> [ERROR] urls[1] =
> file:/C:/Users/ggregory/.m2/repository/com/github/javaparser/javaparser-core/3.22.1/javaparser-core-3.22.1.jar
> [ERROR] urls[2] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/guava/30.1.1-jre/guava-30.1.1-jre.jar
> [ERROR] urls[3] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar
> [ERROR] urls[4] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> [ERROR] urls[5] =
> file:/C:/Users/ggregory/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar
> [ERROR] urls[6] =
> file:/C:/Users/ggregory/.m2/repository/org/checkerframework/checker-qual/3.8.0/checker-qual-3.8.0.jar
> [ERROR] urls[7] =
> file:/C:/Users/ggregory/.m2/repository/com/google/errorprone/error_prone_annotations/2.5.1/error_prone_annotations-2.5.1.jar
> [ERROR] urls[8] =
> file:/C:/Users/ggregory/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm
> ClassRealm[project>org.apache.sshd:sshd:2.9.3-SNAPSHOT, parent:
> ClassRealm[maven.api, parent: null]]]
> [ERROR]
> [ERROR] -
> [ERROR] : org.codehaus.plexus.util.DirectoryScanner
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :sshd-common
> {noformat}
> Same problem with 3.9.1 :
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 21.064 s
> [INFO] Finished at: 2023-03-20T09:36:52-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort (sort-imports) on project
[jira] [Commented] (MCHECKSTYLE-429) Deprecation warning / incompatible with maven 3.9.x
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704345#comment-17704345
]
Michael Osipov commented on MCHECKSTYLE-429:
Recent Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0
branch as well. With the upcoming major version this will be implicitly solved.
> Deprecation warning / incompatible with maven 3.9.x
> ---
>
> Key: MCHECKSTYLE-429
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-429
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 3.2.1
>Reporter: Lenny Primak
>Priority: Major
>
> Every time checkstyle plugin is ran, the following warning occurs:
> {code:java}
> [INFO] --- checkstyle:3.2.1:checkstyle (default) @ shiro-cdi ---
> [WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it instead.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO] Starting audit...
> Audit done.
> {code}
> Looks like maven 3.9.x deprecated `localRepository` variable and the plugin
> needs to be updated to reflect this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7744) Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
[
https://issues.apache.org/jira/browse/MNG-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704341#comment-17704341
]
Gary D. Gregory commented on MNG-7744:
--
Hi [~cstamas]
Thank you for the pointer, it worked. For the curious: I committed
[https://github.com/apache/mina-sshd/commit/77fde8c47ed1502ecf2c5b24369c27884430f931]
Feel free to close this issue.
> Maven 3.9.0 and 3.9.1 break compatibility with Apache Mina SSHD build
> -
>
> Key: MNG-7744
> URL: https://issues.apache.org/jira/browse/MNG-7744
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1
>Reporter: Gary D. Gregory
>Priority: Major
>
> The following works fine with 3.8.7:
> # git clone [https://gitbox.apache.org/repos/asf/mina-sshd.git]
> # cd mina-sshd
> # mvn -V clean install javadoc:javadoc
> {noformat}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: C:\java\apache-maven-3.9.0
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 32.853 s
> [INFO] Finished at: 2023-03-20T09:14:04-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort (sort-imports) on project
> sshd-common: Execution sort-imports of goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort failed: A required class was
> missing while executing net.revelc.code:impsort-maven-plugin:1.6.2:sort:
> org/codehaus/plexus/util/DirectoryScanner
> [ERROR] -
> [ERROR] realm =plugin>net.revelc.code:impsort-maven-plugin:1.6.2
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/C:/Users/ggregory/.m2/repository/net/revelc/code/impsort-maven-plugin/1.6.2/impsort-maven-plugin-1.6.2.jar
> [ERROR] urls[1] =
> file:/C:/Users/ggregory/.m2/repository/com/github/javaparser/javaparser-core/3.22.1/javaparser-core-3.22.1.jar
> [ERROR] urls[2] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/guava/30.1.1-jre/guava-30.1.1-jre.jar
> [ERROR] urls[3] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar
> [ERROR] urls[4] =
> file:/C:/Users/ggregory/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar
> [ERROR] urls[5] =
> file:/C:/Users/ggregory/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar
> [ERROR] urls[6] =
> file:/C:/Users/ggregory/.m2/repository/org/checkerframework/checker-qual/3.8.0/checker-qual-3.8.0.jar
> [ERROR] urls[7] =
> file:/C:/Users/ggregory/.m2/repository/com/google/errorprone/error_prone_annotations/2.5.1/error_prone_annotations-2.5.1.jar
> [ERROR] urls[8] =
> file:/C:/Users/ggregory/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm
> ClassRealm[project>org.apache.sshd:sshd:2.9.3-SNAPSHOT, parent:
> ClassRealm[maven.api, parent: null]]]
> [ERROR]
> [ERROR] -
> [ERROR] : org.codehaus.plexus.util.DirectoryScanner
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :sshd-common
> {noformat}
> Same problem with 3.9.1 :
> {noformat}
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 21.064 s
> [INFO] Finished at: 2023-03-20T09:36:52-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> net.revelc.code:impsort-maven-plugin:1.6.2:sort (sort-imports) on project
> sshd-common: Execution sort-imports of goal
> net.revel
[jira] [Commented] (MCHECKSTYLE-429) Deprecation warning / incompatible with maven 3.9.x
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704340#comment-17704340
]
Tamas Cservenak commented on MCHECKSTYLE-429:
-
[~michaelo] ping. But this is deeply buried in AbstractReport or alike I think,
so huge but ongoing work is happening...
> Deprecation warning / incompatible with maven 3.9.x
> ---
>
> Key: MCHECKSTYLE-429
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-429
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 3.2.1
>Reporter: Lenny Primak
>Priority: Major
>
> Every time checkstyle plugin is ran, the following warning occurs:
> {code:java}
> [INFO] --- checkstyle:3.2.1:checkstyle (default) @ shiro-cdi ---
> [WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it instead.
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO] Starting audit...
> Audit done.
> {code}
> Looks like maven 3.9.x deprecated `localRepository` variable and the plugin
> needs to be updated to reflect this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-429) Deprecation warning / incompatible with maven 3.9.x
Lenny Primak created MCHECKSTYLE-429:
Summary: Deprecation warning / incompatible with maven 3.9.x
Key: MCHECKSTYLE-429
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-429
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:checkstyle
Affects Versions: 3.2.1
Reporter: Lenny Primak
Every time checkstyle plugin is ran, the following warning occurs:
{code:java}
[INFO] --- checkstyle:3.2.1:checkstyle (default) @ shiro-cdi ---
[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid use
of ArtifactRepository type. If you need access to local repository, switch to
'${repositorySystemSession}' expression and get LRM from it instead.
[INFO] Rendering content with org.apache.maven.skins:maven-default-skin:jar:1.3
skin.
[INFO] Starting audit...
Audit done.
{code}
Looks like maven 3.9.x deprecated `localRepository` variable and the plugin
needs to be updated to reflect this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704286#comment-17704286
]
ASF GitHub Bot commented on MNG-7038:
-
w6et commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1481644481
> JIRA issue: [[MNG-7038](https://issues.apache.org/jira/browse/MNG-7038)]
Introduce public property to point to a root directory of (multi-module) project
>
> This PR introduces two properties:
>
> * `session.topdir` / `topdir` : _the directory of the topmost project
being built, usually the current directory or the directory pointed at by the
`-f`/`--file` command line argument_. The `topdir` is similar to the
`executionRootDirectory` property available on the session, but renamed to make
it coherent with the new `rootdir` and to avoid using _root_ in its name. The
`topdir` property is computed by the CLI as the directory pointed at by the
`-f`/`--file` command line argument, or the current directory if there's no
such argument.
> * `session.rootdir` / `rootdir` : _the parent directory containing a
`.mvn` subdirectory, usually the directory containing the topmost `pom.xml` of
the project_. The `rootdir` property is roughly the same as the
`${maven.multiModuleProjectDirectory}`, but computed by the CLI. If the
`rootdir` can not be properly determined (usually because there's no `.mvn`
directory), a warning will be printed to the console.
>
> The `topdir` and `rootdir` properties are made available on the
`MavenSession` / `Session` and deprecate the `executionRootDirectory` and
`multiModuleProjectDirectory` properties. The `rootdir` should never change for
a given project and is thus made available for profile activation and model
interpolation. The goal is also to make it available as a system property
during [command line arguments
interpolation](https://github.com/apache/maven/pull/1062).
i think we can define a build.yml\json, generate build-lock.yml\json at
lifecycle process-resources，in build.yml，can load properties file，can define
any public properties with expression(value from sys/user env properties or
properties file)
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] w6et commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
w6et commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1481644481
> JIRA issue: [[MNG-7038](https://issues.apache.org/jira/browse/MNG-7038)]
Introduce public property to point to a root directory of (multi-module) project
>
> This PR introduces two properties:
>
> * `session.topdir` / `topdir` : _the directory of the topmost project
being built, usually the current directory or the directory pointed at by the
`-f`/`--file` command line argument_. The `topdir` is similar to the
`executionRootDirectory` property available on the session, but renamed to make
it coherent with the new `rootdir` and to avoid using _root_ in its name. The
`topdir` property is computed by the CLI as the directory pointed at by the
`-f`/`--file` command line argument, or the current directory if there's no
such argument.
> * `session.rootdir` / `rootdir` : _the parent directory containing a
`.mvn` subdirectory, usually the directory containing the topmost `pom.xml` of
the project_. The `rootdir` property is roughly the same as the
`${maven.multiModuleProjectDirectory}`, but computed by the CLI. If the
`rootdir` can not be properly determined (usually because there's no `.mvn`
directory), a warning will be printed to the console.
>
> The `topdir` and `rootdir` properties are made available on the
`MavenSession` / `Session` and deprecate the `executionRootDirectory` and
`multiModuleProjectDirectory` properties. The `rootdir` should never change for
a given project and is thus made available for profile activation and model
interpolation. The goal is also to make it available as a system property
during [command line arguments
interpolation](https://github.com/apache/maven/pull/1062).
i think we can define a build.yml\json, generate build-lock.yml\json at
lifecycle process-resources，in build.yml，can load properties file，can define
any public properties with expression(value from sys/user env properties or
properties file)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704248#comment-17704248
]
Tamas Cservenak commented on MENFORCER-426:
---
[~jbarnett] Thanks you a LOT for confirmation.
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704238#comment-17704238
]
Joe Barnett commented on MENFORCER-426:
---
can confirm that workaround does work on 3.9.1 (but we're more likely to stay
on enforcer 3.0.0-M3 than add that workaround at this point in time)
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704230#comment-17704230
]
Tamas Cservenak commented on MENFORCER-426:
---
As [~sjaranowski] mentioned, one workaround (that works ONLY with Maven 3.9.1
would be to invoke your build using Maven 3.9.1 and with
{{-Daether.dependencyCollector.impl=bf}}
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704228#comment-17704228
]
Joe Barnett edited comment on MENFORCER-426 at 3/23/23 4:08 PM:
[~cstamas] have been using maven versions 3.6.3 and 3.8.5 for this, and seen
the same behavior in both versions.
was (Author: jbarnett):
have been using maven versions 3.6.3 and 3.8.5 for this, and seen the same
behavior in both versions.
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[
https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704228#comment-17704228
]
Joe Barnett commented on MENFORCER-426:
---
have been using maven versions 3.6.3 and 3.8.5 for this, and seen the same
behavior in both versions.
> DependencyConvergence in 3.1.0 fails when using version ranges
> --
>
> Key: MENFORCER-426
> URL: https://issues.apache.org/jira/browse/MENFORCER-426
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: dependencyConvergence, Standard Rules
>Affects Versions: 3.0.0, 3.1.0
>Reporter: Joe Barnett
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's
> DependencyConvergence rule passes. Using version 3.1.0 starts to show
> convergence errors that I believe may be related to using version ranges to
> declare dependencies:
> {code:java}
> [WARNING]
> Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile
> paths to dependency are:
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile
> +-com.trib3:graphql:jar:1.32.3279:compile
> and
> +-com.joe.quizzy:server:jar:1.0-SNAPSHOT
> +-com.trib3:graphql:jar:1.32.3324:compile
> {code}
> both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a
> dependency on {{com.trib3:graphql}}, with a version of
> {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to
> 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check
> does not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704184#comment-17704184
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1481340183
I think also in general a new page in `maven-site` would be required
depicting multiple use cases how both values might differ, e.e., `tree(1)`
style.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704183#comment-17704183
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1146267900
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
+
+/**
+ * Returns a boolean indicating if the project is the project from the root
+ * directory of this reactor. The root project is the top-most project
containing
+ * the {@code .mvn} directory. If only a subtree of the reactor is build
(because
+ * the current directory is in a subtree or because the {@code -f} option
has been
+ * specified, then there may be no rootDirProject in this reactor.
+ *
+ * @return {@code true} if the project is the root dir project
+ */
+boolean isRootdirProject();
Review Comment:
Same here
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
Review Comment:
Why not `isTopProject()` or `isTopLevelProject()`?
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,49 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root dir of the project, which is the up-most directory of the
reactor, usually containing
Review Comment:
Here you use the term "up-most" which is likely better
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
Review Comment:
level
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
Review Comment:
Maven
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,49 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiMo
[GitHub] [maven] michael-o commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
michael-o commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1481340183 I think also in general a new page in `maven-site` would be required depicting multiple use cases how both values might differ, e.e., `tree(1)` style. -- 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] michael-o commented on a diff in pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1146267900
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
+
+/**
+ * Returns a boolean indicating if the project is the project from the root
+ * directory of this reactor. The root project is the top-most project
containing
+ * the {@code .mvn} directory. If only a subtree of the reactor is build
(because
+ * the current directory is in a subtree or because the {@code -f} option
has been
+ * specified, then there may be no rootDirProject in this reactor.
+ *
+ * @return {@code true} if the project is the root dir project
+ */
+boolean isRootdirProject();
Review Comment:
Same here
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
Review Comment:
Why not `isTopProject()` or `isTopLevelProject()`?
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,49 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root dir of the project, which is the up-most directory of the
reactor, usually containing
Review Comment:
Here you use the term "up-most" which is likely better
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
Review Comment:
level
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
Review Comment:
Maven
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,49 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root dir of the project, which is the up-most directo
[jira] [Commented] (MNG-7691) Provide a generic way to skip Maven Goals for a specified plugin
[
https://issues.apache.org/jira/browse/MNG-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704145#comment-17704145
]
Michael Osipov commented on MNG-7691:
-
I would say that this should be part of the plugin descriptor/{{@Mojo}}
annotation, e.g., {{skippable}}, by default {{false}} and some method to derive
the property for this...
> Provide a generic way to skip Maven Goals for a specified plugin
>
>
> Key: MNG-7691
> URL: https://issues.apache.org/jira/browse/MNG-7691
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Jimisola Laursen
>Priority: Major
>
> From ([Baeldung|https://www.baeldung.com/maven-disable-parent-pom-plugin]:
> "Many plugins feature a skip parameter. We can use the skip parameter to
> disable the plugin. Support for the skip parameter should be the first thing
> we check because it is the simplest solution and the most conventional.".
> I was thinking that there should be a generic way to skip maven plugin goals
> in the core of Maven, i.e. it should not have to be implemented in each
> plugin.
> Would something like this work?
> -Dmaven.skip.goals=groupID:artifactId:goal (is there a need to specify
> version?)
> E.g.
> -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply
> -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply+validate
> -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply+validate,org.apache.maven.plugins:maven-enforcer-plugin:enforce
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704143#comment-17704143 ] Michael Osipov commented on MRESOLVER-346: -- Release and reacquire can easily lead to race conditions, this needs to be investigated carefully. > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > * another consequence: our "wait time" (def 30s) becomes problem, as due that > above, if build grows, the plausible "wait time" (as all lock is exclusive, > but requester count grows) grows as well. Also, this means we have threads > there doing nothing, just sitting as they wait for exclusive lock one after > another. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. *Change its lock to shared*. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we *could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MRESOLVER-346: - Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. * another consequence: our "wait time" (def 30s) becomes problem, as due that above, if build grows, the plausible "wait time" (as all lock is exclusive, but requester count grows) grows as well. Also, this means we have threads there doing nothing, just sitting as they wait for exclusive lock one after another. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, *no change needed*. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. *Change its lock to shared*. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we *could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. * another consequence: our "wait time" (def 30s) becomes problem, as due that above, if build grows, the plausible "wait time" (as all lock is exclusive, but requester count grows) grows as well. Also, this means we have threads there doing nothing, just sitting as they wait for exclusive lock one after another. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, *no change needed*. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. *Change it's lock to shared*. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we *could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > * another consequence: our "wait time" (def 30s) becomes problem, as due that > above, if build grows, the plausible "wait time" (as all lock is exclusive, > but requester count grows) grows as well. Also, this means we have threads > there doing nothing, just sitting as they wait for exclusive lock one after > another. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeploy
[jira] [Commented] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704137#comment-17704137 ] Michael Osipov commented on MRESOLVER-346: -- The first statement isn't true. Those eager locks have been available since the sync context has been introduced. The difference is that previously it was a noop. > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > * another consequence: our "wait time" (def 30s) becomes problem, as due that > above, if build grows, the plausible "wait time" (as all lock is exclusive, > but requester count grows) grows as well. Also, this means we have threads > there doing nothing, just sitting as they wait for exclusive lock one after > another. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. *Change it's lock to shared*. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we *could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dist-tool] dependabot[bot] closed pull request #25: Bump maven-reporting-exec from 2.0.0-M1 to 2.0.0-M4
dependabot[bot] closed pull request #25: Bump maven-reporting-exec from 2.0.0-M1 to 2.0.0-M4 URL: https://github.com/apache/maven-dist-tool/pull/25 -- 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-dist-tool] dependabot[bot] commented on pull request #25: Bump maven-reporting-exec from 2.0.0-M1 to 2.0.0-M4
dependabot[bot] commented on PR #25: URL: https://github.com/apache/maven-dist-tool/pull/25#issuecomment-1481151382 Superseded by #28. -- 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-dist-tool] dependabot[bot] opened a new pull request, #28: Bump maven-reporting-exec from 2.0.0-M1 to 2.0.0-M5
dependabot[bot] opened a new pull request, #28: URL: https://github.com/apache/maven-dist-tool/pull/28 Bumps [maven-reporting-exec](https://github.com/apache/maven-reporting-exec) from 2.0.0-M1 to 2.0.0-M5. Commits https://github.com/apache/maven-reporting-exec/commit/ac767b531677501b11713ce4535ec3a0f29d15a9";>ac767b5 [maven-release-plugin] prepare release maven-reporting-exec-2.0.0-M5 https://github.com/apache/maven-reporting-exec/commit/fba22bd093d5000cc37f9843b925cce19d26ae5d";>fba22bd [MSHARED-1208] Upgrade plugins and components (in ITs) https://github.com/apache/maven-reporting-exec/commit/f192dce6ec486dc14cb607e2638b265b001d335f";>f192dce [MSHARED-1207] Deprecate MavenReportExecutorRequest#localRepository https://github.com/apache/maven-reporting-exec/commit/a80535e236b03455c7be4bb85dab60e4f609cec2";>a80535e Formatting https://github.com/apache/maven-reporting-exec/commit/bd29118fd0ae381ac9ee841c7f96497a11ca1886";>bd29118 Improve variable name https://github.com/apache/maven-reporting-exec/commit/a80b7b8f1dbeb5035224cf1ee274401831696d80";>a80b7b8 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-reporting-exec/commit/64eeea2476760d5290329532de89559c9bfd6497";>64eeea2 [maven-release-plugin] prepare release maven-reporting-exec-2.0.0-M4 https://github.com/apache/maven-reporting-exec/commit/4b0e26f18d126e7975f114bfcdacd8b732b34366";>4b0e26f [MSHARED-1191] Upgrade Maven Reporting API to 4.0.0-M4 https://github.com/apache/maven-reporting-exec/commit/1a3ee5ceb7ee35c663421dfef2a9ad9ae0b4720f";>1a3ee5c [MSHARED-1190] Upgrade to Doxia/Doxia Sitetools to 2.0.0-M5 https://github.com/apache/maven-reporting-exec/commit/09162b23671340bb7181012fa8d7fbd41ff00d18";>09162b2 [MSHARED-1192] Upgrade plugins in ITs Additional commits viewable in https://github.com/apache/maven-reporting-exec/compare/maven-reporting-exec-2.0.0-M1...maven-reporting-exec-2.0.0-M5";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-shade-plugin] elharo merged pull request #182: Small grammatical corrections and remove IRC
elharo merged PR #182: URL: https://github.com/apache/maven-shade-plugin/pull/182 -- 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-shade-plugin] elharo merged pull request #181: Update to parent POM 39
elharo merged PR #181: URL: https://github.com/apache/maven-shade-plugin/pull/181 -- 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-dependency-plugin] elharo merged pull request #290: use Apache Commons StringUtil
elharo merged PR #290: URL: https://github.com/apache/maven-dependency-plugin/pull/290 -- 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-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704102#comment-17704102
]
Tamas Cservenak commented on MRESOLVER-334:
---
Just adding some context to this issue:
Maven historically had the version parsing implemented in maven-artifact moduie
https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java
and AFAIR the site documents this class
https://maven.apache.org/pom.html#version-order-specification
With Maven 3.x and introduction of aether/resolver, this logic was refined
according to this page
https://cwiki.apache.org/confluence/display/MAVEN//Versioning and
implementation landed here
https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/version/GenericVersion.java
In short, Maven has two version implementations (parser and comparison) and
they deviate from each other annoyingly little, but they do.
One of our goals is to stop this happening, and rely on only one (resolver most
probably), so maven-artifact code should be considered "deprecated", but alas,
we cannot do that right now as many other stuff blocks us (like use of
maven-artifact version related classes on maven-artifact Artifact and related
classes...
Best would be if we could:
* settle on one (as this confuses not only us but also users)
* lay down proper doco/specs and fix all issues
* consider what can we do in Maven 3.x window
Note: Maven 4 API does not suffer from this as it introduces completely new API
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-345) Conflict resolution in verbose mode is sensitive to version ordering
[
https://issues.apache.org/jira/browse/MRESOLVER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-345:
--
Fix Version/s: 1.9.8
> Conflict resolution in verbose mode is sensitive to version ordering
>
>
> Key: MRESOLVER-345
> URL: https://issues.apache.org/jira/browse/MRESOLVER-345
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.8
>
>
> It all started with MENFORCER-426. In short, if we have layout of
> dependencies like this below (ranges are key here), *conflict resolution in
> verbose mode* will misbehave, is sensitive on version ordering in the "dirty
> tree" (collected graph, output of DependencyCollector).
> {noformat}
> A -> B -> C[1..2]
> \--> C[1..2] {noformat}
> (explained: A depends on B and C[1..2] range, and B depends on C[1..2] as
> well)
> As when "dirty tree" is being collected by DependencyCollector (and we have
> two, old DF and new BF), the ranges are turned into series of artifacts with
> versions discovered (by VersionRangeResolver), so the input above while
> collecting A from above would yield some tree like this (in this example
> {{some-group:c:jar}} has versions 1.0 and 2.0 ):
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> This "dirty tree" is then transformed using {{ConflictResolver}} into final
> graph. Conflict resolver in "normal" mode works OK and produces stable
> outputs, that is not sensitive to ordering, this is OK.
> But, conflict resolver supports so called "verbose" mode as well, mostly used
> to perform some "analysis" on graph (like for example "dependency
> convergence" is). Conflict resolver in "verbose" mode {*}is version ordering
> sensitive{*}.
> Conflict resolver in "verbose" mode would transform that dirty tree above
> into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:1.0 [compile] (conflicts 2.0)
> \- some-group:c:jar:2.0 [compile] {noformat}
> And for analysis like "dependency convergence", this would mean *divergency
> is found* (error condition), as there are conflicts. But, if you look more
> closely on input "dirty tree", you can notice that {{b}} depends on {{c:2.0}}
> as well (as b depends on range {{{}[1,2]{}}}.
> Moreover, that dirty tree above is output of resolver standard DF collector.
> BF on the other hand, produces dirty tree like this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:c:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:1.0 [compile] {noformat}
> (the order of c dependencies are sorted descending).
> In other words, DF produces tree with versions in order as discovered
> (essentially metadata based), the BF explicitly sorts versions in descending
> order (to maximize skipper effect, but that is BF internal detail).
> Same conflict resolver in "verbose" mode transforms BF dirty tree into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> And in this case, {*}there is no divergence found{*}. Again, this is same
> input, but collected with DF and BF collectors, then applied conflict
> resolution, and once we have divergence, and once we have no divergence. The
> difference between two inputs is only the order of versions (produced from
> discovered versions that were resolved from metadata, but new BF explicitly
> sorts versions in descending order to better utilize it's own internals).
> Proper conflict resolver solution should be:
> * insensitive on version ordering
> * produce "stable" (same) output for same input (version order should not
> matter, and this is not only about DF vs BF)
> * Good to have: the "verbose" mode we currently have is half-assed, in a
> way, *it still removes nodes* from tree, and leaves one version (the first in
> order, this is the problem) that holds conflict information.
> * Better to have: We may want a "full" verbose mode, where {*}node
> selection/elimination and mediation is done{*}, but *no node was removed*
> graph still contains all the nodes, as that would give much more precise
> picture about dependencies, than like today, "randomly" (first) nodes marked
> for conflict, rest removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-346: -- Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. * another consequence: our "wait time" (def 30s) becomes problem, as due that above, if build grows, the plausible "wait time" (as all lock is exclusive, but requester count grows) grows as well. Also, this means we have threads there doing nothing, just sitting as they wait for exclusive lock one after another. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, *no change needed*. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. *Change it's lock to shared*. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we *could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, *no change needed*. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. *Change it's lock to shared*. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we *could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > * another consequence: our "wait time" (def 30s) becomes problem, as due that > above, if build grows, the plausible "wait time" (as all lock is exclusive, > but requester count grows) grows as well. Also, this means we have threads > there doing nothing, just sitting as they wait for exclusive lock one after > another. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. *Change it's lock to shared*. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very s
[jira] [Commented] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704081#comment-17704081 ] ASF GitHub Bot commented on MRESOLVER-346: -- cstamas opened a new pull request, #272: URL: https://github.com/apache/maven-resolver/pull/272 The locking in resolver is too eager. This PR relaxes locking by introducing use of shared locks (not used before) and following changes: * installer > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. *Change it's lock to shared*. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we *could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #272: [MRESOLVER-346] Too eager locking in resolver
cstamas opened a new pull request, #272: URL: https://github.com/apache/maven-resolver/pull/272 The locking in resolver is too eager. This PR relaxes locking by introducing use of shared locks (not used before) and following changes: * installer -- no change, remains exclusive locking * deployer -- laxed to shared locking, as it only reads local repo * A and M resolver -- implemented "upgrade", they are optimistic and start with shared lock (and will happily finish if local repo has all) but will "upgrade" to exclusive if remote access (hence local caching) is about to happen. Best viewed with whitespace ignore, as there are not much change but blocks got nested. --- https://issues.apache.org/jira/browse/MRESOLVER-346 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-346: -- Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, *no change needed*. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. *Change it's lock to shared*. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we *could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, *no change needed*. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. *Change it's lock to shared*. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we *could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is*: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-346: -- Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above * consequence is that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > * consequence is that "hot" artifacts in bigger multi module build run in > parallel become bottleneck as all threads will wait for their moment to grab > exclusive lock. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, no change needed. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. Change it's lock to shared. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-346: -- Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to local repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to lock repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > This causes that "hot" artifacts in bigger multi module build run in parallel > become bottleneck as all threads will wait for their moment to grab exclusive > lock. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to local > repository, it needs exclusive lock, no change needed. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. Change it's lock to shared. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-346) Too eager locking
Tamas Cservenak created MRESOLVER-346: - Summary: Too eager locking Key: MRESOLVER-346 URL: https://issues.apache.org/jira/browse/MRESOLVER-346 Project: Maven Resolver Issue Type: Bug Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.8 The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: ArtifactInstaller: it is about to install (write) artifact files to lock repository, it needs exclusive lock, no change needed. ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-346) Too eager locking
[ https://issues.apache.org/jira/browse/MRESOLVER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-346: -- Description: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: * ArtifactInstaller: it is about to install (write) artifact files to lock repository, it needs exclusive lock, no change needed. * ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. * ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). was: The locking that is present in Resolver since 1.8.0 is too eager: * there are no shared locks used at all * this implies that local repository access is heavily serialized by locking * there is no "upgrade" of locking due that above This causes that "hot" artifacts in bigger multi module build run in parallel become bottleneck as all threads will wait for their moment to grab exclusive lock. We can do it better: there are 4 main areas where locking is used: ArtifactInstaller: it is about to install (write) artifact files to lock repository, it needs exclusive lock, no change needed. ArtifactDeployer: it is about to upload present files to remote, it does not modifies anything on local. Change it's lock to shared. The exclusive lock also meant that if no DeployAtEnd used, other modules during resolution had to wait while this module uploaded. ArtifactResolver and MetadataResolver: two very similar beasts, they attempt to resolve locally (from local repo) w/o any content modification (read only), and if not successful, they will reach remote to download what is needed (write). Here we could do something similar to [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with shared lock first, and if local content is not fulfilling, release shared, acquire exclusive and REDO all (as meanwhile someone else may downloaded files already). > Too eager locking > - > > Key: MRESOLVER-346 > URL: https://issues.apache.org/jira/browse/MRESOLVER-346 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.8 > > > The locking that is present in Resolver since 1.8.0 is too eager: > * there are no shared locks used at all > * this implies that local repository access is heavily serialized by locking > * there is no "upgrade" of locking due that above > This causes that "hot" artifacts in bigger multi module build run in parallel > become bottleneck as all threads will wait for their moment to grab exclusive > lock. > We can do it better: there are 4 main areas where locking is used: > * ArtifactInstaller: it is about to install (write) artifact files to lock > repository, it needs exclusive lock, no change needed. > * ArtifactDeployer: it is about to upload present files to remote, it does > not modifies anything on local. Change it's lock to shared. The exclusive > lock also meant that if no DeployAtEnd used, other modules during resolution > had to wait while this module uploaded. > * ArtifactResolver and MetadataResolver: two very similar beasts, they > attempt to resolve locally (from local repo) w/o any content modification > (read only), and if not successful, they will reach remote to download what > is needed (write). Here we could do something similar to > [DCL|https://en.wikipedia.org/wiki/Double-checked_locking] is: try with > shared lock first, and if local content is not fulfilling, release shared, > acquire exclusive and REDO all (as meanwhile someone else may downloaded > files already). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] cstamas closed issue #826: Upgrade to maven 3.9.1?
cstamas closed issue #826: Upgrade to maven 3.9.1? URL: https://github.com/apache/maven-mvnd/issues/826 -- 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] cstamas commented on issue #826: Upgrade to maven 3.9.1?
cstamas commented on issue #826: URL: https://github.com/apache/maven-mvnd/issues/826#issuecomment-1480988743 Is already done and release is on vote https://lists.apache.org/thread/cz6ckd3rlkvktlrrw5pv9z5znz00jzt4 -- 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] MarkvanOsch opened a new issue, #826: Upgrade to maven 3.9.1?
MarkvanOsch opened a new issue, #826: URL: https://github.com/apache/maven-mvnd/issues/826 Hi, a gentle request to upgrade mvnd to latest maven 3.9.1. Kind regards, Mark -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] elharo merged pull request #1069: remove unused branches in fake
elharo merged PR #1069: URL: https://github.com/apache/maven/pull/1069 -- 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-7747) Large blocks of whitespace in plugin debug logs
[
https://issues.apache.org/jira/browse/MNG-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703965#comment-17703965
]
Tamas Cservenak commented on MNG-7747:
--
This is funny, and commons-digester3 is plugin dependency... (but not of Maven)
> Large blocks of whitespace in plugin debug logs
> ---
>
> Key: MNG-7747
> URL: https://issues.apache.org/jira/browse/MNG-7747
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Delany
>Priority: Major
>
> I get large blocks of whitespace in debug logs when running the
> formatter-maven-plugin. Author claims its a Maven issue
> [https://github.com/revelc/formatter-maven-plugin/issues/713]
> Reproduce with
> {code:java}
> git clone --branch issue-713
> https://github.com/delanym/formatter-maven-plugin.git
> cd formatter-maven-plugin
> ./do{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] gnodet merged pull request #825: Make native mvnd only require glibc 2.12 on ubuntu 22.04
gnodet merged PR #825: URL: https://github.com/apache/maven-mvnd/pull/825 -- 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 closed issue #823: keep compatible for glibc 2.12 when build on ubuntu 22.04
gnodet closed issue #823: keep compatible for glibc 2.12 when build on ubuntu 22.04 URL: https://github.com/apache/maven-mvnd/issues/823 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7747) Large blocks of whitespace in plugin debug logs
[
https://issues.apache.org/jira/browse/MNG-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7747.
---
Resolution: Invalid
Not from us:
{noformat}
613 [DEBUG] org.apache.commons.digester3.Digester - Fire body() for
SetPropertiesRule[aliases={id=id}, ignoreMissingProperty=true]
614 [DEBUG] org.apache.commons.digester3.Digester - Fire body() for
SetPropertiesRule[aliases={value=value}, ignoreMissingProperty=true]
615 [DEBUG] org.apache.commons.digester3.Digester - Popping body text '
616
617
618
619 '
620 [DEBUG] org.apache.commons.digester3.Digester - Fire end() for
SetPropertiesRule[aliases={value=value}, ignoreMissingProperty=true]
621 [DEBUG] org.apache.commons.digester3.Digester - Fire end() for
SetPropertiesRule[aliases={id=id}, ignoreMissingProperty=true]
622 [DEBUG] org.apache.commons.digester3.Digester - Fire end() for
SetNextRule[methodName=addSetting, paramType=null, paramTypeName=null,
useExactMatch=false, fireOnBegin=false]
623 [DEBUG] org.apache.commons.digester3.Digester -
[SetNextRule]{profiles/profile/setting} Call
net.revelc.code.formatter.model.Profile.addSetting(net.revelc.code.formatter.model.Setting@71926a36)
624 [DEBUG] org.apache.commons.digester3.Digester - Fire end() for
ObjectCreateRule[className=net.revelc.code.formatter.model.Setting,
attributeName=null]
625 [DEBUG] org.apache.commons.digester3.Digester -
[ObjectCreateRule]{profiles/profile/setting} Pop
'net.revelc.code.formatter.model.Setting'
626 [DEBUG] org.apache.commons.digester3.Digester.sax - characters(
627 )
628 [DEBUG] org.apache.commons.digester3.Digester.sax -
startElement(,,setting)
629 [DEBUG] org.apache.commons.digester3.Digester - Pushing body text '
630
631
632
633
634 '
635 [DEBUG] org.apache.commons.digester3.Digester - New
match='profiles/profile/setting'
636 [DEBUG] org.apache.commons.digester3.Digester - Fire begin() for
ObjectCreateRule[className=net.revelc.code.formatter.model.Setting,
attributeName=null]
{noformat}
We don't use Commons Digester.
> Large blocks of whitespace in plugin debug logs
> ---
>
> Key: MNG-7747
> URL: https://issues.apache.org/jira/browse/MNG-7747
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Delany
>Priority: Major
>
> I get large blocks of whitespace in debug logs when running the
> formatter-maven-plugin. Author claims its a Maven issue
> [https://github.com/revelc/formatter-maven-plugin/issues/713]
> Reproduce with
> {code:java}
> git clone --branch issue-713
> https://github.com/delanym/formatter-maven-plugin.git
> cd formatter-maven-plugin
> ./do{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7747) Large blocks of whitespace in plugin debug logs
[
https://issues.apache.org/jira/browse/MNG-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703961#comment-17703961
]
Michael Osipov commented on MNG-7747:
-
You did not mention Java requirements, fails for me.
> Large blocks of whitespace in plugin debug logs
> ---
>
> Key: MNG-7747
> URL: https://issues.apache.org/jira/browse/MNG-7747
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Delany
>Priority: Major
>
> I get large blocks of whitespace in debug logs when running the
> formatter-maven-plugin. Author claims its a Maven issue
> [https://github.com/revelc/formatter-maven-plugin/issues/713]
> Reproduce with
> {code:java}
> git clone --branch issue-713
> https://github.com/delanym/formatter-maven-plugin.git
> cd formatter-maven-plugin
> ./do{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DOXIATOOLS-80) Update to Doxia 2.x
[ https://issues.apache.org/jira/browse/DOXIATOOLS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved DOXIATOOLS-80. --- Resolution: Fixed Fixed in https://github.com/apache/maven-doxia-converter/commit/786c94d7c98a6c960d658105a3ea125e1e3f9971. > Update to Doxia 2.x > --- > > Key: DOXIATOOLS-80 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-80 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIATOOLS-80) Update to Doxia 2.x
[ https://issues.apache.org/jira/browse/DOXIATOOLS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703946#comment-17703946 ] ASF GitHub Bot commented on DOXIATOOLS-80: -- kwin merged PR #41: URL: https://github.com/apache/maven-doxia-converter/pull/41 > Update to Doxia 2.x > --- > > Key: DOXIATOOLS-80 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-80 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: doxia-converter-1.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-doxia-converter] kwin merged pull request #41: [DOXIATOOLS-80] Update to Doxia 2.0.0-M6
kwin merged PR #41: URL: https://github.com/apache/maven-doxia-converter/pull/41 -- 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
