[jira] [Commented] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897194#comment-17897194 ] Elliotte Rusty Harold commented on MDEP-965: That's a comment for MDEP-964. This issue is for replacing org.glassfish:javax.json with org.glassfish:jakarta.json since the former is no longer developed or supported. We should do that whether we decide to allowlist javax.json or not. > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINSTALL-205) Warning when using install-file in parallel builds
Gili created MINSTALL-205:
-
Summary: Warning when using install-file in parallel builds
Key: MINSTALL-205
URL: https://issues.apache.org/jira/browse/MINSTALL-205
Project: Maven Install Plugin
Issue Type: Bug
Affects Versions: 3.1.3
Environment: Maven 3.9.9
Reporter: Gili
Per the online documentation, `install-file`:
* Executes as an aggregator goal.
* The goal is thread-safe and supports parallel builds.
But when I use it in a parallel build I get this warning:
{{[WARNING] *}}
{{[WARNING] * The *}}
{{[WARNING] * org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file
*}}
{{[WARNING] * aggregator mojo is already being executed in this parallel *}}
{{[WARNING] * build, those kind of mojos require exclusive access to *}}
{{[WARNING] * reactor to prevent race conditions. This mojo execution will *}}
{{[WARNING] * be blocked until the aggregator mojo is done. *}}
{{[WARNING] *}}
Expected behavior: If the plugin is safe for use in parallel builds, it should
not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8373) Extract resolver related code into its own impl submodule
Konrad Windszus created MNG-8373: Summary: Extract resolver related code into its own impl submodule Key: MNG-8373 URL: https://issues.apache.org/jira/browse/MNG-8373 Project: Maven Issue Type: Sub-task Components: Core Reporter: Konrad Windszus As https://github.com/apache/maven/tree/master/compat/maven-resolver-provider has a substantial amount of classes and also very limited interaction with other core classes, it would be good to re-extract the resolver related ones into a dedicated submodule. In the best case this would allow to get rid of all resolved dependencies from Core. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897206#comment-17897206
]
Gili commented on MINSTALL-205:
---
For clarification, I have a multi-module project that depends on libraries that
are missing {{{}module-info.java{}}}. Consequently, one of my sub-modules uses
moditect-maven-plugin to add {{module-info.java}} files and repackage those
libraries under a local groupId so that the final project's dependencies are
all modularized. This is the only reason I am using "mvn install" instead of
"mvn verify". To authors of the libraries in question have been unwilling to
add "module-info.java" themselves :(
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3, 4.0.0-beta-1
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-8372] Augment error message to give users more context when running into deprecated encryption warning [maven]
ottlinger opened a new pull request, #1898: URL: https://github.com/apache/maven/pull/1898 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8372: - Fix Version/s: 4.0.0-beta-6 > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > Fix For: 4.0.0-beta-6 > > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIATOOLS-90) Optionally write converted files to input files and then rename via git mv
[ https://issues.apache.org/jira/browse/DOXIATOOLS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897239#comment-17897239 ] Michael Osipov commented on DOXIATOOLS-90: -- This sounds very very specific and out of scope for this tool. > Optionally write converted files to input files and then rename via git mv > -- > > Key: DOXIATOOLS-90 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-90 > Project: Maven Doxia Tools > Issue Type: New Feature > Components: Doxia Converter >Reporter: Konrad Windszus >Priority: Major > > Using [git mv|https://git-scm.com/docs/git-mv] allows to keep the file's > history (although using the blame feature won't work as the line numbers are > off after conversion). > This is reasonable to use when the input files are managed with Git and the > converted ones should still be. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MCLEAN-117) Threading issue with fast=true on multi-module project.
[ https://issues.apache.org/jira/browse/MCLEAN-117 ]
Peter De Maeyer deleted comment on MCLEAN-117:
was (Author: peterdm):
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + 3 retries with back-off delays of 50 +
250 + 750 milliseconds, only to fail 3 times over again for the same reason.
Depending on {{failOnError}} this will actually fail the build or not, but in
any case it will cause an unnecessary delay. This could be fixed, by rewriting
the {{Cleaner}} to leverage {{Files.walkFileTree(Path, FileVisitor)}} + being
smarter about when to (not) delete a directory. MCLEAN-126 won't fix it, but is
a prerequisite first step towards improving this.
> Threading issue with fast=true on multi-module project.
> ---
>
> Key: MCLEAN-117
> URL: https://issues.apache.org/jira/browse/MCLEAN-117
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Dan Mclaughlin
>Priority: Major
>
> We recently moved to new Macbooks with the M3 Max and have started seeing
> random failures where builds will fail trying to access files in target. Our
> project is a multi-module project with multiple sub-modules, with 50+ modules
> in total. For example...
> pom.xml (parent)
> module1 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module1)
> sub-module2 (parent is module1)
> pom.xml
> module2 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module2)
> sub-module2 (parent is module2)
> pom.xml
> module3, 4, 5, etc...
> We build using -TC1, so on the M3 Max there are 16 threads used during the
> build.
> We didn't see this problem often running on our older laptops; we rarely saw
> it on our Windows laptops because they only had 8 cores, but we would
> occasionally see it on our Macbook Pro 2019 models with i9 8 core (16 with
> hyperthreading). Now that we are using the new M3 Max we can't get a build
> to finish without failures.
> We see that things fail randomly when trying to access files in the target.
> For example...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:analyze-only (analyze)
> on project authservice-webapp: Cannot analyze dependencies:
> /Users/username/workspace/trunk/common-resources/target/common-resources-28.0.0-SNAPSHOT.jar
> -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:copy-dependencies
> (copy-dependencies) on project spatialdata-loader: Error copying artifact
> from
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> to
> /Users/username/workspace//trunk/spatialdata/spatialdata-loader/target/lib/ant-spring-runner-28.0.0-SNAPSHOT.jar:
> File
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> does not exist ->
> [Help 1]
> To debug it down to possibly a threading issue related to using fast with
> maven-clean-plugin a tested the following...
> If I build using "mvn clean install" the build always fails and in random
> places.
> If I build with -T1 then the build never fails. It also doesn't fail with up
> to -T7, but failures start at -T8 or -TC1.
> If I run mvn clean first, then mvn install, then the build never fails.
> If I build using "mvn clean install", but I disable fast, then the build
> never fails.
> This is our plugin configuration. All I have to do is set fast to false, and
> we won't see any of the random failures as I described above. So it seems
> like there is some threading issue with fast where files are being deleted.
> {code:java}
>
> org.apache.maven.plugins
> maven-clean-plugin
> ${maven-clean-plugin.version}
>
>
>
> ${project.basedir}
> true
> true
>
> *.tgz
> src/**/generated-sources/**
> dist/**
> app/scripts/beans/**
> src/scripts/beans/**
>
>
>
>
> false
> true
> true
> true
> ${project.build.directory}/.clean
> background
>
> {code}
> One place it will randomly fail is a sub-module like this...
> root
> pom.xml
> module A
> pom.xml
> sub-module 1
> pom.xml
> sub-module 2
> pom.xml (sub-module 2 has a runtime dependency on module
> A/sub-module 1)
> If
[jira] [Comment Edited] (MCLEAN-117) Threading issue with fast=true on multi-module project.
[
https://issues.apache.org/jira/browse/MCLEAN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897270#comment-17897270
]
Peter De Maeyer edited comment on MCLEAN-117 at 11/11/24 8:12 PM:
--
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + 3 retries with back-off delays of 50 +
250 + 750 milliseconds, only to fail 3 times over again for the same reason.
Depending on {{failOnError}} this will actually fail the build or not, but in
any case it will cause an unnecessary delay. This could be fixed, by rewriting
the {{Cleaner}} to leverage {{Files.walkFileTree(Path, FileVisitor)}} + being
smarter about when to (not) delete a directory. MCLEAN-126 won't fix it, but is
a prerequisite first step towards improving this.
was (Author: peterdm):
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + 3 retries with back-off delays of 50 +
250 + 750 milliseconds, only to fail 3 times over again for the same reason.
Depending on {{failOnError}} this will actually fail the build or not, but in
any case it will cause an unnecessary delay. This could be fixed, by rewriting
the {{Cleaner}} to leverage {{Files.walkFileTree(Path, FileVisitor)}}.
MCLEAN-126 won't fix it, but is a prerequisite first step towards improving
this.
> Threading issue with fast=true on multi-module project.
> ---
>
> Key: MCLEAN-117
> URL: https://issues.apache.org/jira/browse/MCLEAN-117
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Dan Mclaughlin
>Priority: Major
>
> We recently moved to new Macbooks with the M3 Max and have started seeing
> random failures where builds will fail trying to access files in target. Our
> project is a multi-module project with multiple sub-modules, with 50+ modules
> in total. For example...
> pom.xml (parent)
> module1 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module1)
> sub-module2 (parent is module1)
> pom.xml
> module2 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module2)
> sub-module2 (parent is module2)
> pom.xml
> module3, 4, 5, etc...
> We build using -TC1, so on the M3 Max there are 16 threads used during the
> build.
> We didn't see this problem often running on our older laptops; we rarely saw
> it on our Windows laptops because they only had 8 cores, but we would
> occasionally see it on our Macbook Pro 2019 models with i9 8 core (16 with
> hyperthreading). Now that we are using the new M3 Max we can't get a build
> to finish without failures.
> We see that things fail randomly when trying to access files in the target.
> For example...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:analyze-only (analyze)
> on project authservice-webapp: Cannot analyze dependencies:
> /Users/username/workspace/trunk/common-resources/target/common-resources-28.0.0-SNAPSHOT.jar
> -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:copy-dependencies
> (copy-dependencies) on project spatialdata-loader: Error copying artifact
> from
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> to
> /Users/username/workspace//trunk/spatialdata/spatialdata-loader/target/lib/ant-spring-runner-28.0.0-SNAPSHOT.jar:
> File
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> does not exist ->
> [Help 1]
> To debug it down to possibly a threading issue related to using fast with
> maven-clean-plugin a tested the following...
> If I build using "mvn clean install" the build always fails and in random
> places.
> If I build with -T1 then the build never fails. It also doesn't fail with up
> to -T7, but failures start at -T8 or -TC1.
> If I run mvn clean first, then mvn install, then the build never fails.
> If I build using "mvn clean install", but I disable fast, then the build
> never fails.
> This is our plugin configuration. All I have to do is set fast to false, and
>
[PR] Bump commons-io:commons-io from 2.16.1 to 2.17.0 [maven-dependency-plugin]
dependabot[bot] opened a new pull request, #462: URL: https://github.com/apache/maven-dependency-plugin/pull/462 Bumps commons-io:commons-io from 2.16.1 to 2.17.0. [](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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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
[jira] [Commented] (MCLEAN-117) Threading issue with fast=true on multi-module project.
[
https://issues.apache.org/jira/browse/MCLEAN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897270#comment-17897270
]
Peter De Maeyer commented on MCLEAN-117:
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + an 3 retries with back-off delays of
50 + 250 + 750 milliseconds, only to fail 3 times over again for the same
reason. Depending on {{failOnError}} this will actually fail the build or not,
but in any case it will cause an unnecessary delay. This could be fixed, by
rewriting the {{Cleaner}} to leverage {{Files.walkFileTree(Path,
FileVisitor)}}. MCLEAN-126 won't fix it, but is a prerequisite first step
towards improving this.
> Threading issue with fast=true on multi-module project.
> ---
>
> Key: MCLEAN-117
> URL: https://issues.apache.org/jira/browse/MCLEAN-117
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Dan Mclaughlin
>Priority: Major
>
> We recently moved to new Macbooks with the M3 Max and have started seeing
> random failures where builds will fail trying to access files in target. Our
> project is a multi-module project with multiple sub-modules, with 50+ modules
> in total. For example...
> pom.xml (parent)
> module1 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module1)
> sub-module2 (parent is module1)
> pom.xml
> module2 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module2)
> sub-module2 (parent is module2)
> pom.xml
> module3, 4, 5, etc...
> We build using -TC1, so on the M3 Max there are 16 threads used during the
> build.
> We didn't see this problem often running on our older laptops; we rarely saw
> it on our Windows laptops because they only had 8 cores, but we would
> occasionally see it on our Macbook Pro 2019 models with i9 8 core (16 with
> hyperthreading). Now that we are using the new M3 Max we can't get a build
> to finish without failures.
> We see that things fail randomly when trying to access files in the target.
> For example...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:analyze-only (analyze)
> on project authservice-webapp: Cannot analyze dependencies:
> /Users/username/workspace/trunk/common-resources/target/common-resources-28.0.0-SNAPSHOT.jar
> -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:copy-dependencies
> (copy-dependencies) on project spatialdata-loader: Error copying artifact
> from
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> to
> /Users/username/workspace//trunk/spatialdata/spatialdata-loader/target/lib/ant-spring-runner-28.0.0-SNAPSHOT.jar:
> File
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> does not exist ->
> [Help 1]
> To debug it down to possibly a threading issue related to using fast with
> maven-clean-plugin a tested the following...
> If I build using "mvn clean install" the build always fails and in random
> places.
> If I build with -T1 then the build never fails. It also doesn't fail with up
> to -T7, but failures start at -T8 or -TC1.
> If I run mvn clean first, then mvn install, then the build never fails.
> If I build using "mvn clean install", but I disable fast, then the build
> never fails.
> This is our plugin configuration. All I have to do is set fast to false, and
> we won't see any of the random failures as I described above. So it seems
> like there is some threading issue with fast where files are being deleted.
> {code:java}
>
> org.apache.maven.plugins
> maven-clean-plugin
> ${maven-clean-plugin.version}
>
>
>
> ${project.basedir}
> true
> true
>
> *.tgz
> src/**/generated-sources/**
> dist/**
> app/scripts/beans/**
> src/scripts/beans/**
>
>
>
>
> false
> true
> true
> true
> ${project.build.directory}/.clean
> background
>
> {code}
> One place it will randomly fail is a sub-module like this...
> root
> pom.xml
> module A
> pom.xml
> sub-module 1
> pom.xml
> sub-module 2
> pom.xml (sub-module 2 has a runtime dependency on modu
[jira] [Comment Edited] (MCLEAN-117) Threading issue with fast=true on multi-module project.
[
https://issues.apache.org/jira/browse/MCLEAN-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897270#comment-17897270
]
Peter De Maeyer edited comment on MCLEAN-117 at 11/11/24 8:11 PM:
--
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + 3 retries with back-off delays of 50 +
250 + 750 milliseconds, only to fail 3 times over again for the same reason.
Depending on {{failOnError}} this will actually fail the build or not, but in
any case it will cause an unnecessary delay. This could be fixed, by rewriting
the {{Cleaner}} to leverage {{Files.walkFileTree(Path, FileVisitor)}}.
MCLEAN-126 won't fix it, but is a prerequisite first step towards improving
this.
was (Author: peterdm):
I think there is another limitation. Looking at the code {{Cleaner.delete}},
{{fast}} mode together with {{includes/excludes}} has a performance impact. As
soon as a file is excluded from a directory, it will cause the
{{parentDir.delete}} to fail because the dir is obviously not empty, which will
result in a {{System.gc()}} on Windows + an 3 retries with back-off delays of
50 + 250 + 750 milliseconds, only to fail 3 times over again for the same
reason. Depending on {{failOnError}} this will actually fail the build or not,
but in any case it will cause an unnecessary delay. This could be fixed, by
rewriting the {{Cleaner}} to leverage {{Files.walkFileTree(Path,
FileVisitor)}}. MCLEAN-126 won't fix it, but is a prerequisite first step
towards improving this.
> Threading issue with fast=true on multi-module project.
> ---
>
> Key: MCLEAN-117
> URL: https://issues.apache.org/jira/browse/MCLEAN-117
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Dan Mclaughlin
>Priority: Major
>
> We recently moved to new Macbooks with the M3 Max and have started seeing
> random failures where builds will fail trying to access files in target. Our
> project is a multi-module project with multiple sub-modules, with 50+ modules
> in total. For example...
> pom.xml (parent)
> module1 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module1)
> sub-module2 (parent is module1)
> pom.xml
> module2 (parent is root)
> pom.xml
> sub-module1 (parent is module1
> pom.xml
> sub-sub-module (parent is sub-module2)
> sub-module2 (parent is module2)
> pom.xml
> module3, 4, 5, etc...
> We build using -TC1, so on the M3 Max there are 16 threads used during the
> build.
> We didn't see this problem often running on our older laptops; we rarely saw
> it on our Windows laptops because they only had 8 cores, but we would
> occasionally see it on our Macbook Pro 2019 models with i9 8 core (16 with
> hyperthreading). Now that we are using the new M3 Max we can't get a build
> to finish without failures.
> We see that things fail randomly when trying to access files in the target.
> For example...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:analyze-only (analyze)
> on project authservice-webapp: Cannot analyze dependencies:
> /Users/username/workspace/trunk/common-resources/target/common-resources-28.0.0-SNAPSHOT.jar
> -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.6.1:copy-dependencies
> (copy-dependencies) on project spatialdata-loader: Error copying artifact
> from
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> to
> /Users/username/workspace//trunk/spatialdata/spatialdata-loader/target/lib/ant-spring-runner-28.0.0-SNAPSHOT.jar:
> File
> /Users/username/workspace/trunk/spatialdata/ant-spring-runner/target/ant-spring-runner-28.0.0-SNAPSHOT.jar
> does not exist ->
> [Help 1]
> To debug it down to possibly a threading issue related to using fast with
> maven-clean-plugin a tested the following...
> If I build using "mvn clean install" the build always fails and in random
> places.
> If I build with -T1 then the build never fails. It also doesn't fail with up
> to -T7, but failures start at -T8 or -TC1.
> If I run mvn clean first, then mvn install, then the build never fails.
> If I build using "mvn clean install", but I disable fast, then the build
> never fails.
> This is our plugin configuration. All I have to do is set fast to false, and
> we won't see any of the random failures as I descri
[jira] [Updated] (MARTIFACT-80) `ignore` doesn't work on the main module artifact
[ https://issues.apache.org/jira/browse/MARTIFACT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Ng updated MARTIFACT-80: Description: The `ignore` configuration option doesn't work on the main artifact of the module, only on additional attached artifacts. Use case I have is that we're building RPMs on a (very) old CentOS version and they have attributes that aren't easily 'fixable' to be cleanly rebuilt. I ignore 'failures' in those individual modules, but when the plugin tries to do the aggregated `buildInfo` on the last module those RPMs aren't ignored, and I don't want to ignore failures for every module in the aggregator. (was: The `ignore` configuration option doesn't work on the main artifact of the module, only on additional attached artifacts. Use case I have is that we're building RPMs on a (very) old CentOS version and they have attributes that aren't easily 'fixable' to be cleanly rebuilt. I can not 'fail' the build in those individual modules, but when the plugin tries to do the aggregated `buildInfo` on the last module those RPMs aren't ignored, and I don't want to ignore failures for every module in the aggregator.) > `ignore` doesn't work on the main module artifact > - > > Key: MARTIFACT-80 > URL: https://issues.apache.org/jira/browse/MARTIFACT-80 > Project: Maven Artifact Plugin > Issue Type: Bug > Components: artifact:compare >Affects Versions: 3.5.3 >Reporter: Christopher Ng >Priority: Major > > The `ignore` configuration option doesn't work on the main artifact of the > module, only on additional attached artifacts. Use case I have is that we're > building RPMs on a (very) old CentOS version and they have attributes that > aren't easily 'fixable' to be cleanly rebuilt. I ignore 'failures' in those > individual modules, but when the plugin tries to do the aggregated > `buildInfo` on the last module those RPMs aren't ignored, and I don't want to > ignore failures for every module in the aggregator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCLEAN-102) Fast is slower on windows with many cores
[
https://issues.apache.org/jira/browse/MCLEAN-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897271#comment-17897271
]
Peter De Maeyer commented on MCLEAN-102:
There is not much to go on in this issue to effectively root-cause this, but
let's see if we can hypothesize as to what _might_ be a root cause.
Looking at the code {{Cleaner.delete}}, {{fast}} mode together with
{{includes/excludes}} could have a performance impact. As soon as a file is
excluded from a directory, it will cause the {{parentDir.delete}} to fail
because the dir is obviously not empty, which will result in a {{System.gc()}}
on Windows + 3 retries with back-off delays of 50 + 250 + 750 milliseconds,
only to fail 3 times over again for the same reason. Depending on
{{failOnError}} this will actually fail the build or not, but in any case it
will cause an unnecessary delay. This could be fixed, by rewriting the
{{Cleaner}} to leverage {{Files.walkFileTree(Path, FileVisitor)}} + being
smarter about when to (not) delete a directory. MCLEAN-126 won't fix it, but is
a prerequisite first step towards improving this.
> Fast is slower on windows with many cores
> -
>
> Key: MCLEAN-102
> URL: https://issues.apache.org/jira/browse/MCLEAN-102
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Delany
>Priority: Major
>
> I run a 500+ module project with 4 core Linux and experience a 20sec
> improvement in reactor build time when enabling the fast.
> My one colleagues runs the same build with 4 cores on Windows and also sees
> an improvement.
> But two other colleagues run the same build with 12 cores on Windows (one
> uses cygwin, the other powershell) and they consistently see a slowdown from
> 2:14 to 3:23, for example.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8374) mvn uses option --enable-native-access
Jochen Wiedmann created MNG-8374:
Summary: mvn uses option --enable-native-access
Key: MNG-8374
URL: https://issues.apache.org/jira/browse/MNG-8374
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 4.0.0-beta-5
Reporter: Jochen Wiedmann
Sorry, if I am wrong, but it is my understanding that Maven 4 is still supposed
to work with Java 8 as the build JVM. Fact is, it doesn't, if I use the
JAVA_HOME
variable to use Java 8 as the build JVM
{{$ JAVA_HOME=/usr/lib/jvm/java-1.8.0 /home/jwi/opt/mvn/4.0.0-beta-5/bin/mvn -V
Unrecognized option: --enable-native-access=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.hamcrest:hamcrest from 2.2 to 3.0 [maven]
dependabot[bot] opened a new pull request, #1900: URL: https://github.com/apache/maven/pull/1900 Bumps [org.hamcrest:hamcrest](https://github.com/hamcrest/JavaHamcrest) from 2.2 to 3.0. Release notes Sourced from https://github.com/hamcrest/JavaHamcrest/releases";>org.hamcrest:hamcrest's releases. Hamcrest v3.0 Breaking Changes From version 3.0, the jar distributed to Maven Central is now compiled to Java 1.8 bytecode, and is not compatible with previous versions of Java. See [Issue https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>#331](https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>hamcrest/JavaHamcrest#331) and [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>#411](https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>hamcrest/JavaHamcrest#411) for details. Developers who use Java 1.7 earlier can still depend upon hamcrest-2.2.jar. Improvements FileMatchersTest simplification ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>#389](https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>hamcrest/JavaHamcrest#389)) License cleanup ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>#414](https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>hamcrest/JavaHamcrest#414), [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>#415](https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>hamcrest/JavaHamcrest#415), see also https://redirect.github.com/hamcrest/JavaHamcrest/issues/264";>#264, https://redirect.github.com/hamcrest/JavaHamcrest/issues/355";>#355, https://redirect.github.com/hamcrest/JavaHamcrest/issues/396";>#396, and https://redirect.github.com/hamcrest/JavaHamcrest/issues/399";>#399) Hamcrest v3.0-rc1 Breaking Changes From version 3.0, the jar distributed to Maven Central is now compiled to Java 1.8 bytecode, and is not compatible with previous versions of Java. See [Issue https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>#331](https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>hamcrest/JavaHamcrest#331) and [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>#411](https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>hamcrest/JavaHamcrest#411) for details. Developers who use Java 1.7 earlier can still depend upon hamcrest-2.2.jar. Improvements FileMatchersTest simplification ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>#389](https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>hamcrest/JavaHamcrest#389)) License cleanup ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>#414](https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>hamcrest/JavaHamcrest#414), [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>#415](https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>hamcrest/JavaHamcrest#415), see also https://redirect.github.com/hamcrest/JavaHamcrest/issues/264";>#264, https://redirect.github.com/hamcrest/JavaHamcrest/issues/355";>#355, https://redirect.github.com/hamcrest/JavaHamcrest/issues/396";>#396, and https://redirect.github.com/hamcrest/JavaHamcrest/issues/399";>#399) Changelog Sourced from https://github.com/hamcrest/JavaHamcrest/blob/master/CHANGES.md";>org.hamcrest:hamcrest's changelog. Version 3.0 (1st August 2024) Breaking Changes From version 3.0, the jar distributed to Maven Central is now compiled to Java 1.8 bytecode, and is not compatible with previous versions of Java. See [Issue https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>#331](https://redirect.github.com/hamcrest/JavaHamcrest/issues/331";>hamcrest/JavaHamcrest#331) and [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>#411](https://redirect.github.com/hamcrest/JavaHamcrest/issues/411";>hamcrest/JavaHamcrest#411) for details. Developers who use Java 1.7 earlier can still depend upon hamcrest-2.2.jar. Improvements FileMatchersTest simplification ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>#389](https://redirect.github.com/hamcrest/JavaHamcrest/issues/389";>hamcrest/JavaHamcrest#389)) License cleanup ([PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>#414](https://redirect.github.com/hamcrest/JavaHamcrest/issues/414";>hamcrest/JavaHamcrest#414), [PR https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>#415](https://redirect.github.com/hamcrest/JavaHamcrest/issues/415";>hamcrest/JavaHamcrest#415), see also https://redirect.github.com/hamcrest/JavaHamcrest/issues/264";>#264, https://redirect.github.com/hamcrest/JavaHamcrest/issues/355";>#355, https://redirect.github.com/hamcrest/JavaHamcrest/issues/396";>#396,and https://redirect.github.com/hamcrest/JavaHamcrest/issues/399";>#399)
[PR] Bump commons-io:commons-io from 2.14.0 to 2.17.0 [maven]
dependabot[bot] opened a new pull request, #1899: URL: https://github.com/apache/maven/pull/1899 Bumps commons-io:commons-io from 2.14.0 to 2.17.0. [](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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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
[jira] [Commented] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897196#comment-17897196 ] Elliotte Rusty Harold commented on MDEP-965: https://stackoverflow.com/questions/70302594/javax-json-and-jakarta-json-in-the-same-application-org-glassfish-json-jsonprov > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897203#comment-17897203
]
Gili edited comment on MINSTALL-205 at 11/11/24 2:56 PM:
-
Invoking {{mvn verify install:install}} causes the warning to disappear. I know
that "mvn install" is not the same as "mvn install:install" but it's still not
clear why the former would trigger a warning claiming that the "install" or
"install-file" goals are not thread-safe when they are... This seems like a
bug, no? If not, it would be helpful to clarify the documentation on this
point.}}
was (Author: cowwoc):
{{Invoking {{mvn verify install:install}} causes the warning to disappear. I
know that "mvn install" is not the same as "mvn install:install" but it's still
not clear why the former would trigger a warning claiming that the "install" or
"install-file" goals are not thread-safe when they are... This seems like a
bug, no? If not, it would be helpful to clarify the documentation on this
point.}}
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3, 4.0.0-beta-1
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897203#comment-17897203
]
Gili commented on MINSTALL-205:
---
{{Invoking {{mvn verify install:install}} causes the warning to disappear. I
know that "mvn install" is not the same as "mvn install:install" but it's still
not clear why the former would trigger a warning claiming that the "install" or
"install-file" goals are not thread-safe when they are... This seems like a
bug, no? If not, it would be helpful to clarify the documentation on this
point.}}
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3, 4.0.0-beta-1
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MINSTALL-205:
--
Description:
ePer the online documentation, `install-file`:
* Executes as an aggregator goal.
* The goal is thread-safe and supports parallel builds.
But when I use it in a parallel build I get this warning:
{{[WARNING] *}}
{{[WARNING] * The *}}
{{[WARNING] * org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file
*}}
{{[WARNING] * aggregator mojo is already being executed in this parallel *}}
{{[WARNING] * build, those kind of mojos require exclusive access to *}}
{{[WARNING] * reactor to prevent race conditions. This mojo execution will *}}
{{[WARNING] * be blocked until the aggregator mojo is done. *}}
{{[WARNING] *}}
Expected behavior: If the plugin is safe for use in parallel builds, it should
not trigger this warning.
was:
Per the online documentation, `install-file`:
* Executes as an aggregator goal.
* The goal is thread-safe and supports parallel builds.
But when I use it in a parallel build I get this warning:
{{[WARNING] *}}
{{[WARNING] * The *}}
{{[WARNING] * org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file
*}}
{{[WARNING] * aggregator mojo is already being executed in this parallel *}}
{{[WARNING] * build, those kind of mojos require exclusive access to *}}
{{[WARNING] * reactor to prevent race conditions. This mojo execution will *}}
{{[WARNING] * be blocked until the aggregator mojo is done. *}}
{{[WARNING] *}}
Expected behavior: If the plugin is safe for use in parallel builds, it should
not trigger this warning.
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MINSTALL-205:
--
Affects Version/s: 4.0.0-beta-1
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3, 4.0.0-beta-1
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MARTIFACT-80) `ignore` doesn't work on the main module artifact
Christopher Ng created MARTIFACT-80: --- Summary: `ignore` doesn't work on the main module artifact Key: MARTIFACT-80 URL: https://issues.apache.org/jira/browse/MARTIFACT-80 Project: Maven Artifact Plugin Issue Type: Bug Components: artifact:compare Affects Versions: 3.5.3 Reporter: Christopher Ng The `ignore` configuration option doesn't work on the main artifact of the module, only on additional attached artifacts. Use case I have is that we're building RPMs on a (very) old CentOS version and they have attributes that aren't easily 'fixable' to be cleanly rebuilt. I can not 'fail' the build in those individual modules, but when the plugin tries to do the aggregated `buildInfo` on the last module those RPMs aren't ignored, and I don't want to ignore failures for every module in the aggregator. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Update m2.conf to match Maven 4.x [maven-mvnd]
oehme opened a new pull request, #1200: URL: https://github.com/apache/maven-mvnd/pull/1200 So calling the `mvn` executable from a daemon distribution behaves more like vanilla Maven 4.x -- 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
[PR] Add Forgejo to the List of Repository Managers [maven-site]
uwekoenig opened a new pull request, #575: URL: https://github.com/apache/maven-site/pull/575 (no comment) -- 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] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897167#comment-17897167 ] Slawomir Jaranowski commented on MDEP-965: -- I'm not sure if we should add next hardcoded item to default excludes Especially when proposed artifact is not widely used by common projects. If we go such way we will have a huge list of default exclusions. User should define own exclusion in own project. Next issue is there when user defined custom exclusion - default ones are gone ... so it is not usable for me > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
Philipp Ottlinger created MNG-8372: -- Summary: [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it? Key: MNG-8372 URL: https://issues.apache.org/jira/browse/MNG-8372 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-beta-5 Reporter: Philipp Ottlinger I ran into above error message and asked myself what to do the error message does not tell me anything. https://maven.apache.org/guides/mini/guide-encryption.html is the way I encrypted my password. Can someone clarify the implication of this error message? Is there a page that tells me how to properly/safely configure my credentials. To my mind it would be helpful to have a before/after example to explicitly show where the problem is and how to circumvent it. Thanks $ ./mvnw Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 Default locale: de_DE, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" [WARNING] Legacy/insecurely encrypted password detected for server srv.snapshots.https [WARNING] Legacy/insecurely encrypted password detected for server srv.releases.https [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897181#comment-17897181 ] Tamas Cservenak commented on MNG-8372: -- What I forgot to mention: * maven4 warns that you use (busted) maven3 encryption, hence the warning * maven4 is backward compatible to maven3 encryption, but maven3 will not be able to utilize maven4 encryption. > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[
https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897180#comment-17897180
]
Tamas Cservenak commented on MNG-8372:
--
Maven 4 introduced new CLI tool called {{mvnenc}}, that is sadly busted (fully
defunct) in Maven 4.0.0-beta-5. You could use current master build and run
{{mvnenc init}} to set it up, but the setup is not backward compatible as Maven
3 password encryption is fully broken.
> [WARNING] Legacy/insecurely encrypted password detected for server - what
> can/shall I do about it?
> --
>
> Key: MNG-8372
> URL: https://issues.apache.org/jira/browse/MNG-8372
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-beta-5
>Reporter: Philipp Ottlinger
>Priority: Major
>
> I ran into above error message and asked myself what to do
> the error message does not tell me anything.
> https://maven.apache.org/guides/mini/guide-encryption.html
> is the way I encrypted my password.
> Can someone clarify the implication of this error message? Is there a page
> that tells me how to properly/safely configure my credentials. To my mind it
> would be helpful to have a before/after example to explicitly show where the
> problem is and how to circumvent it.
> Thanks
> $ ./mvnw
> Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad)
> Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f
> Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix"
> [WARNING] Legacy/insecurely encrypted password detected for server
> srv.snapshots.https
> [WARNING] Legacy/insecurely encrypted password detected for server
> srv.releases.https
> [INFO] Scanning for projects...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.10.1 to 3.11.1 [maven-mvnd]
dependabot[bot] opened a new pull request, #1199: URL: https://github.com/apache/maven-mvnd/pull/1199 Bumps [org.apache.maven.plugins:maven-javadoc-plugin](https://github.com/apache/maven-javadoc-plugin) from 3.10.1 to 3.11.1. Commits https://github.com/apache/maven-javadoc-plugin/commit/619650c667070ef114d571c0f075ce456ace1cf8";>619650c [maven-release-plugin] prepare release maven-javadoc-plugin-3.11.1 https://github.com/apache/maven-javadoc-plugin/commit/e314da0226d100eae39d96d7a0cbdad799879dca";>e314da0 [MJAVADOC-821] Align toolchain discovery code with Maven Compiler Plugin https://github.com/apache/maven-javadoc-plugin/commit/62a686180915de1e3c0a2f71081776eacfd1d4c3";>62a6861 [MJAVADOC-820] [REGRESSION] MJAVADOC-787 was merged incompletely https://github.com/apache/maven-javadoc-plugin/commit/d1090c50ce66e10ab0adcadb996b0fe790c900b6";>d1090c5 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-javadoc-plugin/commit/ee030f719f4bc7df1671f6dfe5993f778b57a504";>ee030f7 [maven-release-plugin] prepare release maven-javadoc-plugin-3.11.0 https://github.com/apache/maven-javadoc-plugin/commit/6c5fdc06d76fdd429c4d3ae01e70be8917c64bea";>6c5fdc0 [MJAVADOC-819] Align archive generation code with Maven Source Plugin https://github.com/apache/maven-javadoc-plugin/commit/3a90de597adff7c8f8c4a420400f24c7386e9880";>3a90de5 [MJAVADOC-787] Automatic detection of release option for JDK < 9 https://github.com/apache/maven-javadoc-plugin/commit/373172d8782ad011cc14e20ac78a84d032ad1d4b";>373172d [MJAVADOC-817] Upgrade to Doxia 2.0.0 GA Stack https://github.com/apache/maven-javadoc-plugin/commit/ba266c0fe11a822bf3fb19c365a174246eae29f9";>ba266c0 Fix SCM tag https://github.com/apache/maven-javadoc-plugin/commit/5775ce13455d565bd10b15cbeb94310074dee8a3";>5775ce1 Fix typo Additional commits viewable in https://github.com/apache/maven-javadoc-plugin/compare/maven-javadoc-plugin-3.10.1...maven-javadoc-plugin-3.11.1";>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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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
[PR] Bump groovy.version from 4.0.23 to 4.0.24 [maven-mvnd]
dependabot[bot] opened a new pull request, #1198: URL: https://github.com/apache/maven-mvnd/pull/1198 Bumps `groovy.version` from 4.0.23 to 4.0.24. Updates `org.apache.groovy:groovy` from 4.0.23 to 4.0.24 Commits See full diff in https://github.com/apache/groovy/commits";>compare view Updates `org.apache.groovy:groovy-all` from 4.0.23 to 4.0.24 Commits See full diff in https://github.com/apache/groovy/commits";>compare view 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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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
Re: [PR] Bump org.apache.maven.shared:maven-shared-utils from 0.9 to 3.4.2 [maven]
cstamas merged PR #1896: URL: https://github.com/apache/maven/pull/1896 -- 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
Re: [PR] Bump org.junit.jupiter:junit-jupiter from 5.8.0 to 5.11.3 [maven]
cstamas merged PR #1894: URL: https://github.com/apache/maven/pull/1894 -- 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] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897162#comment-17897162 ] Elliotte Rusty Harold commented on MDEP-965: By namespace you mean package name? > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Upgrade plugin versions to migrate to Doxia 2 [maven-parent]
slachiewicz commented on PR #212:
URL: https://github.com/apache/maven-parent/pull/212#issuecomment-2468120832
> > Okay, now all the properties from the parent with Doxia. We may have
here a few more.
> > Are we done with plugin updates for Doxia 2? Do you think this kind of
PR makes sense, or can we go with apache-parent update and release?
>
> See
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack#TowardsDoxia2.0.0Stack-Progress
>
> I would keep it for Maven Parent only before we broaden the scope.
>
> Progress
> Necessary changes performed at our (reporting) plugins
>
> Format: {repository}: {branch-for-doxia-1.x}; {branch-for-doxia-2.0.0}
>
> maven-help-plugin: maven-help-plugin-3.4.x; master
> maven-project-info-reports-plugin:
maven-project-info-reports-plugin-3.6.x; master
> maven-invoker-plugin: maven-invoker-plugin-3.7.x; mater
> maven-dependency-plugin: maven-dependency-plugin-3.7.x; master
> maven-plugin-tools: maven-plugin-tools-3.14.x; master
> maven-jxr: jxr-3.4.x; master
> maven-pmd-plugin: maven-pmd-plugin-3.24.x; master
> maven-javadoc-plugin: maven-javadoc-plugin-3.8.x; master
> maven-checkstyle-plugin: maven-checkstyle-plugin-3.4.x; master
> maven-surefire: surefire-3.4.x; master
> Note: other reporting plugin will not be upgraded.
--
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] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897175#comment-17897175 ] Michael Osipov commented on MDEP-965: - Yes > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897182#comment-17897182 ] Philipp Ottlinger commented on MNG-8372: Thanks for the context! To my mind the error message should point the user to exactly this explanation. Is: [WARNING] Legacy/insecurely encrypted password detected for server apache.snapshots.https Expected: [WARNING] Pre-Maven4 legacy encrypted password detected for server apache.releases.https - configure password encryption with the help of mvnenc to be compatible with Maven 4. WDYT? > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Upgrade plugin versions to migrate to Doxia 2 [maven-parent]
slawekjaranowski commented on PR #212: URL: https://github.com/apache/maven-parent/pull/212#issuecomment-2468201421 maven-help-plugin - doesn't has a reports, so do not depends on doxia -- 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-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897186#comment-17897186 ] Tamas Cservenak commented on MNG-8372: -- Sounds good to me. > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-965) org.glassfish:javax.json --> org.glassfish:jakarta.json
[ https://issues.apache.org/jira/browse/MDEP-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897104#comment-17897104 ] Michael Osipov commented on MDEP-965: - Attention, this likely also changes the namespace to jakarta. You should double check. > org.glassfish:javax.json --> org.glassfish:jakarta.json > --- > > Key: MDEP-965 > URL: https://issues.apache.org/jira/browse/MDEP-965 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > > apparently a few years ago the artifact ID changed. This is the new hotness > > org.glassfish > jakarta.json > 2.0.1 > test > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCLEAN-126) Use Path instead of File paradigm as much as possible
[
https://issues.apache.org/jira/browse/MCLEAN-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897111#comment-17897111
]
Peter De Maeyer commented on MCLEAN-126:
I made a PR with minimal "like for like" replacements, focusing on production
code. There are more opportunities to leverage the `Path` API further, for
example leveraging its built-in support for symlinks to replace the
roll-your-own symlink code with, but I left that out of scope of for now.
> Use Path instead of File paradigm as much as possible
> -
>
> Key: MCLEAN-126
> URL: https://issues.apache.org/jira/browse/MCLEAN-126
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> The code currently uses a combination of old {{File}} API and old {{Path}}.
> This is suboptimal, as it requires conversions back and forth. It would be
> better if we consolidated on the {{Path}} API as much as possible.
> Unfortunately, the Maven `@Parameter` injection only supports {{File}}
> fields, so we cannot replace it completely yet. Hopefully some day, Maven's
> `@Parameter` injection will also support {{Path}} fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MCLEAN-126) Use Path instead of File paradigm as much as possible
[
https://issues.apache.org/jira/browse/MCLEAN-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897111#comment-17897111
]
Peter De Maeyer edited comment on MCLEAN-126 at 11/11/24 8:21 AM:
--
I made a PR with minimal "like for like" replacements, focusing on production
code. There are more opportunities to leverage the {{Path}} API further, for
example leveraging its built-in support for symlinks to replace the
roll-your-own symlink code with, but I left that out of scope of for now.
was (Author: peterdm):
I made a PR with minimal "like for like" replacements, focusing on production
code. There are more opportunities to leverage the `Path` API further, for
example leveraging its built-in support for symlinks to replace the
roll-your-own symlink code with, but I left that out of scope of for now.
> Use Path instead of File paradigm as much as possible
> -
>
> Key: MCLEAN-126
> URL: https://issues.apache.org/jira/browse/MCLEAN-126
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> The code currently uses a combination of old {{File}} API and old {{Path}}.
> This is suboptimal, as it requires conversions back and forth. It would be
> better if we consolidated on the {{Path}} API as much as possible.
> Unfortunately, the Maven `@Parameter` injection only supports {{File}}
> fields, so we cannot replace it completely yet. Hopefully some day, Maven's
> `@Parameter` injection will also support {{Path}} fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-625) Rewrite homepage to reflect new resolver provider location in Maven4
Konrad Windszus created MRESOLVER-625: - Summary: Rewrite homepage to reflect new resolver provider location in Maven4 Key: MRESOLVER-625 URL: https://issues.apache.org/jira/browse/MRESOLVER-625 Project: Maven Resolver Issue Type: New Feature Reporter: Konrad Windszus The page at https://github.com/apache/maven-resolver/blob/maven-resolver-2.0.3/src/site/xdoc/index.xml still refers to a dedicated Maven 3 module. With Maven4 this dissolved and is now part of https://github.com/apache/maven/tree/master/impl/maven-impl. Would be good to adjust links and provide proper entry points. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MARTIFACT-79) Resuming `artifact:compare` in a multi-module project fails with NPE
Christopher Ng created MARTIFACT-79:
---
Summary: Resuming `artifact:compare` in a multi-module project
fails with NPE
Key: MARTIFACT-79
URL: https://issues.apache.org/jira/browse/MARTIFACT-79
Project: Maven Artifact Plugin
Issue Type: Bug
Components: artifact:compare
Affects Versions: 3.5.3
Reporter: Christopher Ng
{{artifact:compare}} throws an NPE if resumed in a multi-module project, e.g.
{code:java}
$ mvn clean verify artifact:compare -rf :my-module
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare (default-cli) on
project my-module: Execution default-cli of goal
org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare failed: Cannot
invoke "org.apache.maven.project.MavenProject.getBasedir()" because the return
value of
"org.apache.maven.plugins.artifact.buildinfo.CompareMojo.getExecutionRoot()" is
null -> [Help 1]
... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-626) Rewrite homepage to reflect new resolver provider location in Maven4
Konrad Windszus created MRESOLVER-626: - Summary: Rewrite homepage to reflect new resolver provider location in Maven4 Key: MRESOLVER-626 URL: https://issues.apache.org/jira/browse/MRESOLVER-626 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Konrad Windszus The Maven4 resolver provider is now part of https://github.com/apache/maven/tree/master/impl/maven-impl which makes it harder to identify the pieces which make up the resolver provider parts. There should be some more clarification what package/class is relevant in this context in https://github.com/apache/maven-resolver/blob/maven-resolver-2.0.3/src/site/xdoc/index.xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARTIFACT-79) Resuming `artifact:compare` in a multi-module project fails with NPE
[
https://issues.apache.org/jira/browse/MARTIFACT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MARTIFACT-79:
Labels: pull-request-available (was: )
> Resuming `artifact:compare` in a multi-module project fails with NPE
>
>
> Key: MARTIFACT-79
> URL: https://issues.apache.org/jira/browse/MARTIFACT-79
> Project: Maven Artifact Plugin
> Issue Type: Bug
> Components: artifact:compare
>Affects Versions: 3.5.3
>Reporter: Christopher Ng
>Priority: Major
> Labels: pull-request-available
>
> {{artifact:compare}} throws an NPE if resumed in a multi-module project, e.g.
> {code:java}
> $ mvn clean verify artifact:compare -rf :my-module
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare (default-cli) on
> project my-module: Execution default-cli of goal
> org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare failed: Cannot
> invoke "org.apache.maven.project.MavenProject.getBasedir()" because the
> return value of
> "org.apache.maven.plugins.artifact.buildinfo.CompareMojo.getExecutionRoot()"
> is null -> [Help 1]
> ... {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MARTIFACT-79) Resuming `artifact:compare` in a multi-module project fails with NPE
[
https://issues.apache.org/jira/browse/MARTIFACT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897149#comment-17897149
]
ASF GitHub Bot commented on MARTIFACT-79:
-
facboy opened a new pull request, #70:
URL: https://github.com/apache/maven-artifact-plugin/pull/70
When resuming a multi-module build, the `executionRoot` may not be included
in `session.projects`. `session.allProjects` contains all projects in the
reactor build.
> Resuming `artifact:compare` in a multi-module project fails with NPE
>
>
> Key: MARTIFACT-79
> URL: https://issues.apache.org/jira/browse/MARTIFACT-79
> Project: Maven Artifact Plugin
> Issue Type: Bug
> Components: artifact:compare
>Affects Versions: 3.5.3
>Reporter: Christopher Ng
>Priority: Major
>
> {{artifact:compare}} throws an NPE if resumed in a multi-module project, e.g.
> {code:java}
> $ mvn clean verify artifact:compare -rf :my-module
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare (default-cli) on
> project my-module: Execution default-cli of goal
> org.apache.maven.plugins:maven-artifact-plugin:3.5.3:compare failed: Cannot
> invoke "org.apache.maven.project.MavenProject.getBasedir()" because the
> return value of
> "org.apache.maven.plugins.artifact.buildinfo.CompareMojo.getExecutionRoot()"
> is null -> [Help 1]
> ... {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCLEAN-125) Don't clean files put in the output directory by previous modules during the same build
[
https://issues.apache.org/jira/browse/MCLEAN-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MCLEAN-125:
---
Summary: Don't clean files put in the output directory by previous modules
during the same build (was: Clean all modules in multi-module project
beforehand)
> Don't clean files put in the output directory by previous modules during the
> same build
> ---
>
> Key: MCLEAN-125
> URL: https://issues.apache.org/jira/browse/MCLEAN-125
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> In complex multi-module projects with custom plugins, there is often a
> situation where one module populates the {{target/}} directory of _another_
> (typically sibling or parent) module. While I agree that is not ideal and not
> recommended practice, it is sometimes the only way to work around limitations
> in plugins or build setups.
> In such a case, one sooner or later bumps into the situation where {{mvn
> clean verify}} fails while {{mvn clean; mvn verify}} (note the semicolon)
> succeeds. The reason is that in the first case the {{target/}} directory is
> cleared at the start of every module's build life cycle, clearing any needed
> files that a previous module has put there. The workaround {{mvn clean; mvn
> verify}} works, but it requires understanding of the user to correctly build
> the multi-module project, which is suboptimal. It would be better if that
> knowledge were embedded in the build script.
> To better support these situations, it would be useful to have for example a
> {{cleanAtStart}} option to the {{maven-clean-plugin}} that would clean _all_
> modules during the "clean" phase of the first one. It would be similar and
> complementary to the {{installAtEnd}} option of the {{maven-install-plugin}},
> or the {{deployAtEnd}} option of the {{maven-deploy-plugin}}. This would move
> the responsibility for correctly cleaning the project from the user to the
> build, where it belongs. Then users could do a plain {{mvn clean install}}
> while trusting the build script to take care of any of its own multi-module
> intricacies.
> I did some preliminary analysis of what it would take to implement this,
> using the {{maven-invoker-plugin}}'s {{installAtEnd}} as inspiration, but
> it's not so simple. The advantage that the {{maven-install-plugin}} has is
> that it can visit all the plugin executions of all the modules in a normal
> way and merely needs to defer the actual installation. Here, for the
> {{maven-clean-plugin}}, it is different: it needs to clean modules at the
> very start, before anything else, based on information that is not available
> yet 'coz the executions of the next modules hasn't been visited yet.
> Another idea for an implementation I had was to monitor the file system for
> files that were added during the build (by other modules) and exclude those
> from cleaning, but that is also (too) complicated to implement.
> Anyway, difficulty of implementation aside, I think this would be a good
> feature that would complement existing features such as {{installAtEnd}} and
> {{deployAtEnd}}. Ideally in a 3.x version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MINSTALL-206) Ability to skip execution by setting phase to none
Gili created MINSTALL-206:
-
Summary: Ability to skip execution by setting phase to none
Key: MINSTALL-206
URL: https://issues.apache.org/jira/browse/MINSTALL-206
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 3.1.3
Reporter: Gili
Following up on MINSTALL-73, if a module does not contain a "src" directory
then:
{code:java}
org.apache.maven.plugins
maven-install-plugin
default-cli
install
none
true
{code}
Works fine but if you run skip=true, then you'll get this error:
{quote}The packaging plugin for project deployment did not assign a file to the
build artifact
{quote}
Expected behavior: phase=none should be sufficient to skip execution of this
plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897202#comment-17897202
]
Piotr Zygielo commented on MINSTALL-205:
MNG-8186
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3, 4.0.0-beta-1
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> ePer the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Upgrade plugin versions to migrate to Doxia 2 [maven-parent]
michael-o commented on PR #212: URL: https://github.com/apache/maven-parent/pull/212#issuecomment-2468381344 > maven-help-plugin - doesn't has a reports, so do not depends on doxia Because it uses the Maven Reporting API. -- 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
Re: [PR] [MNG-8372] Augment error message to give users more context when running into deprecated encryption warning [maven]
ottlinger commented on PR #1898: URL: https://github.com/apache/maven/pull/1898#issuecomment-2468517339 @cstamas how come that Maven does not define a defaultGoal in its pom? :) I did not want to add it in this MR, was just wondering. -- 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
Re: [PR] [MNG-8372] Augment error message to give users more context when running into deprecated encryption warning [maven]
ottlinger commented on PR #1898: URL: https://github.com/apache/maven/pull/1898#issuecomment-2468529088 The failing test has nothing to do with my change but is a problem within the GitHubAction Infra structure (network error to reach Maven repo). -- 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] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897198#comment-17897198
]
Gili commented on MINSTALL-205:
---
{{I am building with mvnw --strict-checksums --threads=1C}}
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.1.3
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> Per the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897199#comment-17897199
]
Gili commented on MINSTALL-205:
---
When I try version 4.0.0-beta-1 I get:
{quote}[WARNING] * Your build is requesting parallel execution, but this
*
[WARNING] * project contains the following plugin(s) that have goals not *
[WARNING] * marked as thread-safe to support parallel execution. *
[WARNING] * While this /may/ work fine, please look for plugin updates *
[WARNING] * and/or request plugins be made thread-safe. *
[WARNING] * If reporting an issue, report it against the plugin in *
[WARNING] * question, not against Apache Maven. *
[WARNING] *
[WARNING] The following goals are not marked as thread-safe in root:
[WARNING] org.apache.maven.plugins:maven-install-plugin:4.0.0-beta-1:install
[WARNING] *
{quote}
This seems to imply that either the documentation is wrong or the
implementation is wrong. The documentation I am looking at is
[https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html] and
https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.1.3
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> Per the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-205) Warning when using install-file in parallel builds
[
https://issues.apache.org/jira/browse/MINSTALL-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MINSTALL-205:
--
Component/s: install:install
install:install-file
> Warning when using install-file in parallel builds
> --
>
> Key: MINSTALL-205
> URL: https://issues.apache.org/jira/browse/MINSTALL-205
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install, install:install-file
>Affects Versions: 3.1.3
> Environment: Maven 3.9.9
>Reporter: Gili
>Priority: Major
>
> Per the online documentation, `install-file`:
> * Executes as an aggregator goal.
> * The goal is thread-safe and supports parallel builds.
> But when I use it in a parallel build I get this warning:
>
> {{[WARNING]
> *}}
> {{[WARNING] * The
> *}}
> {{[WARNING] *
> org.apache.maven.plugins:maven-install-plugin:3.1.3:install-file *}}
> {{[WARNING] * aggregator mojo is already being executed in this parallel
> *}}
> {{[WARNING] * build, those kind of mojos require exclusive access to
> *}}
> {{[WARNING] * reactor to prevent race conditions. This mojo execution will
> *}}
> {{[WARNING] * be blocked until the aggregator mojo is done.
> *}}
> {{[WARNING]
> *}}
>
> Expected behavior: If the plugin is safe for use in parallel builds, it
> should not trigger this warning.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8373) Extract resolver related code into its own impl submodule
[ https://issues.apache.org/jira/browse/MNG-8373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MNG-8373: - Description: As https://github.com/apache/maven/tree/master/compat/maven-resolver-provider has a substantial amount of classes and also very limited interaction with other core classes, it would be good to re-extract the resolver related ones into a dedicated submodule. In the best case this would allow to get rid of all resolver dependencies (at least resolver-spi) from Core. (was: As https://github.com/apache/maven/tree/master/compat/maven-resolver-provider has a substantial amount of classes and also very limited interaction with other core classes, it would be good to re-extract the resolver related ones into a dedicated submodule. In the best case this would allow to get rid of all resolved dependencies from Core.) > Extract resolver related code into its own impl submodule > - > > Key: MNG-8373 > URL: https://issues.apache.org/jira/browse/MNG-8373 > Project: Maven > Issue Type: Sub-task > Components: Core >Reporter: Konrad Windszus >Priority: Major > > As https://github.com/apache/maven/tree/master/compat/maven-resolver-provider > has a substantial amount of classes and also very limited interaction with > other core classes, it would be good to re-extract the resolver related ones > into a dedicated submodule. In the best case this would allow to get rid of > all resolver dependencies (at least resolver-spi) from Core. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897213#comment-17897213 ] Philipp Ottlinger commented on MNG-8372: [~cstamas] can you do the change or shall I start a fork/PR via Github? > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8372) [WARNING] Legacy/insecurely encrypted password detected for server - what can/shall I do about it?
[ https://issues.apache.org/jira/browse/MNG-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897215#comment-17897215 ] Tamas Cservenak commented on MNG-8372: -- Please, do so! A PR via Github is welcome! > [WARNING] Legacy/insecurely encrypted password detected for server - what > can/shall I do about it? > -- > > Key: MNG-8372 > URL: https://issues.apache.org/jira/browse/MNG-8372 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-5 >Reporter: Philipp Ottlinger >Priority: Major > > I ran into above error message and asked myself what to do > the error message does not tell me anything. > https://maven.apache.org/guides/mini/guide-encryption.html > is the way I encrypted my password. > Can someone clarify the implication of this error message? Is there a page > that tells me how to properly/safely configure my credentials. To my mind it > would be helpful to have a before/after example to explicitly show where the > problem is and how to circumvent it. > Thanks > $ ./mvnw > Apache Maven 4.0.0-beta-5 (6e78fcf6f5e76422c0eb358cd11f0c231ecafbad) > Maven home: /home/me/.m2/wrapper/dists/apache-maven-4.0.0-beta-5/4431294f > Java version: 21.0.5, vendor: Oracle Corporation, runtime: /home/me/jdk-21.0.5 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "5.15.0-125-generic", arch: "amd64", family: "unix" > [WARNING] Legacy/insecurely encrypted password detected for server > srv.snapshots.https > [WARNING] Legacy/insecurely encrypted password detected for server > srv.releases.https > [INFO] Scanning for projects... -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIATOOLS-88] Optionally remove input files after conversion [maven-doxia-converter]
kwin merged PR #85: URL: https://github.com/apache/maven-doxia-converter/pull/85 -- 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] [Resolved] (DOXIATOOLS-88) Optionally remove input files after conversion
[
https://issues.apache.org/jira/browse/DOXIATOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIATOOLS-88.
---
Resolution: Fixed
Fixed in
https://github.com/apache/maven-doxia-converter/commit/c9053c39dc9fd89b2fc9f9cc5e6e98c32b98a86f.
> Optionally remove input files after conversion
> --
>
> Key: DOXIATOOLS-88
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-88
> Project: Maven Doxia Tools
> Issue Type: Improvement
> Components: Doxia Converter
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: doxia-converter-1.4
>
>
> Currently if a directory is given to the {{in}} parameter it is only read.
> However usually after conversion you want to remove the original input files.
> There should be a dedicated flag which allows to achieve that automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIATOOLS-88) Optionally remove input files after conversion
[
https://issues.apache.org/jira/browse/DOXIATOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897232#comment-17897232
]
ASF GitHub Bot commented on DOXIATOOLS-88:
--
kwin merged PR #85:
URL: https://github.com/apache/maven-doxia-converter/pull/85
> Optionally remove input files after conversion
> --
>
> Key: DOXIATOOLS-88
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-88
> Project: Maven Doxia Tools
> Issue Type: Improvement
> Components: Doxia Converter
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: doxia-converter-1.4
>
>
> Currently if a directory is given to the {{in}} parameter it is only read.
> However usually after conversion you want to remove the original input files.
> There should be a dedicated flag which allows to achieve that automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIATOOLS-88] Optionally remove input files after conversion [maven-doxia-converter]
kwin commented on PR #85: URL: https://github.com/apache/maven-doxia-converter/pull/85#issuecomment-2468641920 > I thought about the possibility to use git mv to keep git history Good idea, I tracked this now in https://issues.apache.org/jira/browse/DOXIATOOLS-90. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (DOXIATOOLS-90) Optionally write converted files to input files and then rename via git mv
Konrad Windszus created DOXIATOOLS-90: - Summary: Optionally write converted files to input files and then rename via git mv Key: DOXIATOOLS-90 URL: https://issues.apache.org/jira/browse/DOXIATOOLS-90 Project: Maven Doxia Tools Issue Type: New Feature Components: Doxia Converter Reporter: Konrad Windszus Using [git mv|https://git-scm.com/docs/git-mv] allows to keep the file's history (although using the blame feature won't work as the line numbers are off after conversion). This is reasonable to use when the input files are managed with Git and the converted ones should still be. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIATOOLS-88) Optionally remove input files after conversion
[
https://issues.apache.org/jira/browse/DOXIATOOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897234#comment-17897234
]
ASF GitHub Bot commented on DOXIATOOLS-88:
--
kwin commented on PR #85:
URL:
https://github.com/apache/maven-doxia-converter/pull/85#issuecomment-2468641920
> I thought about the possibility to use git mv to keep git history
Good idea, I tracked this now in
https://issues.apache.org/jira/browse/DOXIATOOLS-90.
> Optionally remove input files after conversion
> --
>
> Key: DOXIATOOLS-88
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-88
> Project: Maven Doxia Tools
> Issue Type: Improvement
> Components: Doxia Converter
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: doxia-converter-1.4
>
>
> Currently if a directory is given to the {{in}} parameter it is only read.
> However usually after conversion you want to remove the original input files.
> There should be a dedicated flag which allows to achieve that automatically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8369) Empty .mvn/extensions.xml should not lead to error
[
https://issues.apache.org/jira/browse/MNG-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897261#comment-17897261
]
Benjamin Marwell commented on MNG-8369:
---
Yes, I will update the title.
> Empty .mvn/extensions.xml should not lead to error
> --
>
> Key: MNG-8369
> URL: https://issues.apache.org/jira/browse/MNG-8369
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.9
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: extensions
>
> {{{}touch{}}}ing an empty file {{.mvn/extensions.xml}} will lead to:
>
> {code}
> + ./mvnw --no-transfer-progress verify
> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/user/.m2/wrapper/dists/apache-maven-3.9.9/490815c6
> Java version: 21.0.4, vendor: IBM Corporation, runtime:
> /home/user/jenkins/tools/hudson.model.JDK/jdk21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.14.21-150500.55.68-default", arch: "amd64",
> family: "unix"
> [ERROR] Error executing Maven.
> java.io.EOFException: input contained no data
> at org.codehaus.plexus.util.xml.pull.MXParser.fillBuf (MXParser.java:3898)
> at org.codehaus.plexus.util.xml.pull.MXParser.more (MXParser.java:3980)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog (MXParser.java:1774)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl (MXParser.java:1757)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1375)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:586)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:613)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:628)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:659)
> at org.apache.maven.cli.MavenCli.readCoreExtensionsDescriptor
> (MavenCli.java:770)
> at org.apache.maven.cli.MavenCli.loadCoreExtensions (MavenCli.java:713)
> at org.apache.maven.cli.MavenCli.container (MavenCli.java:627)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:277)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:586)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:255)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:201)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:361)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8369) Empty .mvn/extensions.xml should not just print EOFException
[
https://issues.apache.org/jira/browse/MNG-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell reassigned MNG-8369:
-
Assignee: Benjamin Marwell
> Empty .mvn/extensions.xml should not just print EOFException
>
>
> Key: MNG-8369
> URL: https://issues.apache.org/jira/browse/MNG-8369
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.9
>Reporter: Benjamin Marwell
>Assignee: Benjamin Marwell
>Priority: Major
> Labels: extensions
>
> {{{}touch{}}}ing an empty file {{.mvn/extensions.xml}} will lead to:
>
> {code}
> + ./mvnw --no-transfer-progress verify
> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/user/.m2/wrapper/dists/apache-maven-3.9.9/490815c6
> Java version: 21.0.4, vendor: IBM Corporation, runtime:
> /home/user/jenkins/tools/hudson.model.JDK/jdk21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.14.21-150500.55.68-default", arch: "amd64",
> family: "unix"
> [ERROR] Error executing Maven.
> java.io.EOFException: input contained no data
> at org.codehaus.plexus.util.xml.pull.MXParser.fillBuf (MXParser.java:3898)
> at org.codehaus.plexus.util.xml.pull.MXParser.more (MXParser.java:3980)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog (MXParser.java:1774)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl (MXParser.java:1757)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1375)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:586)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:613)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:628)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:659)
> at org.apache.maven.cli.MavenCli.readCoreExtensionsDescriptor
> (MavenCli.java:770)
> at org.apache.maven.cli.MavenCli.loadCoreExtensions (MavenCli.java:713)
> at org.apache.maven.cli.MavenCli.container (MavenCli.java:627)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:277)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:586)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:255)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:201)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:361)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8369) Empty .mvn/extensions.xml should not just print EOFException
[
https://issues.apache.org/jira/browse/MNG-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell updated MNG-8369:
--
Summary: Empty .mvn/extensions.xml should not just print EOFException
(was: Empty .mvn/extensions.xml should not lead to error)
> Empty .mvn/extensions.xml should not just print EOFException
>
>
> Key: MNG-8369
> URL: https://issues.apache.org/jira/browse/MNG-8369
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.9
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: extensions
>
> {{{}touch{}}}ing an empty file {{.mvn/extensions.xml}} will lead to:
>
> {code}
> + ./mvnw --no-transfer-progress verify
> Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/user/.m2/wrapper/dists/apache-maven-3.9.9/490815c6
> Java version: 21.0.4, vendor: IBM Corporation, runtime:
> /home/user/jenkins/tools/hudson.model.JDK/jdk21
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.14.21-150500.55.68-default", arch: "amd64",
> family: "unix"
> [ERROR] Error executing Maven.
> java.io.EOFException: input contained no data
> at org.codehaus.plexus.util.xml.pull.MXParser.fillBuf (MXParser.java:3898)
> at org.codehaus.plexus.util.xml.pull.MXParser.more (MXParser.java:3980)
> at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog (MXParser.java:1774)
> at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl (MXParser.java:1757)
> at org.codehaus.plexus.util.xml.pull.MXParser.next (MXParser.java:1375)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:586)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:613)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:628)
> at
> org.apache.maven.cli.internal.extension.model.io.xpp3.CoreExtensionsXpp3Reader.read
> (CoreExtensionsXpp3Reader.java:659)
> at org.apache.maven.cli.MavenCli.readCoreExtensionsDescriptor
> (MavenCli.java:770)
> at org.apache.maven.cli.MavenCli.loadCoreExtensions (MavenCli.java:713)
> at org.apache.maven.cli.MavenCli.container (MavenCli.java:627)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:277)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:586)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:255)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:201)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:361)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCLEAN-125) Don't clean files put in the output directory by previous modules during the same build
[
https://issues.apache.org/jira/browse/MCLEAN-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MCLEAN-125:
---
Description:
In complex multi-module projects with custom plugins, there is often a
situation where one module populates the {{target/}} directory of _another_
(typically sibling or parent) module. While I agree that is not ideal and not
recommended practice, it is sometimes the only way to work around limitations
in plugins or build setups. Because of its design, the current
{{maven-clean-plugin}} deletes these files too, breaking the build when doing a
{{mvn clean verify}}.
The workaround in such a case is to use {{mvn clean; mvn verify}} instead, note
the semicolon. The reason is that in the first case the {{target/}} directory
is cleared at the start of every module's build life cycle, clearing any needed
files that a previous module has put there. The workaround {{mvn clean; mvn
verify}} works, but it requires understanding of the user to correctly build
the multi-module project, which is suboptimal. It would be better if that
knowledge were embedded in the build script.
h3. Idea 1
To better support these situations, it would be useful to have for example a
{{cleanAtStart}} option to the {{maven-clean-plugin}} that would clean _all_
modules during the "clean" phase of the first one. It would be similar and
complementary to the {{installAtEnd}} option of the {{maven-install-plugin}},
or the {{deployAtEnd}} option of the {{maven-deploy-plugin}}. This would move
the responsibility for correctly cleaning the project from the user to the
build, where it belongs. Then users could do a plain {{mvn clean install}}
while trusting the build script to take care of any of its own multi-module
intricacies.
I did some preliminary analysis of what it would take to implement this, using
the {{maven-invoker-plugin}}'s {{installAtEnd}} as inspiration, but it's not so
simple. The advantage that the {{maven-install-plugin}} has is that it can
visit all the plugin executions of all the modules in a normal way and merely
needs to defer the actual installation. And even that is a hack to work around
the fundamental limitation that Maven itself has no support for this. Here, for
the {{maven-clean-plugin}}, it is different: it needs to clean modules at the
very start, before anything else, based on information that is not available
yet 'coz the executions of the next modules hasn't been visited yet.
Conclusion: it is impossible to implement due to lack of support from the Maven
framework.
h3. Idea 2
Another idea is to only delete files based on modification time < build time,
for example by configuring the Clean plugin with an {{excludeBuildFiles}}
parameter. This would effectively delete files which were the result of
_previous_ builds, but _not_ files which are the result of the _current_ build.
This works assuming that:
* Modification times of files produced in output directories are not
manipulated. _If_ they are manipulated, this breaks the feature and files may
be deleted while they're not supposed to, or the other way around.
* Modification time is enabled on the file system and are granular enough to
separate consecutive builds. Imagine for example the modification times are not
granular enough so that two consecutive builds have the same build timestamp.
That would mean files are not deleted when they're supposed to. Generally, on
Linux timestamps have millisecond, and on Windows at least second precision
AFAIK, which is generally good enough.
Conclusion: this works quite well in practice. I'll create a PR for this.
was:
In complex multi-module projects with custom plugins, there is often a
situation where one module populates the {{target/}} directory of _another_
(typically sibling or parent) module. While I agree that is not ideal and not
recommended practice, it is sometimes the only way to work around limitations
in plugins or build setups.
In such a case, one sooner or later bumps into the situation where {{mvn clean
verify}} fails while {{mvn clean; mvn verify}} (note the semicolon) succeeds.
The reason is that in the first case the {{target/}} directory is cleared at
the start of every module's build life cycle, clearing any needed files that a
previous module has put there. The workaround {{mvn clean; mvn verify}} works,
but it requires understanding of the user to correctly build the multi-module
project, which is suboptimal. It would be better if that knowledge were
embedded in the build script.
To better support these situations, it would be useful to have for example a
{{cleanAtStart}} option to the {{maven-clean-plugin}} that would clean _all_
modules during the "clean" phase of the first one. It would be similar and
complementary to the {{installAtEnd}} option of the {{maven-install-plugin}},
or the {{deployAtEnd}} option of the {{ma
[jira] [Commented] (MNG-8371) Document Deprecation
[ https://issues.apache.org/jira/browse/MNG-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897263#comment-17897263 ] Elliotte Rusty Harold commented on MNG-8371: also possible some of these classes shouldn't be deprecated at all. ArtifactFactory appears to have been deprecated circa 2009 > Document Deprecation > > > Key: MNG-8371 > URL: https://issues.apache.org/jira/browse/MNG-8371 > Project: Maven > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > A lot of classes and methods in the API are deprecated. E.g. ArtifactFactory > ' > https://maven.apache.org/ref/3.9.9/maven-core/apidocs/org/apache/maven/artifact/factory/ArtifactFactory.html > However, the deprecation is simply a tag. There's no info on what to replace > them with. Add this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCLEAN-125) Don't clean files put in the output directory by previous modules during the same build
[
https://issues.apache.org/jira/browse/MCLEAN-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897265#comment-17897265
]
Peter De Maeyer commented on MCLEAN-125:
I hope this gets merged into the 3.x branch, in which case I believe this
warrants a 3.5.0 since it adds a configuration parameter, which is additional
(but compatible) API.
> Don't clean files put in the output directory by previous modules during the
> same build
> ---
>
> Key: MCLEAN-125
> URL: https://issues.apache.org/jira/browse/MCLEAN-125
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.4.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> In complex multi-module projects with custom plugins, there is often a
> situation where one module populates the {{target/}} directory of _another_
> (typically sibling or parent) module. While I agree that is not ideal and not
> recommended practice, it is sometimes the only way to work around limitations
> in plugins or build setups. Because of its design, the current
> {{maven-clean-plugin}} deletes these files too, breaking the build when doing
> a {{mvn clean verify}}.
> The workaround in such a case is to use {{mvn clean; mvn verify}} instead,
> note the semicolon. The reason is that in the first case the {{target/}}
> directory is cleared at the start of every module's build life cycle,
> clearing any needed files that a previous module has put there. The
> workaround {{mvn clean; mvn verify}} works, but it requires understanding of
> the user to correctly build the multi-module project, which is suboptimal. It
> would be better if that knowledge were embedded in the build script.
> h3. Idea 1
> To better support these situations, it would be useful to have for example a
> {{cleanAtStart}} option to the {{maven-clean-plugin}} that would clean _all_
> modules during the "clean" phase of the first one. It would be similar and
> complementary to the {{installAtEnd}} option of the {{maven-install-plugin}},
> or the {{deployAtEnd}} option of the {{maven-deploy-plugin}}. This would move
> the responsibility for correctly cleaning the project from the user to the
> build, where it belongs. Then users could do a plain {{mvn clean install}}
> while trusting the build script to take care of any of its own multi-module
> intricacies.
> I did some preliminary analysis of what it would take to implement this,
> using the {{maven-invoker-plugin}}'s {{installAtEnd}} as inspiration, but
> it's not so simple. The advantage that the {{maven-install-plugin}} has is
> that it can visit all the plugin executions of all the modules in a normal
> way and merely needs to defer the actual installation. And even that is a
> hack to work around the fundamental limitation that Maven itself has no
> support for this. Here, for the {{maven-clean-plugin}}, it is different: it
> needs to clean modules at the very start, before anything else, based on
> information that is not available yet 'coz the executions of the next modules
> hasn't been visited yet.
> Conclusion: it is impossible to implement due to lack of support from the
> Maven framework.
> h3. Idea 2
> Another idea is to only delete files based on modification time < build time,
> for example by configuring the Clean plugin with an {{excludeBuildFiles}}
> parameter. This would effectively delete files which were the result of
> _previous_ builds, but _not_ files which are the result of the _current_
> build. This works assuming that:
> * Modification times of files produced in output directories are not
> manipulated. _If_ they are manipulated, this breaks the feature and files may
> be deleted while they're not supposed to, or the other way around.
> * Modification time is enabled on the file system and are granular enough to
> separate consecutive builds. Imagine for example the modification times are
> not granular enough so that two consecutive builds have the same build
> timestamp. That would mean files are not deleted when they're supposed to.
> Generally, on Linux timestamps have millisecond, and on Windows at least
> second precision AFAIK, which is generally good enough.
> Conclusion: this works quite well in practice. I'll create a PR for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
