[jira] [Updated] (MPMD-381) MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows
[
https://issues.apache.org/jira/browse/MPMD-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPMD-381:
Description:
{noformat}
Error: 'other' has different root
Error:
Error: To see the full stack trace of the errors, re-run Maven with the -e
switch.
Error: Re-run Maven using the -X switch to enable full debug logging.
Running post-build script:
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy
Assertion failed:
assert pmdXml.exists()
| |
| false
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at Script1.run(Script1.groovy:21)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436)
at
org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431)
at
org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
*** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml ***
Error: -
Error:
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 44, Failed: 1, Errors: 0, Skipped: 4
[INFO] -
{noformat}
was:
Error: 'other' has different root
Error:
Error: To see the full stack trace of the errors, re-run Maven with the -e
switch.
Error: Re-run Maven using the -X switch to enable full debug logging.
Running post-build script:
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy
Assertion failed:
{noformat}
assert pmdXml.exists()
| |
| false
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at Script1.run(Script1.groovy:21)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436)
at
org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431)
at
org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
*** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml ***
Error: -
Error:
[INFO]
[jira] [Updated] (MPMD-381) MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows
[
https://issues.apache.org/jira/browse/MPMD-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPMD-381:
Description:
Error: 'other' has different root
Error:
Error: To see the full stack trace of the errors, re-run Maven with the -e
switch.
Error: Re-run Maven using the -X switch to enable full debug logging.
Running post-build script:
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy
Assertion failed:
{noformat}
assert pmdXml.exists()
| |
| false
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at Script1.run(Script1.groovy:21)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436)
at
org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431)
at
org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
*** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml ***
Error: -
Error:
[INFO] -
[INFO] Build Summary:
[INFO] Passed: 44, Failed: 1, Errors: 0, Skipped: 4
[INFO] -
{noformat}
was:
Error: 'other' has different root
Error:
Error: To see the full stack trace of the errors, re-run Maven with the -e
switch.
Error: Re-run Maven using the -X switch to enable full debug logging.
Running post-build script:
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy
Assertion failed:
assert pmdXml.exists()
| |
| false
D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml
at
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670)
at Script1.run(Script1.groovy:21)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436)
at
org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721)
at
org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431)
at
org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
*** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml ***
Error: -
Error:
[INFO] ---
[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737000#comment-17737000
]
ASF GitHub Bot commented on MCOMPILER-446:
--
bdecaestecker opened a new pull request, #196:
URL: https://github.com/apache/maven-compiler-plugin/pull/196
…ent if specified
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/MCOMPILER) 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 `[MCOMPILER-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MCOMPILER-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in 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 integration tests successfully (`mvn -Prun-its clean
verify`).
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).
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] bdecaestecker opened a new pull request, #196: [MCOMPILER-446] - Compiler is crashing while setting JPMS module version
bdecaestecker opened a new pull request, #196: URL: https://github.com/apache/maven-compiler-plugin/pull/196 …ent if specified 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/MCOMPILER) 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 `[MCOMPILER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCOMPILER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in 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 integration tests successfully (`mvn -Prun-its clean verify`). 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). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-clean-plugin] dependabot[bot] opened a new pull request, #29: Bump plexus-xml from 4.0.0 to 4.0.1
dependabot[bot] opened a new pull request, #29: URL: https://github.com/apache/maven-clean-plugin/pull/29 Bumps [plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 4.0.0 to 4.0.1. Commits https://github.com/codehaus-plexus/plexus-xml/commit/bcb6981e2a9c635d024e0422de2a997a00ffdd8e";>bcb6981 [maven-release-plugin] prepare release plexus-xml-4.0.1 https://github.com/codehaus-plexus/plexus-xml/commit/d227a49f0f9b552a61b2aaac3bbe2c722ce06fea";>d227a49 Fix detection of invalid spaces in prolog (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/20";>#20) https://github.com/codehaus-plexus/plexus-xml/commit/27d6127d3196d09263d8fe0f445b9d83f6ccfb75";>27d6127 pom.mxl and site.xml cleanup https://github.com/codehaus-plexus/plexus-xml/commit/62f50bc46c7b51d51a25541dfe0a502063dc1fc3";>62f50bc [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.0...plexus-xml-4.0.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 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] (MNG-7820) Remove dependency on plexus-utils
[ https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736987#comment-17736987 ] Guillaume Nodet commented on MNG-7820: -- We don't have any dependency on commons-lang, so I don't think we should add one just for 1 or 2 methods. > Remove dependency on plexus-utils > - > > Key: MNG-7820 > URL: https://issues.apache.org/jira/browse/MNG-7820 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-parent] dependabot[bot] opened a new pull request, #131: Bump plexus-xml from 4.0.0 to 4.0.1
dependabot[bot] opened a new pull request, #131: URL: https://github.com/apache/maven-parent/pull/131 Bumps [plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 4.0.0 to 4.0.1. Commits https://github.com/codehaus-plexus/plexus-xml/commit/bcb6981e2a9c635d024e0422de2a997a00ffdd8e";>bcb6981 [maven-release-plugin] prepare release plexus-xml-4.0.1 https://github.com/codehaus-plexus/plexus-xml/commit/d227a49f0f9b552a61b2aaac3bbe2c722ce06fea";>d227a49 Fix detection of invalid spaces in prolog (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/20";>#20) https://github.com/codehaus-plexus/plexus-xml/commit/27d6127d3196d09263d8fe0f445b9d83f6ccfb75";>27d6127 pom.mxl and site.xml cleanup https://github.com/codehaus-plexus/plexus-xml/commit/62f50bc46c7b51d51a25541dfe0a502063dc1fc3";>62f50bc [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.0...plexus-xml-4.0.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 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] (MNG-7820) Remove dependency on plexus-utils
[ https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736975#comment-17736975 ] Zhongming Hua commented on MNG-7820: [~gnodet] StringUtils can no longer use common components such as Apache commons? > Remove dependency on plexus-utils > - > > Key: MNG-7820 > URL: https://issues.apache.org/jira/browse/MNG-7820 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-381) MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows
[ https://issues.apache.org/jira/browse/MPMD-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736931#comment-17736931 ] Elliotte Rusty Harold commented on MPMD-381: see https://github.com/apache/maven-pmd-plugin/pull/133 which is a trivial docs change that should have no effect on any integration test. Same error on other PRs. > MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows > - > > Key: MPMD-381 > URL: https://issues.apache.org/jira/browse/MPMD-381 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Error: 'other' has different root > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Running post-build script: > D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy > Assertion failed: > assert pmdXml.exists() >| | >| false > > D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml > at > org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436) > at > org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670) > at Script1.run(Script1.groovy:21) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461) > at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436) > at > org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76) > at > org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236) > at > org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161) > at > org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154) > at > org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129) > at > org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721) > at > org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431) > at > org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:833) > *** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml *** > Error: - > Error: > [INFO] - > [INFO] Build Summary: > [INFO] Passed: 44, Failed: 1, Errors: 0, Skipped: 4 > [INFO] - -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-381) MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows
Elliotte Rusty Harold created MPMD-381: -- Summary: MPMD-323-ruleset-basedir-jgitver is broken or flaky on JDK 17 windows Key: MPMD-381 URL: https://issues.apache.org/jira/browse/MPMD-381 Project: Maven PMD Plugin Issue Type: Bug Reporter: Elliotte Rusty Harold Error: 'other' has different root Error: Error: To see the full stack trace of the errors, re-run Maven with the -e switch. Error: Re-run Maven using the -X switch to enable full debug logging. Running post-build script: D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\verify.groovy Assertion failed: assert pmdXml.exists() | | | false D:\a\maven-pmd-plugin\maven-pmd-plugin\target\it\MPMD-323-ruleset-basedir-jgitver\target\pmd.xml at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:436) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670) at Script1.run(Script1.groovy:21) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:427) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:461) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:436) at org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:76) at org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:236) at org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:161) at org.apache.maven.plugins.invoker.AbstractInvokerMojo.runPostBuildHook(AbstractInvokerMojo.java:2154) at org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:2129) at org.apache.maven.plugins.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1721) at org.apache.maven.plugins.invoker.AbstractInvokerMojo.lambda$runBuilds$4(AbstractInvokerMojo.java:1431) at org.apache.maven.plugins.invoker.JobExecutor.lambda$null$1(JobExecutor.java:69) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) *** end build.log for: MPMD-323-ruleset-basedir-jgitver\pom.xml *** Error: - Error: [INFO] - [INFO] Build Summary: [INFO] Passed: 44, Failed: 1, Errors: 0, Skipped: 4 [INFO] - -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-380) Prefer apache commons and JDK to Plexus utils
[ https://issues.apache.org/jira/browse/MPMD-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736930#comment-17736930 ] ASF GitHub Bot commented on MPMD-380: - elharo commented on PR #132: URL: https://github.com/apache/maven-pmd-plugin/pull/132#issuecomment-1606270094 Flaky? Error: 'other' has different root Error: Error: To see the full stack trace of the errors, re-run Maven with the -e switch. Error: Re-run Maven using the -X switch to enable full debug logging. > Prefer apache commons and JDK to Plexus utils > - > > Key: MPMD-380 > URL: https://issues.apache.org/jira/browse/MPMD-380 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-pmd-plugin] elharo commented on pull request #132: [MPMD-380] use Apache Commons FileUtils and JDK
elharo commented on PR #132: URL: https://github.com/apache/maven-pmd-plugin/pull/132#issuecomment-1606270094 Flaky? Error: 'other' has different root Error: Error: To see the full stack trace of the errors, re-run Maven with the -e switch. Error: Re-run Maven using the -X switch to enable full debug logging. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson edited comment on MSHADE-451 at 6/25/23 8:24 PM:
---
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.9.1s and 3.4.1s
and I was in a rush. But I fixed it. 😉
was (Author: garretwilson):
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson edited comment on MSHADE-451 at 6/25/23 8:23 PM:
---
{quote}Hello human from the future: In which year will Windows 17 be
released?{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
was (Author: garretwilson):
{quote}Hello human from the future: In which year will Windows 17 be
released?\{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736921#comment-17736921
]
Garret Wilson commented on MSHADE-451:
--
{quote}Hello human from the future: In which year will Windows 17 be
released?\{quote}
Ack! I was hungry, OK? 😅 There were too many 10s and 17s and 3.91s and 3.4.1s
and I was in a rush. But I fixed it. 😉
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 10, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Wind
[jira] [Commented] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736920#comment-17736920
]
Michael Osipov commented on MSHADE-451:
---
Hello human from the future: In which year will Windows 17 be released?
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin
> 3.4.1.
> I'm using a technique which I described in MNG-7815 which allows me to easily
> set the base filename of the generated artifacts in {{{}target/{}}}.
> # In a separate parent pom ("Root POM") in the {{}} section I
> set a property
> {{{}${project.artifactId}{}}}.
> # In the {{}} section I set
> {{{}${build.finalBaseName}-${project.version}{}}}.
> Let's suppose my project (which inherits from Root POM) has its own child
> project with an {{{}bar{}}}. Normally because of the
> default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
> e.g.:
> * {{bar-1.2.3.jar}}
> * {{bar-1.2.3-javadoc.jar}}
> However with the configuration I described above, I merely need to set the
> following property in the child project:
> {code:xml}
> foo-${project.artifactId}
> {code}
> Now my artifacts are generated with these names, just like I want:
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> However the Maven Shade Plugin seems to be ignoring the final
> {{build.finalName}} and just assuming that it is set to the
> {{{}${project.artifactId}-$\{project.version{ (which is the Maven
> default). For example let's say I add the following to my Maven Shade Plugin
> {{{}{}}}:
> {code:xml}
> true
> aws-lambda
> {code}
> I would expect the classifier to be added to the {{build.finalName}} (which
> is now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just
> fine. However I get this:
> * {{bar-aws-lambda-1.2.3.jar}}
> * {{foo-bar-1.2.3.jar}}
> * {{foo-bar-1.2.3-javadoc.jar}}
> {{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
> (compare with the other generated artifacts). I'm guessing the Maven Shade
> Plugin is making assumptions about the value of {{build.finalName}} instead
> of using the actual value of {{{}build.finalName{}}}.
> I have not yet done further investigations or tested with the latest version
> of the plugin. (I think I saw that a newer version has been released.)
> Nevertheless I wanted to record this bug while I have all the necessary
> windows open, before I stop for lunch and forget how all these pieces fit
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{${project.artifactId}-${project.version}}} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
>
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.)
Nevertheless I wanted to record this bug while I have all the necessary windows
open, before I stop for lunch and forget how all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} instead of
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{{}target/{}}}.
# In a separate parent pom ("Root POM") in the {{}} section I set
a property
{{{}${project.artifactId}{}}}.
# In the {{}} section I set
{{{}${build.finalBaseName}-${project.version}{}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{{}bar{}}}. Normally because of the
default Maven {{{}build.finalName{}}}, setting, the target artifacts will be
e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{{}${project.artifactId}-$\{project.version{ (which is the Maven default).
For example let's say I add the following to my Maven Shade Plugin
{{{}{}}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{{}foo-bar-1.2.3{}}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts). I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{{}build.finalName{}}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Ga
[jira] [Updated] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
[
https://issues.apache.org/jira/browse/MSHADE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Garret Wilson updated MSHADE-451:
-
Description:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
{{${project.artifactId}-${project.version}}} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
was:
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
${project.artifactId}-${project.version} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
> Shade plugin not using `build.finalName` to produce artifact with classifier.
> -
>
> Key: MSHADE-451
> URL: https://issues.apache.org/jira/browse/MSHADE-451
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Garret Wilson
>Priority: Major
>
> I'm using Maven 3.9.1 with Java 17 on Window
[jira] [Created] (MSHADE-451) Shade plugin not using `build.finalName` to produce artifact with classifier.
Garret Wilson created MSHADE-451:
Summary: Shade plugin not using `build.finalName` to produce
artifact with classifier.
Key: MSHADE-451
URL: https://issues.apache.org/jira/browse/MSHADE-451
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.4.1
Reporter: Garret Wilson
I'm using Maven 3.9.1 with Java 17 on Windows 17, and Maven Shade Plugin 3.4.1.
I'm using a technique which I described in MNG-7815 which allows me to easily
set the base filename of the generated artifacts in {{target/}}.
# In a separate parent pom ("Root POM") in the {{}} section I set a
property {{${project.artifactId}}}.
# In the {{}} section I set
{{${build.finalBaseName}-${project.version}}}.
Let's suppose my project (which inherits from Root POM) has its own child
project with an {{bar}}. Normally because of the
default Maven {{build.finalName}}, setting, the target artifacts will be e.g.:
* {{bar-1.2.3.jar}}
* {{bar-1.2.3-javadoc.jar}}
However with the configuration I described above, I merely need to set the
following property in the child project:
{code:xml}
foo-${project.artifactId}
{code}
Now my artifacts are generated with these names, just like I want:
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
However the Maven Shade Plugin seems to be ignoring the final
{{build.finalName}} and just assuming that it is set to the
${project.artifactId}-${project.version} (which is the Maven default). For
example let's say I add the following to my Maven Shade Plugin
{{}}:
{code:xml}
true
aws-lambda
{code}
I would expect the classifier to be added to the {{build.finalName}} (which is
now {{foo-bar-1.2.3}})—after all, the Javadoc plugin does this just fine.
However I get this:
* {{bar-aws-lambda-1.2.3.jar}}
* {{foo-bar-1.2.3.jar}}
* {{foo-bar-1.2.3-javadoc.jar}}
{{bar-aws-lambda-1.2.3.jar}} should be {{foo-bar-aws-lambda-1.2.3.jar}}
(compare with the other generated artifacts. I'm guessing the Maven Shade
Plugin is making assumptions about the value of {{build.finalName}} without
using the actual value of {{build.finalName}}.
I have not yet done further investigations or tested with the latest version of
the plugin. (I think I saw that a newer version has been released.) Nor have I
done any further investigations. Nevertheless I wanted to record this bug while
I have all the necessary windows open, before I stop for lunch and forget how
all these pieces fit together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRELEASE-1131) When preparing a release on Windows 10, the pom.xml is not read properly when building the code
Robert Voorn created MRELEASE-1131:
--
Summary: When preparing a release on Windows 10, the pom.xml is
not read properly when building the code
Key: MRELEASE-1131
URL: https://issues.apache.org/jira/browse/MRELEASE-1131
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Robert Voorn
I created a project on a Macbook Pro laptop that uses the Maven Release Plugin
(tried with 2.5.3 and 3.0.1) and works as desired and documented. However, when
I clone this project on a Windows 10 machine and to the same 'mvn
release:prepare' command, I behaves differently. I will do the checks regarding
-SNAPSHOT should be in the version, the new release version is suggested and
can be modified, the tag name is suggested and can be modified, and the new
SNAPSHOT version is suggested and can be modified. After that, on Macbook it
will the package maven goal (as configured in the plugin). On Windows I get the
following error:
{noformat}
The goal you specified requires a project to execute but there is no POM in
this directory (C:\). Please verify you invoked
Maven from the correct directory.
{noformat}
It looks like when the release:prepare goal is executed on the maven project,
it first can read it (hence the version suggestions are correct) but when the
'package' goal is executed after that it tries to find the pom.xml in my home
folder (when the maven command is not executed and the pom.xml is indeed not
present.
I also tried to explicitly give the full path to the pom.xml file using the -f
option and that also does not work.
The plugin configuration is as follows:
{code:xml}
org.apache.maven.plugins
maven-release-plugin
pre-integration-test
package
true
v@{project.version}
false
{code}
I use the following spring-boot-starter-parent:
{code:xml}
org.springframework.boot
spring-boot-starter-parent
2.5.8
{code}
Is there something that needs to change when using this plugin in Windows
instead of Macbook?
On windows I use the git-bash linux shell application to run the maven command.
The problem also happens using the regular cmd.exe from windows (even when
running with administrator rights). The Windows 10 machine I am working on is a
restricted virtual machine, but should have full administrative rights when the
cmd.exe is started as adminitrator. I am convinced that the configuration is
correct since it works fine on Macbook. Maybe someone can point out some
differences that are happening on Linux based machines and Windows 10. I have
tried to find some solutions using google and these solutions do not work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736878#comment-17736878 ] Vladimir Sitnikov commented on MNG-7776: The checksums exits for artifacts, so it is not clear why making a deviation for .sigstore There are non-https servers still used, so having checksums would make sense. > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-380) Prefer apache commons and JDK to Plexus utils
[ https://issues.apache.org/jira/browse/MPMD-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736875#comment-17736875 ] ASF GitHub Bot commented on MPMD-380: - elharo opened a new pull request, #132: URL: https://github.com/apache/maven-pmd-plugin/pull/132 (no comment) > Prefer apache commons and JDK to Plexus utils > - > > Key: MPMD-380 > URL: https://issues.apache.org/jira/browse/MPMD-380 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-380) Prefer apache commons and JDK to Plexus utils
Elliotte Rusty Harold created MPMD-380: -- Summary: Prefer apache commons and JDK to Plexus utils Key: MPMD-380 URL: https://issues.apache.org/jira/browse/MPMD-380 Project: Maven PMD Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold Assignee: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736874#comment-17736874 ] Vladimir Sitnikov commented on MNG-7776: If only all the servers used TLS > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7776) don't fingerprint Sigstore signatures (like GPG)
[ https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736873#comment-17736873 ] Michael Osipov commented on MNG-7776: - TLS comes with integrity check otherwise how to very messages? > don't fingerprint Sigstore signatures (like GPG) > > > Key: MNG-7776 > URL: https://issues.apache.org/jira/browse/MNG-7776 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0 > > > Maven repository format requires .md5 and .sha1 fingerprints/checksums for > every artifact: https://maven.apache.org/repository/layout.html > .GPG signature (.asc) is not considered as an artifact, and it does not > require these fingerprints > While working on Sigstore support in addition to GPG, the same should be done > for Sigstore signatures: no fingerprint for .sigstore files (like no GPG > signature for Sigstore signature: see MGPG-86) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736871#comment-17736871
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo merged PR #89:
URL: https://github.com/apache/maven-dependency-analyzer/pull/89
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhan
[GitHub] [maven-dependency-analyzer] elharo merged pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
elharo merged PR #89: URL: https://github.com/apache/maven-dependency-analyzer/pull/89 -- 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-7776) don't fingerprint Sigstore signatures (like GPG)
[
https://issues.apache.org/jira/browse/MNG-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736869#comment-17736869
]
Vladimir Sitnikov commented on MNG-7776:
Checksums for {{.sigstore}} files would help for verifying transfer integrity.
For instance, when client pushes artifacts to a server, the server would be
able to verify if the received {{.sigstore}} file is corrupted or not (TCP and
HTTPS do not guarantee file integrity during transfer).
The same goes for receiving the file from the repository: if the repository
serves a checksum, then client can verify the received file is ok, and it is
not truncated or accidentally corrupted.
Skipping the checksum does not make any good, yet it is bad for verifying
integrity.
Of course, it makes no sense to sign {{.sigstore}} files with PGP, however,
that is a completely different story. I would suggest that Maven should
generate checksums for both {{.sigstore}} and {{.asc}} files.
> don't fingerprint Sigstore signatures (like GPG)
>
>
> Key: MNG-7776
> URL: https://issues.apache.org/jira/browse/MNG-7776
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.9.1, 4.0.0-alpha-5
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.9.2, 4.0.0-alpha-7, 4.0.0
>
>
> Maven repository format requires .md5 and .sha1 fingerprints/checksums for
> every artifact: https://maven.apache.org/repository/layout.html
> .GPG signature (.asc) is not considered as an artifact, and it does not
> require these fingerprints
> While working on Sigstore support in addition to GPG, the same should be done
> for Sigstore signatures: no fingerprint for .sigstore files (like no GPG
> signature for Sigstore signature: see MGPG-86)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7820) Remove dependency on plexus-utils
[
https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736854#comment-17736854
]
Guillaume Nodet commented on MNG-7820:
--
[~crazyhzm] awesome ! the idea is to get rid of {{StringUtils}} by inlining the
methods, {{ReaderFactory}} and {{WriterFactory}} by using streams and letting
the parser handle the encoding (those are usually used to read files anyway, so
using {{Files.newInputStream(...)}} is the best option. The {{diag}} package
would have to be completely copied to maven-core I think. Not sure where to
put the {{Os}} stuff though, it may be inlined...
> Remove dependency on plexus-utils
> -
>
> Key: MNG-7820
> URL: https://issues.apache.org/jira/browse/MNG-7820
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-8
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPATCH-25) Using destFile fails if the directory of destFile does not exist
[
https://issues.apache.org/jira/browse/MPATCH-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Réda Housni Alaoui updated MPATCH-25:
-
Description:
{code:xml}
org.apache.maven.plugins
maven-patch-plugin
1.2
add-registration-privacy-policy
generate-resources
apply
${project.basedir}/patches/add-registration-privacy-policy.patch
${project.build.directory}/genuine-themes/theme/base/login/register-user-profile.ftl
${project.build.outputDirectory}/theme/aqme/login/register-user-profile.ftl
{code}
{code:java}
[INFO] Applying patch: add-registration-privacy-policy.patch
[DEBUG] Executing: /bin/sh -c cd
'/home/rhousni/projects/foo/plugin/core/src/main/java' && 'patch' '-p0' '-l'
'-i'
'/home/rhousni/projects/foo/plugin/core/patches/add-registration-privacy-policy.patch'
'-o'
'/home/rhousni/projects/foo/plugin/core/target/classes/theme/aqme/login/register-user-profile.ftl'
'/home/rhousni/projects/foo/plugin/core/target/genuine-themes/theme/base/login/register-user-profile.ftl'
[DEBUG] patch: Can't create file
/home/rhousni/projects/foo/plugin/core/target/classes/theme/aqme/login/register-user-profile.ftl
: No such file or directory {code}
> Using destFile fails if the directory of destFile does not exist
>
>
> Key: MPATCH-25
> URL: https://issues.apache.org/jira/browse/MPATCH-25
> Project: Maven Patch Plugin
> Issue Type: Bug
>Reporter: Réda Housni Alaoui
>Priority: Major
>
> {code:xml}
>
> org.apache.maven.plugins
> maven-patch-plugin
> 1.2
>
>
> add-registration-privacy-policy
> generate-resources
>
> apply
>
>
>
> ${project.basedir}/patches/add-registration-privacy-policy.patch
>
> ${project.build.directory}/genuine-themes/theme/base/login/register-user-profile.ftl
>
> ${project.build.outputDirectory}/theme/aqme/login/register-user-profile.ftl
>
>
>
> {code}
> {code:java}
> [INFO] Applying patch: add-registration-privacy-policy.patch
> [DEBUG] Executing: /bin/sh -c cd
> '/home/rhousni/projects/foo/plugin/core/src/main/java' && 'patch' '-p0' '-l'
> '-i'
> '/home/rhousni/projects/foo/plugin/core/patches/add-registration-privacy-policy.patch'
> '-o'
> '/home/rhousni/projects/foo/plugin/core/target/classes/theme/aqme/login/register-user-profile.ftl'
>
> '/home/rhousni/projects/foo/plugin/core/target/genuine-themes/theme/base/login/register-user-profile.ftl'
> [DEBUG] patch: Can't create file
> /home/rhousni/projects/foo/plugin/core/target/classes/theme/aqme/login/register-user-profile.ftl
> : No such file or directory {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPATCH-25) Using destFile fails if the directory of destFile does not exist
Réda Housni Alaoui created MPATCH-25: Summary: Using destFile fails if the directory of destFile does not exist Key: MPATCH-25 URL: https://issues.apache.org/jira/browse/MPATCH-25 Project: Maven Patch Plugin Issue Type: Bug Reporter: Réda Housni Alaoui -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7820) Remove dependency on plexus-utils
[ https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhongming Hua updated MNG-7820: --- Attachment: (was: image-2023-06-25-17-40-05-430.png) > Remove dependency on plexus-utils > - > > Key: MNG-7820 > URL: https://issues.apache.org/jira/browse/MNG-7820 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7820) Remove dependency on plexus-utils
[ https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736848#comment-17736848 ] Zhongming Hua commented on MNG-7820: [~gnodet] I can try to do this. > Remove dependency on plexus-utils > - > > Key: MNG-7820 > URL: https://issues.apache.org/jira/browse/MNG-7820 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7820) Remove dependency on plexus-utils
[ https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhongming Hua updated MNG-7820: --- Attachment: image-2023-06-25-17-40-05-430.png > Remove dependency on plexus-utils > - > > Key: MNG-7820 > URL: https://issues.apache.org/jira/browse/MNG-7820 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] chenfeg opened a new issue, #862: Failed to install artifact xxx
chenfeg opened a new issue, #862: URL: https://github.com/apache/maven-mvnd/issues/862 mvn clean package -Ppre -DskipTests execution succeed mvnd clean package -Ppre -DskipTests execution succeed mvn clean install -Ppre -DskipTests execution succeed mvnd clean install -Ppre -DskipTests execution failed error info : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal [32morg.apache.maven.plugins:maven-install-plugin:2.5.2:install[m [1m(default-install)[m on project [36mcommon-util[m: [1;31mFailed to install artifact com.xxx:common-util:jar:1.0-SNAPSHOT: D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar.5405012231798465179.tmp -> D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar[m at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:341) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:324) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174) at org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:77) at org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162) at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:114) at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204) at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to install artifact com.xxx:common-util:jar:1.0-SNAPSHOT: D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar.5405012231798465179.tmp -> D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar at org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:236) at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:126) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:336) ... 15 common frames omitted Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException: Failed to install artifact com.xxx:common-util:jar:1.0-SNAPSHOT: D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar.5405012231798465179.tmp -> D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:96) at org.apache.maven.plugin.install.InstallMojo.installProject(InstallMojo.java:197) ... 18 common frames omitted Caused by: org.eclipse.aether.installation.InstallationException: Failed to install artifact com.xxx:common-util:jar:1.0-SNAPSHOT: D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar.5405012231798465179.tmp -> D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar at org.eclipse.aether.internal.impl.DefaultInstaller.install(DefaultInstaller.java:273) at org.eclipse.aether.internal.impl.DefaultInstaller.install(DefaultInstaller.java:220) at org.eclipse.aether.internal.impl.DefaultInstaller.install(DefaultInstaller.java:170) at org.eclipse.aether.internal.impl.DefaultInstaller.install(DefaultInstaller.java:135) at org.apache.maven.internal.aether.MavenInstaller.install(MavenInstaller.java:56) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.install(DefaultRepositorySystem.java:384) at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:94) ... 19 common frames omitted Caused by: java.nio.file.AccessDeniedException: D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-1.0-SNAPSHOT.jar.5405012231798465179.tmp -> D:\maven_repository\com\xxx\common-util\1.0-SNAPSHOT\common-util-
