[jira] [Created] (MPMD-396) Impractical to fail build on violation
Delany created MPMD-396:
---
Summary: Impractical to fail build on violation
Key: MPMD-396
URL: https://issues.apache.org/jira/browse/MPMD-396
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.22.0
Reporter: Delany
Let me start with what I'm trying to achieve. I have a multi-module build and I
want it to fail on a violation, quickly.
I'm not interesting in producing a report.
The build may include anything from a single module to all modules. In each
case, I don't want PMD to try parse the entire code base if I only asked Maven
to build a single module.
I notice that if I use the "aggregate-pmd-check" goal, I get log lines like
{{[WARNING] org.apache.maven.plugins.pmd.AggregatorPmdReport - Unable to locate
Source XRef to link to - DISABLED}}
Why is AggregatorPmdReport being invoked? Sounds like a legacy issue.
I also notice that unlike most Maven plugins, the pmd-maven-plugin goal is
always forking, indicated by chevrons in the output {{<<< pmd:3.22.0:check}}
With a single custom XPath rule, the time to complete a build becomes
impractical.
I was hoping to add pmd to my list of static analysis checkers/formatters like
checkstyle, impsort, sortpom, errorprone, modernizer etc which are all able to
parse source code and do various checks without becoming a burden.
With the current state of the pmd-maven-plugin (v3.22.0) that does not look
likely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848890#comment-17848890 ] Delany commented on MPMD-391: - Is there an issue logged to remove those last 7 lines? The link to MojoFailureException is useless, and how often do we use -e or -X to solve a failure? > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MJAR-307) Commons-io class not found
[
https://issues.apache.org/jira/browse/MJAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837071#comment-17837071
]
Delany edited comment on MJAR-307 at 4/15/24 5:46 AM:
--
I'll try. Here's the stacktrace in the mean time
{noformat}
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.io.file.attribute.FileTimes
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.fileTimeToZip
(X000A_NTFS.java:91)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.setModifyFileTime
(X000A_NTFS.java:424)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.addNTFSTimestamp
(ZipArchiveEntry.java:530)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtraTimeFields
(ZipArchiveEntry.java:1316)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setLastModifiedTime
(ZipArchiveEntry.java:1350)
at org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setTime
(ZipArchiveEntry.java:1474)
at org.codehaus.plexus.archiver.jar.JarArchiver.setZipEntryTime
(JarArchiver.java:717)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipDir
(AbstractZipArchiver.java:509)
at org.codehaus.plexus.archiver.jar.JarArchiver.writeManifest
(JarArchiver.java:336)
at org.codehaus.plexus.archiver.jar.JarArchiver.initZipOutputStream
(JarArchiver.java:284)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain
(AbstractZipArchiver.java:258)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute
(AbstractZipArchiver.java:182)
at org.codehaus.plexus.archiver.AbstractArchiver.createArchive
(AbstractArchiver.java:877)
at org.apache.maven.archiver.MavenArchiver.createArchive
(MavenArchiver.java:620)
at org.apache.maven.plugins.jar.AbstractJarMojo.createArchive
(AbstractJarMojo.java:320)
at org.apache.maven.plugins.jar.AbstractJarMojo.execute
(AbstractJarMojo.java:345)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
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:75)
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:105)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:193)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:180)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:635)
at java.lang.Thread.run (Thread.java:840){noformat}
was (Author: delany):
I'll try. Here's the stacktrace in the mean time
```
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.io.file.attribute.FileTimes
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.fileTimeToZip
(X000A_NTFS.java:91)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.setModifyFileTime
(X000A_NTFS.java:424)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.addNTFSTimestamp
(ZipArchiveEntry.java:530)
at
[jira] [Commented] (MJAR-307) Commons-io class not found
[
https://issues.apache.org/jira/browse/MJAR-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837071#comment-17837071
]
Delany commented on MJAR-307:
-
I'll try. Here's the stacktrace in the mean time
```
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.io.file.attribute.FileTimes
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.fileTimeToZip
(X000A_NTFS.java:91)
at org.apache.commons.compress.archivers.zip.X000A_NTFS.setModifyFileTime
(X000A_NTFS.java:424)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.addNTFSTimestamp
(ZipArchiveEntry.java:530)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtraTimeFields
(ZipArchiveEntry.java:1316)
at
org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setLastModifiedTime
(ZipArchiveEntry.java:1350)
at org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setTime
(ZipArchiveEntry.java:1474)
at org.codehaus.plexus.archiver.jar.JarArchiver.setZipEntryTime
(JarArchiver.java:717)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipDir
(AbstractZipArchiver.java:509)
at org.codehaus.plexus.archiver.jar.JarArchiver.writeManifest
(JarArchiver.java:336)
at org.codehaus.plexus.archiver.jar.JarArchiver.initZipOutputStream
(JarArchiver.java:284)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain
(AbstractZipArchiver.java:258)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute
(AbstractZipArchiver.java:182)
at org.codehaus.plexus.archiver.AbstractArchiver.createArchive
(AbstractArchiver.java:877)
at org.apache.maven.archiver.MavenArchiver.createArchive
(MavenArchiver.java:620)
at org.apache.maven.plugins.jar.AbstractJarMojo.createArchive
(AbstractJarMojo.java:320)
at org.apache.maven.plugins.jar.AbstractJarMojo.execute
(AbstractJarMojo.java:345)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
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:75)
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:105)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:193)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:180)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:635)
at java.lang.Thread.run (Thread.java:840)
```
> Commons-io class not found
> --
>
> Key: MJAR-307
> URL: https://issues.apache.org/jira/browse/MJAR-307
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Delany
>Priority: Major
>
> With Maven 3.9.6 and upgrading from plugin version 3.3.0 I now get this error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar (default-jar) on project
> comet:
> Execution default-jar of goal
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar
> failed: A required class was missing while executing
> org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar:
> org/apache/commons/io/file/attribute/FileTimes
> [ERROR] -
>
> [ERROR] realm = plugin>org.apache.maven.plugins:maven-jar-plugin:3.4.0
>
[jira] [Created] (MJAR-307) Commons-io class not found
Delany created MJAR-307:
---
Summary: Commons-io class not found
Key: MJAR-307
URL: https://issues.apache.org/jira/browse/MJAR-307
Project: Maven JAR Plugin
Issue Type: Bug
Affects Versions: 3.4.0
Reporter: Delany
With Maven 3.9.6 and upgrading from plugin version 3.3.0 I now get this error:
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar (default-jar) on project
comet: Execution default-jar of goal
org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar failed: A required class
was missing while executing
org.apache.maven.plugins:maven-jar-plugin:3.4.0:jar:
org/apache/commons/io/file/attribute/FileTimes
[ERROR] -
[ERROR] realm = plugin>org.apache.maven.plugins:maven-jar-plugin:3.4.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/home/sol/.m2/repository/org/apache/maven/plugins/maven-jar-plugin/3.4.0/maven-jar-plugin-3.4.0.jar
[ERROR] urls[1] =
file:/home/sol/.m2/repository/org/apache/maven/shared/file-management/3.1.0/file-management-3.1.0.jar
[ERROR] urls[2] =
file:/home/sol/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
[ERROR] urls[3] =
file:/home/sol/.m2/repository/org/apache/maven/maven-archiver/3.6.2/maven-archiver-3.6.2.jar
[ERROR] urls[4] =
file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.27/plexus-interpolation-1.27.jar
[ERROR] urls[5] =
file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-utils/4.0.0/plexus-utils-4.0.0.jar
[ERROR] urls[6] =
file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-archiver/4.9.2/plexus-archiver-4.9.2.jar
[ERROR] urls[7] =
file:/home/sol/.m2/repository/org/codehaus/plexus/plexus-io/3.4.2/plexus-io-3.4.2.jar
[ERROR] urls[8] =
file:/home/sol/.m2/repository/org/apache/commons/commons-compress/1.26.1/commons-compress-1.26.1.jar
[ERROR] urls[9] =
file:/home/sol/.m2/repository/org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar
[ERROR] urls[10] =
file:/home/sol/.m2/repository/commons-codec/commons-codec/1.16.1/commons-codec-1.16.1.jar
[ERROR] urls[11] =
file:/home/sol/.m2/repository/org/iq80/snappy/snappy/0.4/snappy-0.4.jar
[ERROR] urls[12] = file:/home/sol/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar
[ERROR] urls[13] =
file:/home/sol/.m2/repository/com/github/luben/zstd-jni/1.5.5-11/zstd-jni-1.5.5-11.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
```
not sure if I'm only seeing it because of this configuration
```xml
true
true
${build.number}
${build.sealed}
```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRELEASE-1140) New version suggestion should be based on previous release
Delany created MRELEASE-1140:
Summary: New version suggestion should be based on previous release
Key: MRELEASE-1140
URL: https://issues.apache.org/jira/browse/MRELEASE-1140
Project: Maven Release Plugin
Issue Type: Improvement
Affects Versions: 3.0.1
Reporter: Delany
When i run *release:prepare* the plugin suggests what the new version should be.
On some of my projects it will suggest raising the minor version number, and on
others it suggests raising the patch version number.
Judging from experience, the algorithm looks at the FIRST release I made for
the project and will suggest that for eternity. So if for the first release I
bumped the minor version number, it will suggest changing that even if the last
10 times I bumped the patch number, e.g.
{code:java}
[INFO] 5/17 prepare:map-release-versions
What is the release version for "Thirdparty"? (thirdparty) 1.1.0: : 1.0.10
[INFO] 6/17 prepare:input-variables
What is the SCM release tag or label for "Thirdparty"? (thirdparty) v1.0.10: :
[INFO] 7/17 prepare:map-development-versions
What is the new development version for "Thirdparty"? (thirdparty)
1.1.0-SNAPSHOT: : 1.0.11-SNAPSHOT{code}
This is inconvenient. I would be better if it considered the LAST release only.
Perhaps there could be a configuration for this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-885) Introduce artifactSets in analyze
[ https://issues.apache.org/jira/browse/MDEP-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17768145#comment-17768145 ] Delany commented on MDEP-885: - If Maven were opinionated it wouldn't even allow used-undeclared, unused-undeclared. And I might add that if Maven were strict from the beginning the project I'm working on would never have been allowed to deteriorate to the state that it is in. The whole purpose of this goal, it seems, is to aid in tightening up what Maven allows by design. Who knows what situations people might be trying to crawl out from? My idiosyncratic setup is NOT fine. But I cant fix it all in one go. Of course we all want to avoid unnecessary work, so you ask for a use case. What I'm saying is: allow full freedom to arbitrarily select artifacts and you will never have to consider another use case for this type of issue. I don't really understand what else could be the obstacle. IgnoredDependencies is the same as an excludes filter, and includes just lets you do its complement. What is the use case for an IgnoredDependencies parameter? > Introduce artifactSets in analyze > - > > Key: MDEP-885 > URL: https://issues.apache.org/jira/browse/MDEP-885 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze-only >Affects Versions: 3.6.0 >Reporter: Delany >Assignee: Elliotte Rusty Harold >Priority: Major > > As in MDEP-210, in my project all third-party artifacts, including their > transitives, must be specified as direct dependencies. What happens is that > these transitives get flagged as unused. I want the rule to consider only > dependencies with a groupId identifying the artifacts I produce. > None of the current options allow this. Please add include/exclude parameters > so I can filter by Maven coordinates. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-885) Introduce artifactSets in analyze
[ https://issues.apache.org/jira/browse/MDEP-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767240#comment-17767240 ] Delany commented on MDEP-885: - On further thought how about something like [https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#artifactSet] The parameters artifactSet/artifactSetUsed/artifactSetUnused could be introduced to replace these bitsy params * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUsedUndeclaredDependencies] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredUnusedDeclaredDependencies] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreUnusedRuntime] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredPackagings] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile] * [https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredNonTestScopedDependencies] This would future proof any requirement for further filtering and make the goal easier to understand > Introduce artifactSets in analyze > - > > Key: MDEP-885 > URL: https://issues.apache.org/jira/browse/MDEP-885 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze-only >Affects Versions: 3.6.0 >Reporter: Delany >Assignee: Elliotte Rusty Harold >Priority: Major > > As in MDEP-210, in my project all third-party artifacts, including their > transitives, must be specified as direct dependencies. What happens is that > these transitives get flagged as unused. I want the rule to consider only > dependencies with a groupId identifying the artifacts I produce. > None of the current options allow this. Please add include/exclude parameters > so I can filter by Maven coordinates. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEP-885) Introduce artifactSets in analyze
[ https://issues.apache.org/jira/browse/MDEP-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delany updated MDEP-885: Summary: Introduce artifactSets in analyze (was: Support includes/excludes configuration in analyze v2) > Introduce artifactSets in analyze > - > > Key: MDEP-885 > URL: https://issues.apache.org/jira/browse/MDEP-885 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze-only >Affects Versions: 3.6.0 >Reporter: Delany >Assignee: Elliotte Rusty Harold >Priority: Major > > As in MDEP-210, in my project all third-party artifacts, including their > transitives, must be specified as direct dependencies. What happens is that > these transitives get flagged as unused. I want the rule to consider only > dependencies with a groupId identifying the artifacts I produce. > None of the current options allow this. Please add include/exclude parameters > so I can filter by Maven coordinates. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-885) Support includes/excludes configuration in analyze v2
[ https://issues.apache.org/jira/browse/MDEP-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767151#comment-17767151 ] Delany commented on MDEP-885: - Its not related to flattening. I'm already making use of the results of the analysis and I've removed unnecessary dependencies and added missing dependencies. But, we have a very particular situation where third-party dependencies (direct and transitive) must be direct dependencies. To protect the dependencies from future changes, if I set the plugin to fail on warnings, it will fail because it found transitive dependencies that are not needed on the modules. I cant do anything about this at this time. I think as a general rule any plugin should allow filtering with include/exclude by coordinates. > Support includes/excludes configuration in analyze v2 > - > > Key: MDEP-885 > URL: https://issues.apache.org/jira/browse/MDEP-885 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze-only >Affects Versions: 3.6.0 >Reporter: Delany >Assignee: Elliotte Rusty Harold >Priority: Major > > As in MDEP-210, in my project all third-party artifacts, including their > transitives, must be specified as direct dependencies. What happens is that > these transitives get flagged as unused. I want the rule to consider only > dependencies with a groupId identifying the artifacts I produce. > None of the current options allow this. Please add include/exclude parameters > so I can filter by Maven coordinates. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEP-886) Add user properties for ignoredUsedUndeclaredDependencies/ignoredUnusedDeclaredDependencies
[ https://issues.apache.org/jira/browse/MDEP-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delany updated MDEP-886: Summary: Add user properties for ignoredUsedUndeclaredDependencies/ignoredUnusedDeclaredDependencies (was: Add user properties for ignored(UsedUndeclared|UnusedDeclared)Dependencies) > Add user properties for > ignoredUsedUndeclaredDependencies/ignoredUnusedDeclaredDependencies > --- > > Key: MDEP-886 > URL: https://issues.apache.org/jira/browse/MDEP-886 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze, analyze-only >Affects Versions: 3.6.0 >Reporter: Delany >Priority: Minor > > These properties need a user property, especially in the *analyze* goal which > is intended to be used standalone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-886) Add user properties for ignored(UsedUndeclared|UnusedDeclared)Dependencies
Delany created MDEP-886: --- Summary: Add user properties for ignored(UsedUndeclared|UnusedDeclared)Dependencies Key: MDEP-886 URL: https://issues.apache.org/jira/browse/MDEP-886 Project: Maven Dependency Plugin Issue Type: Improvement Components: analyze, analyze-only Affects Versions: 3.6.0 Reporter: Delany These properties need a user property, especially in the *analyze* goal which is intended to be used standalone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766732#comment-17766732
]
Delany commented on MDEP-808:
-
I've arrived at the same issue https://issues.apache.org/jira/browse/MDEP-885
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Priority: Major
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-885) Support includes/excludes configuration in analyze v2
Delany created MDEP-885: --- Summary: Support includes/excludes configuration in analyze v2 Key: MDEP-885 URL: https://issues.apache.org/jira/browse/MDEP-885 Project: Maven Dependency Plugin Issue Type: New Feature Components: analyze-only Affects Versions: 3.6.0 Reporter: Delany As here https://issues.apache.org/jira/browse/MDEP-210 In my project all third-party artifacts, including their transitives, must be specified as direct dependencies. What happens is that these transitives get flagged as unused. I want the rule to consider only dependencies with a groupId identifying the artifacts I produce. None of the current options allow this. Please add include/exclude parameters so I can filter by Maven coordinates. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-454) Shade Plugin does not work with JDK 20
[
https://issues.apache.org/jira/browse/MSHADE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766302#comment-17766302
]
Delany commented on MSHADE-454:
---
I've also tested this with jdk21-ea and no problems. Can we have another
release?
> Shade Plugin does not work with JDK 20
> --
>
> Key: MSHADE-454
> URL: https://issues.apache.org/jira/browse/MSHADE-454
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Barry
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.5.1
>
>
> We are trying to use JDK 20 and this was the only plugin we had to
> work-around because it would not work. Are there plans to update this plugin
> to support JDK 20+? Is there a work-around until changes are made?
>
> Our current work-around is using assembly plugin, but we use shade plugin in
> many of the apps we are migrating and our preference is to continue to use
> Shade-plugin.
> Currently- if you try to use shade plugin with JDK 20, you get : Unsupported
> class file major version 64
>
> {noformat}
> Error creating shaded jar: Unsupported class file major version 64
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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: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:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:578)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
> shaded jar: Unsupported class file major version 64
> at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute
> (ShadeMojo.java:624)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>
[jira] [Commented] (MJARSIGNER-23) Signing is slow, add parallelism signing
[
https://issues.apache.org/jira/browse/MJARSIGNER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749117#comment-17749117
]
Delany commented on MJARSIGNER-23:
--
Is 0.3s per jar slow for verification?
{code:java}
11:49:15,728 [INFO] --- jarsigner:3.0.0:verify (verify) @ third ---
11:50:20,781 [INFO] 177 archive(s) processed {code}
Maven 3.9.3
> Signing is slow, add parallelism signing
>
>
> Key: MJARSIGNER-23
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-23
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
>Reporter: Pino Silvaggio
>Priority: Minor
>
> We have cases where signing can take up to 1h, which is unacceptable.
> Maybe we could add a option?
> Use case:
>
> 1
>
> ...
> ${jarsigner.parallel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJARSIGNER-69) Verify failFast
[ https://issues.apache.org/jira/browse/MJARSIGNER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delany updated MJARSIGNER-69: - Summary: Verify failFast (was: Verify fastFast) > Verify failFast > --- > > Key: MJARSIGNER-69 > URL: https://issues.apache.org/jira/browse/MJARSIGNER-69 > Project: Maven Jar Signer Plugin > Issue Type: Improvement >Reporter: Delany >Priority: Major > > When I verify a directory of jars and errorWhenNotSigned=true I'd like the > option of failing after verifying all jars. > Same as > [https://maven.apache.org/enforcer/maven-enforcer-plugin/enforce-mojo.html#failFast] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJARSIGNER-70) Verify default output
Delany created MJARSIGNER-70: Summary: Verify default output Key: MJARSIGNER-70 URL: https://issues.apache.org/jira/browse/MJARSIGNER-70 Project: Maven Jar Signer Plugin Issue Type: Bug Reporter: Delany The default verify configuration results in no output, and no warning of unsigned jars. Setting verbose=true is an excessive alternative. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJARSIGNER-69) Verify fastFast
Delany created MJARSIGNER-69: Summary: Verify fastFast Key: MJARSIGNER-69 URL: https://issues.apache.org/jira/browse/MJARSIGNER-69 Project: Maven Jar Signer Plugin Issue Type: Improvement Reporter: Delany When I verify a directory of jars and errorWhenNotSigned=true I'd like the option of failing after verifying all jars. Same as [https://maven.apache.org/enforcer/maven-enforcer-plugin/enforce-mojo.html#failFast] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-881) dependencyManagement to dependencies
Delany created MDEP-881:
---
Summary: dependencyManagement to dependencies
Key: MDEP-881
URL: https://issues.apache.org/jira/browse/MDEP-881
Project: Maven Dependency Plugin
Issue Type: Improvement
Affects Versions: 3.6.0
Reporter: Delany
Before releasing a BOM type artefact, e.g. in
[https://reflectoring.io/maven-bom/]
I'd like to confirm that the artefacts I've specified are actually available.
Currently there's no way to do this without making a redundant
section in the project with an entry for every dep in depMng and running the
resolve goal.
Could there be a new property includeManagement on the resolve goal? Or a
separate resolveManaged goal?
Alternatively, a goal that generates a dependency for every managed dependency
which subsequent goals can work off, e.g.
{code:java}
mvn dependency:depend oga-maven-plugin:check ossindex:audit{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742314#comment-17742314
]
Delany edited comment on MRESOLVER-372 at 7/12/23 8:19 AM:
---
Can happen at the end of a large deployAtEnd build (on CI machine)
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
was (Author: delany):
Can happen at the end of a large deployAtEnd build
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
>
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742314#comment-17742314
]
Delany commented on MRESOLVER-372:
--
Can happen at the end of a large deployAtEnd build
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7841) Insecure mirrors are only whitelisted when defined in global settings
Delany created MNG-7841: --- Summary: Insecure mirrors are only whitelisted when defined in global settings Key: MNG-7841 URL: https://issues.apache.org/jira/browse/MNG-7841 Project: Maven Issue Type: Bug Components: Settings Affects Versions: 3.9.3 Reporter: Delany The second option to fix a blocked repository at [https://maven.apache.org/docs/3.8.1/release-notes.html#how-to-fix-when-i-get-a-http-repository-blocked], i.e. "keep the dependency version but [define a mirror in your settings|https://maven.apache.org/guides/mini/guide-mirror-settings.html].; only works when the settings are global (--global-settings). An insecure repository defined in the user settings (–settings) will still be blocked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSITE-966) No default skin
Delany created MSITE-966:
Summary: No default skin
Key: MSITE-966
URL: https://issues.apache.org/jira/browse/MSITE-966
Project: Maven Site Plugin
Issue Type: Bug
Components: site descriptor
Affects Versions: 4.0.0-M8
Reporter: Delany
When I follow instructions to add documentation to a plugin
[https://maven.apache.org/guides/development/guide-plugin-documentation.html]
I get
{quote}{{Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:4.0.0-M8:site failed: skin cannot be
null}}
{quote}
There's no mention of skins on that page.
But at [https://maven.apache.org/skins/index.html]
it says
{quote}You get this skin if you don't specify any skin or template.
{quote}
If I add a skin in the site descriptor its happy
{code:java}
org.apache.maven.skins
maven-fluido-skin
2.0.0-M6
... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716447#comment-17716447 ] Delany commented on MNG-5659: - [~breun] if its permanent, put it in the pom. And if its temporary, wouldn't you rather have something on the command line like [https://maven.apache.org/plugins/maven-dependency-plugin/get-mojo.html#remoteRepositories] ? > Project specific settings.xml > - > > Key: MNG-5659 > URL: https://issues.apache.org/jira/browse/MNG-5659 > Project: Maven > Issue Type: New Feature > Components: FDPFC >Reporter: Joachim Van der Auwera >Priority: Major > Fix For: Issues to be reviewed for 4.x > > Attachments: mvn.patch > > > It would be useful to have a settings.xml file next to the project pom that > could contain project specific settings. For example, when switching between > projects it is sometimes necessary to also change the location of the local > repository, or use a different set of repositories and/or mirror settings for > each project. > If a settings.xml file could be included with a project checkout, then the > repositories needed for the build could be included (instead of putting them > in the pom) along with any other project specific settings. > The tricky part is intelligently handling multi-module projects. For a > multi-module project I don't want to include a separate settings.xml file for > each directory. So Maven could recursively check each parent directory until > it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or > (3) finds the root directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7691) Provide a generic way to skip Maven Goals for a specified plugin
[ https://issues.apache.org/jira/browse/MNG-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711838#comment-17711838 ] Delany commented on MNG-7691: - https://issues.apache.org/jira/browse/MSHADE-251 Although I don't need this personally, I don't buy Robert's paternalistic arguments against skip properties. The question should rather be: where has anyone ever complained about the existence of a skip property? Adding a command line switch and removing inadvertently added switches is trivial. If I'm so concerned about the inefficiencies they introduce I'll refactor the poms as a more permanent solution. Functionality first, efficiency later. > Provide a generic way to skip Maven Goals for a specified plugin > > > Key: MNG-7691 > URL: https://issues.apache.org/jira/browse/MNG-7691 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Jimisola Laursen >Priority: Major > > From ([Baeldung|https://www.baeldung.com/maven-disable-parent-pom-plugin]: > "Many plugins feature a skip parameter. We can use the skip parameter to > disable the plugin. Support for the skip parameter should be the first thing > we check because it is the simplest solution and the most conventional.". > I was thinking that there should be a generic way to skip maven plugin goals > in the core of Maven, i.e. it should not have to be implemented in each > plugin. > Would something like this work? > -Dmaven.skip.goals=groupID:artifactId:goal (is there a need to specify > version?) > E.g. > -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply > -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply+validate > -Dmaven.skip.goals=io.spring.javaformat:spring-javaformat-maven-plugin:apply+validate,org.apache.maven.plugins:maven-enforcer-plugin:enforce -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-436) Extension defined in .mvn/extensions.xml failing "requirePluginVersions" check
[
https://issues.apache.org/jira/browse/MENFORCER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711522#comment-17711522
]
Delany commented on MENFORCER-436:
--
Similarly, adding an extension in the pom
{code:java}
io.takari.maven
maven-timeline
1.8
true
{code}
results in
{quote}[ERROR] Rule 5: org.apache.maven.enforcer.rules.RequirePluginVersions
failed with message:
[ERROR] Internal error in the plugin manager getting plugin
'io.takari.maven:maven-timeline': Failed to parse plugin descriptor for
io.takari.maven:maven-timeline:1.8
(/home/sol/.m2/repository/io/takari/maven/maven-timeline/1.8/maven-timeline-1.8.jar):
No plugin descriptor found at META-INF/maven/plugin.xml
{quote}
> Extension defined in .mvn/extensions.xml failing "requirePluginVersions" check
> --
>
> Key: MENFORCER-436
> URL: https://issues.apache.org/jira/browse/MENFORCER-436
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.1.0
> Environment: Windows 10, JDK 11 (Temurin), Maven 3.8.6, Enforcer
> Plugin 3.1.0
>Reporter: Jeff Thomas
>Priority: Minor
>
> I have defined the "maven-git-versioning-extension' in .mvn/extensions.xml
> with an explicit version.
>
> {{http://maven.apache.org/EXTENSIONS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
> {{ xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>}}
> {{ }}
> {{ me.qoomon}}
> {{ maven-git-versioning-extension}}
> {{ 9.3.1}}
> {{ }}
> {{}}
> This extension is not referenced anywhere in my POM.
> However, the 'requirePluginVersions' check is failing during build.
> NOTE: I saw MENFORCER-133 which was similiar but is already closed.
> Currently I have the workaround to add
> "me.qoomon:maven-git-versioning-extension" to the "unCheckedPluginList"
> configuration option, but this is sort of annoying since we use this
> extension in almost all of our git projects. :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7762) Show version and continue build
[ https://issues.apache.org/jira/browse/MNG-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711476#comment-17711476 ] Delany commented on MNG-7762: - Thanks - and its mentioned in --help > Show version and continue build > --- > > Key: MNG-7762 > URL: https://issues.apache.org/jira/browse/MNG-7762 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-5 >Reporter: Delany >Priority: Minor > > When Maven is called with '--version' the build stops. But sometimes its > useful to have the version info displayed as part of the build output. > I propose that when a goal is specified on the command line only (and not via > defaultGoal) and the --version switch is used, the build should continue, > e.g. `mvn --version clean install` > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7762) Show version and continue build
Delany created MNG-7762: --- Summary: Show version and continue build Key: MNG-7762 URL: https://issues.apache.org/jira/browse/MNG-7762 Project: Maven Issue Type: Improvement Affects Versions: 4.0.0-alpha-5 Reporter: Delany When Maven is called with '--version' the build stops. But sometimes its useful to have the version info displayed as part of the build output. I propose that when a goal is specified on the command line only (and not via defaultGoal) and the --version switch is used, the build should continue, e.g. `mvn --version clean install` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711321#comment-17711321
]
Delany commented on MNG-5659:
-
[~breun] we had to jostle around the configuration quite a lot in the
beginning. Its difficult to talk about it in abstract. One thing I would
recommend is setting up your repository manager with a single group repository
so that you're following Postel's law/the robustness principle, i.e. be
conservative in what you send and liberal in what you accept. Our projects
download from a single group repository (less network!), and then distribution
management always uploads directly to a specific repo.
[~gzm55] the only time I ever went into `${maven.home}` was to try out that
redisson locking thing. Otherwise I never touch
`${maven.home}/conf/settings.xml`
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[ https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710902#comment-17710902 ] Delany commented on MNG-5659: - There's a section on using profiles to configure repositories: [https://maven.apache.org/guides/mini/guide-multiple-repositories.html] In your global settings you could place the default repository in a profile that only activates when a property is not set, and then set that property in your .mvn/maven.config for the project's you're working on. (Note: never use activateProfiles, as it turns all other profiles off. This should probably be deprecated). Now your project has control over the global settings repository via a property. Feel free to add your own repository directly or via a profile. I don't think we ever activate a profile using -P anymore. There's always some other property/file/package type that turns it on. One benefit is that profiles linked to a property can be mutually exclusive. > Project specific settings.xml > - > > Key: MNG-5659 > URL: https://issues.apache.org/jira/browse/MNG-5659 > Project: Maven > Issue Type: New Feature > Components: FDPFC >Reporter: Joachim Van der Auwera >Priority: Major > Fix For: Issues to be reviewed for 4.x > > Attachments: mvn.patch > > > It would be useful to have a settings.xml file next to the project pom that > could contain project specific settings. For example, when switching between > projects it is sometimes necessary to also change the location of the local > repository, or use a different set of repositories and/or mirror settings for > each project. > If a settings.xml file could be included with a project checkout, then the > repositories needed for the build could be included (instead of putting them > in the pom) along with any other project specific settings. > The tricky part is intelligently handling multi-module projects. For a > multi-module project I don't want to include a separate settings.xml file for > each directory. So Maven could recursively check each parent directory until > it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or > (3) finds the root directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710838#comment-17710838
]
Delany commented on MNG-5659:
-
I'm not sure I understand/agree with your example (a username is surely a
property for the ${user.home}/.m2/settings.xml file?) but I understand the
headache. I've made sure the settings.xml file doesn't change all that often. I
think since settings can have server credentials it was always intended that
they be provisioned separately. And if it does have a valid reason for
changing, like cycling credentials, then its worth setting up
puppet/ansible/etc to manage the file.
The fact that --settings switch can refer to a project file looks like a hack.
Since a temporary Jenkins workspace doesn't have a user.home I'm guessing this
was added to override that location.
In short I don't think this issue should be pursued. For a project-specific
local repository add -Dmaven.repo.local to .mvn/maven.config, and for
alternative repositories use either a setting profile or a project profile.
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710322#comment-17710322
]
Delany commented on MNG-5659:
-
What situation would necessitate project-specific mirrors? If the requirement
is to facilitate more granular settings and not just to ease the distribution
of Maven settings, then what about considering a new concept: project group.
Settings could be defined to apply for any project within a directory
{code:java}
/git/github
extra
https://nexus.puff.com/repository/extra/
central
{code}
Or just make every settings.xml file apply to a path and introduce recursion
{code:java}
/git
/git/github
extra
https://nexus.puff.com/repository/extra/
central
{code}
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPH-205) Handling empty elements
Delany created MPH-205:
--
Summary: Handling empty elements
Key: MPH-205
URL: https://issues.apache.org/jira/browse/MPH-205
Project: Maven Help Plugin
Issue Type: Bug
Components: effective-settings
Affects Versions: 3.4.0
Reporter: Delany
When i needed a settings.xml file in the past I would copy the code from
[https://maven.apache.org/settings.html]
[https://maven.apache.org/ref/4.0.0-alpha-5/maven-settings/settings.html]
and replace the self-closing tag of whichever section I needed - typically
servers, mirrors and profiles. The other tags would remain, like
""
With Maven 3.9.0 the empty/self-closing tag was ignored.
In Maven 4.0.0-alpha-1 the value is removed/replaced, resulting in the local
repository directory set to ${pwd}.
This is the case for settings.xml (what about toolchains.xml?) but not pom.xml
With Maven 4.0.0-alpha-5, and I guess
https://issues.apache.org/jira/browse/MNG-7678
the behaviour has changed back to that of Maven 3 - an empty tag is simply
ignored, it doesn't override.
But while the build is successful, mvn help:effective-settings now fails with
{noformat}
Execution default-cli of goal
org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-settings failed:
Cannot invoke "org.codehaus.plexus.util.xml.Xpp3Dom.getDom()" because
"configuration" is null{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708274#comment-17708274
]
Delany commented on MNG-5659:
-
[~breun] to solve your company issue I would use the properties-maven-extension
to set the *git.dir.worktree* property that all the plugins could use. I
stopped using when I found out how to build configuration files into a
dependency for the plugins, e.g.
[https://code.revelc.net/formatter-maven-plugin/examples.html#basic-configuration-using-external-resource]
What if settings were treated the same way? Make another scope for them
{code:java}
com.company.project
settings
settings
{code}
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEPLOY-307) [REGRESSION] Longer deploy times
[ https://issues.apache.org/jira/browse/MDEPLOY-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704728#comment-17704728 ] Delany commented on MDEPLOY-307: I do set -Dmaven.artifact.threads=5 -Dmaven.wagon.httpconnectionManager.ttlSeconds=10 -Dmaven.wagon.http.retryHandler.count=3 Its been a while and I dont have logs for this issue. I'll be sure to post a thorough report next time something like this happens. > [REGRESSION] Longer deploy times > > > Key: MDEPLOY-307 > URL: https://issues.apache.org/jira/browse/MDEPLOY-307 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 3.1.0 >Reporter: Delany >Priority: Major > > On Windows OS, a 500 module build takes half an hour to deploy when using > deployAtEnd. > I was expecting an improvement in build time with this version of the plugin. > Maven 3.9.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-107) Windows script fails to process userinfo
Delany created MWRAPPER-107:
---
Summary: Windows script fails to process userinfo
Key: MWRAPPER-107
URL: https://issues.apache.org/jira/browse/MWRAPPER-107
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.2.0
Environment: Windows
Reporter: Delany
The build fail when the [userinfo
field|https://maven.apache.org/wrapper/index.html#using-basic-authentication-for-distribution-download]
is set in the distributionUrl for type only-script, but only for mvnw.cmd. The
mvnw scripts runs without error on Linux.
{noformat}
C:\git\tester [tester ≡]> .\mvnw.cmd clean -N
icm : Exception calling "DownloadFile" with "2" argument(s): "The remote server
returned an error: (401) Unauthorized."
At line:1 char:53
+ ... 'mvnw.cmd'; icm -ScriptBlock ([Scriptblock]::Create((Get-Content -Raw ...
+ ~
+ CategoryInfo : NotSpecified: (:) [Invoke-Command],
MethodInvocationException
+ FullyQualifiedErrorId :
WebException,Microsoft.PowerShell.Commands.InvokeCommandCommand
ECHO is on.
Cannot start maven from wrapper
C:\git\tester [tester ≡]>{noformat}
https://maven.apache.org/wrapper/index.html#using-basic-authentication-for-distribution-download
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-106) Consistent semantics
Delany created MWRAPPER-106:
---
Summary: Consistent semantics
Key: MWRAPPER-106
URL: https://issues.apache.org/jira/browse/MWRAPPER-106
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.2.0
Reporter: Delany
Two scripts are provided: mvnw and mvnw.cmd. Presumably the only difference
between them is one is used on Linux OS and the other on Windows OS.
They should not have different requirements of the maven-wrapper.properties
file, for example.
mvnw allows a property to be repeated, while mvnw.cmd will fail the build with
an error if a duplicate is defined:
{noformat}
ConvertFrom-StringData : Data item 'distributionUrl' in line
'distributionUrl=https://nexus.synope.com/repository/tools/maven/apache-maven-3.9.2-SNAPSHOT-bin.zip'
is already defined.
At line:54 char:91
+ ... vn/wrapper/maven-wrapper.properties" | ConvertFrom-StringData).distri ...
+ ~~
+ CategoryInfo : InvalidOperation: (:) [ConvertFrom-StringData],
PSInvalidOperationException
+ FullyQualifiedErrorId :
InvalidOperation,Microsoft.PowerShell.Commands.ConvertFromStringDataCommand
ECHO is on.
Cannot start maven from wrapper{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704377#comment-17704377
]
Delany commented on MWRAPPER-101:
-
Anyway, not the issue here. pls close
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-105) mvnd distributionURL support for mvn qualifiers
Delany created MWRAPPER-105: --- Summary: mvnd distributionURL support for mvn qualifiers Key: MWRAPPER-105 URL: https://issues.apache.org/jira/browse/MWRAPPER-105 Project: Maven Wrapper Issue Type: Bug Affects Versions: 3.2.0 Reporter: Delany The wrapper cannot determine the correct URL for mvnd's new qualified form which allows selecting the mvn version, for instance mvn wrapper:3.2.0:wrapper -Dmvnd=1.0-m6-m39 -Dtype=only-script [https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0-m6/maven-mvnd-1.0-m6-m39-bin.zip] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7747) Large blocks of whitespace in plugin debug logs
Delany created MNG-7747:
---
Summary: Large blocks of whitespace in plugin debug logs
Key: MNG-7747
URL: https://issues.apache.org/jira/browse/MNG-7747
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.0
Reporter: Delany
I get large blocks of whitespace in debug logs when running the
formatter-maven-plugin. Author claims its a Maven issue
[https://github.com/revelc/formatter-maven-plugin/issues/713]
Reproduce with
{code:java}
git clone --branch issue-713
https://github.com/delanym/formatter-maven-plugin.git
cd formatter-maven-plugin
./do{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEPLOY-307) [REGRESSION] Longer deploy times
[ https://issues.apache.org/jira/browse/MDEPLOY-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703281#comment-17703281 ] Delany commented on MDEPLOY-307: That's fixed it. Back to normal with Maven 3.9.1 and maven-deploy-plugin 3.1.0 > [REGRESSION] Longer deploy times > > > Key: MDEPLOY-307 > URL: https://issues.apache.org/jira/browse/MDEPLOY-307 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 3.1.0 >Reporter: Delany >Priority: Major > > On Windows OS, a 500 module build takes half an hour to deploy when using > deployAtEnd. > I was expecting an improvement in build time with this version of the plugin. > Maven 3.9.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOURCES-293) Resources should not be read-only
[
https://issues.apache.org/jira/browse/MRESOURCES-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703124#comment-17703124
]
Delany commented on MRESOURCES-293:
---
[~cstamas] maybe just leave it as is? Ad hoc resource copying is covered with
[https://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html]
We all seem to agree its the documentation that causes the confusion.
> Resources should not be read-only
> -
>
> Key: MRESOURCES-293
> URL: https://issues.apache.org/jira/browse/MRESOURCES-293
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Delany
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.3.1
>
>
> With Maven 3.9.0 I'm getting lots of these warnings
> {noformat}
> [WARNING] Parameter 'resources' is read-only, must not be used in
> configuration{noformat}
> Clearly it shouldn't be marked read-only
> https://maven.apache.org/plugins/maven-resources-plugin/examples/resource-directory.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-475) Only evaluate after aggregating pluginManagement
[ https://issues.apache.org/jira/browse/MENFORCER-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702366#comment-17702366 ] Delany commented on MENFORCER-475: -- [~sjaranowski] there's no issue until 4.0.0-alpha-5. I tested 3.8.8, 3.9.1, 4.0.0-alpha-4 [https://github.com/delanym/MENFORCER-475] Run `./mvnw -Pextra` > Only evaluate after aggregating pluginManagement > > > Key: MENFORCER-475 > URL: https://issues.apache.org/jira/browse/MENFORCER-475 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: requirePluginVersions >Affects Versions: 3.2.1 >Reporter: Delany >Priority: Major > > The rule fails if a plugin is configured in 2 pluginManagement sections (one > of which is in a profile), and the profile's pluginManagement does not > configure a plugin version. > Profiles are often used to augment the existing configuration for a plugin, > so there's no need to repeat the version number. > However if the profile is introducing the plugin to the build, then a version > tag should be required. > The rule should evaluate whether a version number has been set after > aggregating the configurations and resolving the profiles. > This is a new issue from Maven 4.0.0-alpha-5 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-475) Only evaluate after aggregating pluginManagement
Delany created MENFORCER-475: Summary: Only evaluate after aggregating pluginManagement Key: MENFORCER-475 URL: https://issues.apache.org/jira/browse/MENFORCER-475 Project: Maven Enforcer Plugin Issue Type: Bug Components: requirePluginVersions Affects Versions: 3.2.1 Reporter: Delany The rule fails if a plugin is configured in 2 pluginManagement sections (one of which is in a profile), and the profile's pluginManagement does not configure a plugin version. Profiles are often used to augment the existing configuration for a plugin, so there's no need to repeat the version number. However if the profile is introducing the plugin to the build, then a version tag should be required. The rule should evaluate whether a version number has been set after aggregating the configurations and resolving the profiles. This is a new issue from Maven 4.0.0-alpha-5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-332) Could not acquire write lock
[
https://issues.apache.org/jira/browse/MRESOLVER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700811#comment-17700811
]
Delany commented on MRESOLVER-332:
--
I got this issue once. Close the ticket if you want - there'll be a record for
future
> Could not acquire write lock
>
>
> Key: MRESOLVER-332
> URL: https://issues.apache.org/jira/browse/MRESOLVER-332
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Delany
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> *
> {noformat}
> 07:59:36 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce (fail) on
> project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> -> [Help 1]
> 07:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
> (fail) on project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'07:59:36 Caused by:
> java.lang.IllegalStateException: Could not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> 07:59:36 at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:184)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:276)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> 07:59:36 at
> org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.resolveArtifact
> (AbstractResolveDependencies.java:152)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getAllDescendants
> (AbstractResolveDependencies.java:124)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getDependenciesToCheck
> (AbstractResolveDependencies.java:95)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.execute
> (AbstractResolveDependencies.java:76)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRuleOld
> (EnforceMojo.java:342)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRule
> (EnforceMojo.java:323)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:248)
> 07:59:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> 07:59:36 at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:193)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:180)
> 07:59:36 at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> 07:59:36 at java.util.concurrent.Executors$RunnableAdapter.call
>
[jira] [Created] (MPH-204) Use pluginRepositories not repositories
Delany created MPH-204: -- Summary: Use pluginRepositories not repositories Key: MPH-204 URL: https://issues.apache.org/jira/browse/MPH-204 Project: Maven Help Plugin Issue Type: Bug Components: describe Affects Versions: 3.4.0 Reporter: Delany The describe goal should retrieve the requested artifact from the available pluginRepositories, not from repositories. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1771#comment-1771
]
Delany commented on MWRAPPER-101:
-
I wonder if an authorization header can be generated from .m2/settings.xml by
matching it up with a user-only userinfo field:
distributionUrl=https://ne...@downloads.myserver.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
{code:java}
nexus
proxies
alskdjflks
{code}
wget and curl can do that. The most difficult part is parsing settings.xml
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699853#comment-17699853
]
Delany commented on MWRAPPER-101:
-
[~sjaranowski] what about this section of the documentation
[https://maven.apache.org/wrapper/#using-a-maven-repository-manager] where it
says
{noformat}
If not set, but your mirror URL in your settings.xml is configured, it will be
used.{noformat}
What does this mean?
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699853#comment-17699853
]
Delany edited comment on MWRAPPER-101 at 3/13/23 10:14 PM:
---
[~sjaranowski] what about this section of the documentation
[https://maven.apache.org/wrapper/#using-a-maven-repository-manager] where it
says
{noformat}
If not set, but your mirror URL in your settings.xml is configured, it will be
used.{noformat}
What does this mean?
was (Author: delany):
[~sjaranowski] what about this section of the documentation
[https://maven.apache.org/wrapper/#using-a-maven-repository-manager] where it
says
{noformat}
If not set, but your mirror URL in your settings.xml is configured, it will be
used.{noformat}
What does this mean?
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
[
https://issues.apache.org/jira/browse/MWRAPPER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699828#comment-17699828
]
Delany commented on MWRAPPER-101:
-
Thanks, MVNW_VERBOSE helped me figure it out. There probably was network, just
very slow.
For the proxied repo, I need to provide credentials, and I would rather not use
the env vars or userinfo options:
[https://maven.apache.org/wrapper/#using-basic-authentication-for-distribution-download]
I want to keep my credentials in settings.xml (so that
[https://maven.apache.org/guides/mini/guide-encryption.html]) and use the
mirror option
[https://maven.apache.org/wrapper/#using-a-maven-repository-manager] but its
not clear how I would do this. The mirror with central
could mirror the *distributionUrl* and *wrapperUrl* since they are both at
Maven central, and maven always defines the central repo in the super pom.
But with mvnd the situation is different because *distributionUrl* points to
downloads.apache.org
> Cannot set distributionUrl to maven-mvnd
>
>
> Key: MWRAPPER-101
> URL: https://issues.apache.org/jira/browse/MWRAPPER-101
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
> Environment: Linux
>Reporter: Delany
>Priority: Major
>
> Issue MWRAPPER-80 should have allowed me to set
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
> {code}
> When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
> change the URL as above, and then run `./mvnw validate -N -X` Maven hangs
> with no output and no network activity.
> If I use a proxied Nexus repository for download.apache.org Maven exits
> immediately with exit code 6.
> If I try avoid the guessing and set the final binary name
> {code:java}
> distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
> I get this message "distributionUrl is not valid, must match *-bin.zip or
> maven-mvnd-*.zip"
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-101) Cannot set distributionUrl to maven-mvnd
Delany created MWRAPPER-101:
---
Summary: Cannot set distributionUrl to maven-mvnd
Key: MWRAPPER-101
URL: https://issues.apache.org/jira/browse/MWRAPPER-101
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.2.0
Environment: Linux
Reporter: Delany
Issue MWRAPPER-80 should have allowed me to set
{code:java}
distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-bin.zip
{code}
When I run `./mvnw wrapper:wrapper -Dmaven=3.9.0 -Dtype=only-script` then
change the URL as above, and then run `./mvnw validate -N -X` Maven hangs with
no output and no network activity.
If I use a proxied Nexus repository for download.apache.org Maven exits
immediately with exit code 6.
If I try avoid the guessing and set the final binary name
{code:java}
distributionUrl=https://downloads.apache.org/maven/mvnd/0.9.0/maven-mvnd-0.9.0-linux-amd64.tar.gz{code}
I get this message "distributionUrl is not valid, must match *-bin.zip or
maven-mvnd-*.zip"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-332) Could not acquire write lock
[
https://issues.apache.org/jira/browse/MRESOLVER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694883#comment-17694883
]
Delany commented on MRESOLVER-332:
--
What should each of these be? LOCK_FACTORY, NAME_MAPPER, JOB_COUNT, BUILD_COUNT
Also, I hope Im at the right place for this as the error message I got was
"Could not acquire write lock for" not the grep string "Failed to acquire"?
> Could not acquire write lock
>
>
> Key: MRESOLVER-332
> URL: https://issues.apache.org/jira/browse/MRESOLVER-332
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Delany
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> *
> {noformat}
> 07:59:36 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce (fail) on
> project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> -> [Help 1]
> 07:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
> (fail) on project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'07:59:36 Caused by:
> java.lang.IllegalStateException: Could not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> 07:59:36 at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:184)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:276)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> 07:59:36 at
> org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.resolveArtifact
> (AbstractResolveDependencies.java:152)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getAllDescendants
> (AbstractResolveDependencies.java:124)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getDependenciesToCheck
> (AbstractResolveDependencies.java:95)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.execute
> (AbstractResolveDependencies.java:76)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRuleOld
> (EnforceMojo.java:342)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRule
> (EnforceMojo.java:323)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:248)
> 07:59:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> 07:59:36 at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:193)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:180)
>
[jira] [Comment Edited] (MRESOLVER-332) Could not acquire write lock
[
https://issues.apache.org/jira/browse/MRESOLVER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694416#comment-17694416
]
Delany edited comment on MRESOLVER-332 at 2/28/23 8:18 AM:
---
It says "At least Maven 4.0.0-alpha-1 and Maven Resolver 1.7.1 installed". Does
it still apply?
I dont see how I can fulfill the other requirements. The lock issue occurs on
Windows Server.
was (Author: delany):
It says "At least Maven 4.0.0-alpha-1 and Maven Resolver 1.7.1 installed". Does
it still apply?
> Could not acquire write lock
>
>
> Key: MRESOLVER-332
> URL: https://issues.apache.org/jira/browse/MRESOLVER-332
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Delany
>Priority: Major
>
> *
> {noformat}
> 07:59:36 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce (fail) on
> project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> -> [Help 1]
> 07:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
> (fail) on project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'07:59:36 Caused by:
> java.lang.IllegalStateException: Could not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> 07:59:36 at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:184)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:276)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> 07:59:36 at
> org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.resolveArtifact
> (AbstractResolveDependencies.java:152)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getAllDescendants
> (AbstractResolveDependencies.java:124)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getDependenciesToCheck
> (AbstractResolveDependencies.java:95)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.execute
> (AbstractResolveDependencies.java:76)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRuleOld
> (EnforceMojo.java:342)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRule
> (EnforceMojo.java:323)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:248)
> 07:59:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> 07:59:36 at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:193)
> 07:59:36 at
>
[jira] [Commented] (MRESOLVER-332) Could not acquire write lock
[
https://issues.apache.org/jira/browse/MRESOLVER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694416#comment-17694416
]
Delany commented on MRESOLVER-332:
--
It says "At least Maven 4.0.0-alpha-1 and Maven Resolver 1.7.1 installed". Does
it still apply?
> Could not acquire write lock
>
>
> Key: MRESOLVER-332
> URL: https://issues.apache.org/jira/browse/MRESOLVER-332
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Delany
>Priority: Major
>
> *
> {noformat}
> 07:59:36 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce (fail) on
> project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> -> [Help 1]
> 07:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
> (fail) on project distribution-noidentityjars: Execution fail of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could
> not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'07:59:36 Caused by:
> java.lang.IllegalStateException: Could not acquire write lock for
> 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
> 07:59:36 at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:184)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:276)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> 07:59:36 at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> 07:59:36 at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> 07:59:36 at
> org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.resolveArtifact
> (AbstractResolveDependencies.java:152)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getAllDescendants
> (AbstractResolveDependencies.java:124)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getDependenciesToCheck
> (AbstractResolveDependencies.java:95)
> 07:59:36 at
> org.apache.maven.plugins.enforcer.AbstractResolveDependencies.execute
> (AbstractResolveDependencies.java:76)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRuleOld
> (EnforceMojo.java:342)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRule
> (EnforceMojo.java:323)
> 07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:248)
> 07:59:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:342)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> 07:59:36 at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> 07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:193)
> 07:59:36 at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:180)
> 07:59:36 at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> 07:59:36 at java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:515)
> 07:59:36 at
[jira] [Created] (MRESOLVER-332) Could not acquire write lock
Delany created MRESOLVER-332:
Summary: Could not acquire write lock
Key: MRESOLVER-332
URL: https://issues.apache.org/jira/browse/MRESOLVER-332
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Affects Versions: 1.9.4
Reporter: Delany
*
{noformat}
07:59:36 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce (fail) on project
distribution-noidentityjars: Execution fail of goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could not
acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0' ->
[Help 1]
07:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
(fail) on project distribution-noidentityjars: Execution fail of goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce failed: Could not
acquire write lock for 'artifact:org.junit.jupiter:junit-jupiter:5.9.0'07:59:36
Caused by: java.lang.IllegalStateException: Could not acquire write lock for
'artifact:org.junit.jupiter:junit-jupiter:5.9.0'
07:59:36 at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:184)
07:59:36 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:276)
07:59:36 at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:255)
07:59:36 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
(DefaultRepositorySystem.java:296)
07:59:36 at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:197)
07:59:36 at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:413)
07:59:36 at
org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
(LegacyRepositorySystem.java:332)
07:59:36 at
org.apache.maven.plugins.enforcer.AbstractResolveDependencies.resolveArtifact
(AbstractResolveDependencies.java:152)
07:59:36 at
org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getAllDescendants
(AbstractResolveDependencies.java:124)
07:59:36 at
org.apache.maven.plugins.enforcer.AbstractResolveDependencies.getDependenciesToCheck
(AbstractResolveDependencies.java:95)
07:59:36 at
org.apache.maven.plugins.enforcer.AbstractResolveDependencies.execute
(AbstractResolveDependencies.java:76)
07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRuleOld
(EnforceMojo.java:342)
07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.executeRule
(EnforceMojo.java:323)
07:59:36 at org.apache.maven.plugins.enforcer.EnforceMojo.execute
(EnforceMojo.java:248)
07:59:36 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:342)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:330)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:175)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:76)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:163)
07:59:36 at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
07:59:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:160)
07:59:36 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
07:59:36 at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:193)
07:59:36 at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:180)
07:59:36 at java.util.concurrent.FutureTask.run (FutureTask.java:264)
07:59:36 at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:515)
07:59:36 at java.util.concurrent.FutureTask.run (FutureTask.java:264)
07:59:36 at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
07:59:36 at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
07:59:36 at java.lang.Thread.run (Thread.java:829){noformat}
* maven v3.9.0
* maven-enforcer-plugin v3.2.1
via Jenkins on Windows Server 2016
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRRESOURCES-123) Maven Remote Resources Plugin cannot load resource bundle from remote repository
[
https://issues.apache.org/jira/browse/MRRESOURCES-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17691265#comment-17691265
]
Delany commented on MRRESOURCES-123:
Confirmed that is used to work on 1.7.0 and doesn't on 3.0.0
> Maven Remote Resources Plugin cannot load resource bundle from remote
> repository
>
>
> Key: MRRESOURCES-123
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-123
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Andrei Mizurou
>Priority: Major
>
> After upgrading from 1.7.0 to 3.0.0, the application is unable to download
> the resourceBundle from a custom remote repository which is defined in
> `pom.xml`. We got the following error:
>
> {code:java}
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process' with
> basic configurator -->
> [DEBUG] (f) appendedResourcesDirectory =
> /Users/myuser/workdir/projects/myservice/src/main/appended-resources
> [DEBUG] (f) attachToMain = false
> [DEBUG] (f) attachToTest = false
> [DEBUG] (f) basedir = /Users/myuser/workdir/projects/myservice
> [DEBUG] (f) encoding = UTF-8
> [DEBUG] (f) excludeTransitive = false
> [DEBUG] (f) includeProjectProperties = false
> [DEBUG] (f) includeScope = runtime
> [DEBUG] (f) localRepository = id: local
> url: file:///Users/myuser/.m2/repository/
> layout: default
> snapshots: [enabled => true, update => always]
> releases: [enabled => true, update => always]
> blocked: false
> [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@5f780a86
> [DEBUG] (f) outputDirectory =
> /Users/myuser/workdir/projects/myservice/target/docker
> [DEBUG] (f) project = MavenProject:
> com.mycompany.services:myservice:0.0.1-SNAPSHOT @
> /Users/myuser/workdir/projects/myservice/pom.xml
> [DEBUG] (f) remoteArtifactRepositories = [ id: artifactory
> url: https://artifactory.mycompany.com/artifactory/maven-repo/
> layout: default
> snapshots: [enabled => true, update => daily]
> releases: [enabled => true, update => daily]
> blocked: false
> , id: central
> url: https://repo.maven.apache.org/maven2
> layout: default
> snapshots: [enabled => false, update => daily]
> releases: [enabled => true, update => daily]
> blocked: false
> ]
> [DEBUG] (f) resourceBundles = [com.mycompany.services:remote-template:1.0.6]
> [DEBUG] (f) resources = [Resource {targetPath: null, filtering: false,
> FileSet {directory:
> /Users/myuser/workdir/projects/myservice/src/main/resources, PatternSet
> [includes: {}, excludes: {}]}}]
> [DEBUG] (f) runOnlyAtExecutionRoot = false
> [DEBUG] (f) skip = false
> [DEBUG] (f) useDefaultFilterDelimiters = true
> [DEBUG] (f) velocityFilterInMemoryThreshold = 5242880
> [DEBUG] -- end configuration --
> {code}
>
> {code:java}
> [INFO] Preparing remote bundle com.mycompany.services:remote-template:1.0.6
> [DEBUG] Verifying availability of
> /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom
> from [central (https://repo.maven.apache.org/maven2, default, releases)]
> [DEBUG] Resolving artifact com.mycompany.services:remote-template:1.0.62 from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2
> Downloading from central:
> https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom
> [DEBUG] Writing tracking file
> /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom.lastUpdated
> [WARNING] The POM for com.mycompany.services:remote-template:jar:1.0.6 is
> missing, no dependency information available
> [DEBUG] Resolving artifact com.mycompany.services:remote-template:jar:1.0.6
> from [central (https://repo.maven.apache.org/maven2, default, releases)]
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2
> Downloading from central:
> https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.jar
> [DEBUG] Writing tracking file
> /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.jar.lastUpdated
> [INFO]
>
> [INFO] BUILD FAILURE
> Caused by:
[jira] [Created] (MINVOKER-328) Plugin tries to install dependency to same path when localRepositoryPath not set
Delany created MINVOKER-328:
---
Summary: Plugin tries to install dependency to same path when
localRepositoryPath not set
Key: MINVOKER-328
URL: https://issues.apache.org/jira/browse/MINVOKER-328
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Delany
The plugin tries to install a dependency from local Maven repository to the
same location:
{code:java}
Installing
/home/sol/.m2/repository/org/apache/maven/maven-core/3.9.0/maven-core-3.9.0.jar
to
/home/sol/.m2/repository/org/apache/maven/maven-core/3.9.0/maven-core-3.9.0.jar
{code}
Reproduce with
[https://github.com/delanym/MINVOKER-283.git]
No
{{[|https://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath]}}
was set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINVOKER-283) Change in behaviour with maven 3.8.2, invoker plugin is trying to install its parent
[ https://issues.apache.org/jira/browse/MINVOKER-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690703#comment-17690703 ] Delany commented on MINVOKER-283: - Broken in 3.5.0 (Maven 3.9.0) [https://github.com/delanym/MINVOKER-283.git] New ticket? > Change in behaviour with maven 3.8.2, invoker plugin is trying to install its > parent > > > Key: MINVOKER-283 > URL: https://issues.apache.org/jira/browse/MINVOKER-283 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.2.1, 3.2.2 > Environment: mvn -f pom.xml -s /maven/settings.xml --version > Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f) > Maven home: /usr/local/Cellar/maven/3.8.2/libexec > Java version: 16.0.2, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk/16.0.2/libexec/openjdk.jdk/Contents/Home > Default locale: en_NZ, platform encoding: UTF-8 > OS name: "mac os x", version: "11.5.2", arch: "x86_64", family: "mac" >Reporter: Jonathan Tew >Priority: Major > > When running maven 3.8.2, the integration test phase attempts the > installation of the parent. > > It fails when its already present in the respository. > > This is a change in behaviour from running on maven 3.8.1. > h2. maven 3.8.2 > > [*INFO*] *---* maven-invoker-plugin:3.2.1:install *(...integration-test)* @ > something-v3 *---* > [*INFO*] Installing > /..blah../maven/repository/blah/blah-parent/2.10/blah-parent-2.10.pom to > /..blah../maven/repository/blah/blah-parent/2.10/blah-parent-2.10.pom > [*INFO*] > ** > [*INFO*] *BUILD FAILURE* > [*INFO*] > ** > [*INFO*] Total time: 8.758 s > [*INFO*] Finished at: 2021-08-27T09:48:34+12:00 > [*INFO*] > ** > [*INFO*] Totally detected 0 potential finishing task(s) > [*ERROR*] Failed to execute goal > org.apache.maven.plugins:maven-invoker-plugin:3.2.1:install > *(...integration-test)* on project something-v3: *Failed to install project > parents: MavenProject: something:something-v3:1.999-SNAPSHOT @ > something-v3/pom.xml*: Failed to install POM: MavenProject: > blah:blah-parent:2.10 @ > /..blah../maven/repository/blah/blah-parent/2.10/blah-parent-2.10.pom: Failed > to install artifact: blah:blah-parent:pom:2.10: Failed to install artifact > blah:blah-parent:pom:2.10: cannot install > /..blah../maven/repository/blah/blah-parent/2.10/blah-parent-2.10.pom to same > path -> *[Help 1]* > > > > h2. maven 3.8.1 > [*INFO*] *---* maven-invoker-plugin:3.2.1:integration-test > *(integration-test)* @ something-v3 *---* > [*INFO*] Building: *sanity/pom.xml* > [*INFO*] Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) > [*INFO*] Maven home: /usr/local/Cellar/maven/3.8.1 > [*INFO*] Java version: 16.0.2, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk/16.0.2/libexec/openjdk.jdk/Contents/Home > [*INFO*] Default locale: en_NZ, platform encoding: UTF-8 > [*INFO*] OS name: "mac os x", version: "11.5.2", arch: "x86_64", family: "mac" > [*INFO*] [INFO] Error stacktraces are turned on. > [*INFO*] [INFO] Scanning for projects... > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEPLOY-306) [REGRESSION] Could not acquire write lock
[
https://issues.apache.org/jira/browse/MDEPLOY-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688705#comment-17688705
]
Delany commented on MDEPLOY-306:
I'll send when it does. This happened once out of the last 5 builds.
> [REGRESSION] Could not acquire write lock
> -
>
> Key: MDEPLOY-306
> URL: https://issues.apache.org/jira/browse/MDEPLOY-306
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Major
>
> On Windows OS, project with 500 modules fails build on final module with
> deployAtEnd set to true.
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
> project x: Execution default-deploy of goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
> acquire write lock for 'y'{noformat}
> Maven 3.9.0
> I've used deployAtEnd in the past without issue (but not with Maven 3.9.0)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEPLOY-306) [REGRESSION] Could not acquire write lock
[
https://issues.apache.org/jira/browse/MDEPLOY-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Delany updated MDEPLOY-306:
---
Description:
On Windows OS, project with 500 modules fails build on final module with
deployAtEnd set to true.
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
project x: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
acquire write lock for 'y'{noformat}
Maven 3.9.0
I've used deployAtEnd in the past without issue (but not with Maven 3.9.0)
was:
On Windows OS, project with 500 modules fails build on final module with
deployAtEnd set to true.
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
project x: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
acquire write lock for 'y'{noformat}
I've used deployAtEnd in the past without issue.
> [REGRESSION] Could not acquire write lock
> -
>
> Key: MDEPLOY-306
> URL: https://issues.apache.org/jira/browse/MDEPLOY-306
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Major
>
> On Windows OS, project with 500 modules fails build on final module with
> deployAtEnd set to true.
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
> project x: Execution default-deploy of goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
> acquire write lock for 'y'{noformat}
> Maven 3.9.0
> I've used deployAtEnd in the past without issue (but not with Maven 3.9.0)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEPLOY-307) [REGRESSION] Longer deploy times
Delany created MDEPLOY-307: -- Summary: [REGRESSION] Longer deploy times Key: MDEPLOY-307 URL: https://issues.apache.org/jira/browse/MDEPLOY-307 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy Affects Versions: 3.1.0 Reporter: Delany On Windows OS, a 500 module build takes half an hour to deploy when using deployAtEnd. I was expecting an improvement in build time with this version of the plugin. Maven 3.9.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MDEPLOY-306) [REGRESSION] Could not acquire write lock
[
https://issues.apache.org/jira/browse/MDEPLOY-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Delany updated MDEPLOY-306:
---
Description:
On Windows OS, project with 500 modules fails build on final module with
deployAtEnd set to true.
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
project x: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
acquire write lock for 'y'{noformat}
I've used deployAtEnd in the past without issue.
was:
On Windows OS, project with 500 modules fails build on final module with
deployAtEnd set to true.
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
project x: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
acquire write lock for 'y'{noformat}
Summary: [REGRESSION] Could not acquire write lock (was: Could not
acquire write lock)
> [REGRESSION] Could not acquire write lock
> -
>
> Key: MDEPLOY-306
> URL: https://issues.apache.org/jira/browse/MDEPLOY-306
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Major
>
> On Windows OS, project with 500 modules fails build on final module with
> deployAtEnd set to true.
> {noformat}
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
> project x: Execution default-deploy of goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
> acquire write lock for 'y'{noformat}
> I've used deployAtEnd in the past without issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEPLOY-306) Could not acquire write lock
Delany created MDEPLOY-306:
--
Summary: Could not acquire write lock
Key: MDEPLOY-306
URL: https://issues.apache.org/jira/browse/MDEPLOY-306
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 3.1.0
Reporter: Delany
On Windows OS, project with 500 modules fails build on final module with
deployAtEnd set to true.
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy (default-deploy) on
project x: Execution default-deploy of goal
org.apache.maven.plugins:maven-deploy-plugin:3.1.0:deploy failed: Could not
acquire write lock for 'y'{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOURCES-293) Resources should not be read-only
[
https://issues.apache.org/jira/browse/MRESOURCES-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684956#comment-17684956
]
Delany commented on MRESOURCES-293:
---
{quote}With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
Hyrum's Law
{quote}
In the end it was a combination of factors that led to me turn off the
default-resources execution and create my own discrete executions.
For one thing, the build/resources element is shared among multiple resource
mojo executions so i couldn't use it.
To answer the question why a resource was missing from a JAR I had to consider
(as a complete novice to Maven)
* multiple build/resources/resource elements in one pom
* inherited build/resources configuration via help-plugin effective-pom
* multiple and often competing include/exclude filters
* mistake in the glob patterns
* filters are laissez-faire/passthru style - no match does not fail the build,
and since the logs never show filename I had to add a guard in the form of the
verifications-plugin which checked resources were actually copied
*
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#outputDirectory]
*
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#overwrite]
*
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#usebuildfilters]
* did the resources plugin override a generated resource from
jaxb/jaxws/xmlbeans. This can get really tricky especially with both jaxb and
jaxws plugins
* before sortpom, moving config around could result in a change in plugin
execution order, and before I discovered buildplan-plugin I wouldn't have known
* resources were needed from other modules. They were retrieved using ../
syntax. Eventually I replaced this with maven-remote-resources-plugin
No wonder I got this job, no one else wanted it! How many plugins I mention?!
There are too many ways resource copying can go wrong and too few ways to check
that it works. I went as far as providing a [https://diffoscope.org/] view of
all the unpacked artefacts.
So no thanks build/resources. It looked like a cheat so I threw it out and
achieved clarity and consistency in the configuration. Today I know exactly
what gets copied when and where - no more magic.
Moving forward though - I'm fine with this mojo warning about read-only. I see
the intention - its all obvious in retrospect.
For now
{code:java}
-Dorg.slf4j.simpleLogger.log.org.apache.maven.plugin.internal.ReadOnlyPluginParametersValidator=error{code}
For later I could try use copy-resources mojo instead.
Perhaps in addition to *Required* and *Optional* parameters the documentation
could mention *Prohibited* parameters?
> Resources should not be read-only
> -
>
> Key: MRESOURCES-293
> URL: https://issues.apache.org/jira/browse/MRESOURCES-293
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Delany
>Priority: Major
>
> With Maven 3.9.0 I'm getting lots of these warnings
> {noformat}
> [WARNING] Parameter 'resources' is read-only, must not be used in
> configuration{noformat}
> Clearly it shouldn't be marked read-only
> https://maven.apache.org/plugins/maven-resources-plugin/examples/resource-directory.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOURCES-293) Resources should not be read-only
[
https://issues.apache.org/jira/browse/MRESOURCES-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684671#comment-17684671
]
Delany commented on MRESOURCES-293:
---
[~cstamas] plugin configuration. We never use build/resources
> Resources should not be read-only
> -
>
> Key: MRESOURCES-293
> URL: https://issues.apache.org/jira/browse/MRESOURCES-293
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Delany
>Priority: Major
>
> With Maven 3.9.0 I'm getting lots of these warnings
> {noformat}
> [WARNING] Parameter 'resources' is read-only, must not be used in
> configuration{noformat}
> Clearly it shouldn't be marked read-only
> https://maven.apache.org/plugins/maven-resources-plugin/examples/resource-directory.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOURCES-293) Resources should not be read-only
Delany created MRESOURCES-293:
-
Summary: Resources should not be read-only
Key: MRESOURCES-293
URL: https://issues.apache.org/jira/browse/MRESOURCES-293
Project: Maven Resources Plugin
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Delany
With Maven 3.9.0 I'm getting lots of these warnings
{noformat}
[WARNING] Parameter 'resources' is read-only, must not be used in
configuration{noformat}
Clearly it shouldn't be marked read-only
https://maven.apache.org/plugins/maven-resources-plugin/examples/resource-directory.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-386) caching implementation
[
https://issues.apache.org/jira/browse/MENFORCER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681132#comment-17681132
]
Delany commented on MENFORCER-386:
--
Another minor point: "executed" should probably be "passed" as a rule that
fails will not log
> caching implementation
> --
>
> Key: MENFORCER-386
> URL: https://issues.apache.org/jira/browse/MENFORCER-386
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Priority: Major
> Fix For: wontfix-candidate
>
>
> The enforcer seems to cache results in a session but it does not persist them.
> The log will always say
> {noformat}
> [INFO] Adding ignore: META-INF/versions/*/module-info
> [INFO] Adding ignore: module-info{noformat}
> whether I add -D{{enforcer.ignoreCache}} or not. And in any case I don't see
> any module-info files being written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-462) ReactorModuleConvergence not cached in reactor
Delany created MENFORCER-462: Summary: ReactorModuleConvergence not cached in reactor Key: MENFORCER-462 URL: https://issues.apache.org/jira/browse/MENFORCER-462 Project: Maven Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 3.2.0 Reporter: Delany Rules like RequireJavaVersion & RequireMavenVersion are run once in a reactor, but ReactorModuleConvergence is repeated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-386) caching implementation
[
https://issues.apache.org/jira/browse/MENFORCER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681129#comment-17681129
]
Delany commented on MENFORCER-386:
--
I understand. Its a lot clearer now that I can see a log line for each rule
{noformat}
[INFO] Rule 0: org.apache.maven.enforcer.rules.ReactorModuleConvergence executed
[INFO] Rule 1: org.apache.maven.plugins.enforcer.RequireEncoding executed
[INFO] Rule 2: org.apache.maven.enforcer.rules.dependency.DependencyConvergence
executed
[INFO] Rule 3:
org.apache.maven.enforcer.rules.BanDuplicatePomDependencyVersions executed
[INFO] Adding ignore: module-info
[INFO] Adding ignore: META-INF/versions/*/module-info
[INFO] Rule 4: org.apache.maven.plugins.enforcer.BanDuplicateClasses executed
[INFO] Rule 5: org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps
executed
[INFO] Rule 6: org.apache.maven.plugins.enforcer.BanCircularDependencies
executed
[INFO] Rule 7:
org.commonjava.maven.enforcer.rule.EnforceManagedDepsRule(requireManagedDeps)
executed
[INFO] Rule 8:
com.hubspot.maven.plugins.dependency.management.DependencyManagementRule
executed
[INFO] Rule 9: org.apache.maven.enforcer.rules.version.RequireJavaVersion
executed
[INFO] Rule 10: org.apache.maven.enforcer.rules.version.RequireMavenVersion
executed{noformat}
Next module with cached rule 9 & 10
{noformat}
[INFO] Rule 0: org.apache.maven.enforcer.rules.ReactorModuleConvergence executed
[INFO] Rule 1: org.apache.maven.plugins.enforcer.RequireEncoding executed
[INFO] Rule 2: org.apache.maven.enforcer.rules.dependency.DependencyConvergence
executed
[INFO] Rule 3:
org.apache.maven.enforcer.rules.BanDuplicatePomDependencyVersions executed
[INFO] Adding ignore: module-info
[INFO] Adding ignore: META-INF/versions/*/module-info
[INFO] Rule 4: org.apache.maven.plugins.enforcer.BanDuplicateClasses executed
[INFO] Rule 5: org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps
executed
[INFO] Rule 6: org.apache.maven.plugins.enforcer.BanCircularDependencies
executed
[INFO] Rule 7:
org.commonjava.maven.enforcer.rule.EnforceManagedDepsRule(requireManagedDeps)
executed
[INFO] Rule 8:
com.hubspot.maven.plugins.dependency.management.DependencyManagementRule
executed{noformat}
But now logging "Adding ignore" is even more annoying
> caching implementation
> --
>
> Key: MENFORCER-386
> URL: https://issues.apache.org/jira/browse/MENFORCER-386
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Priority: Major
> Fix For: wontfix-candidate
>
>
> The enforcer seems to cache results in a session but it does not persist them.
> The log will always say
> {noformat}
> [INFO] Adding ignore: META-INF/versions/*/module-info
> [INFO] Adding ignore: module-info{noformat}
> whether I add -D{{enforcer.ignoreCache}} or not. And in any case I don't see
> any module-info files being written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-386) caching implementation
[
https://issues.apache.org/jira/browse/MENFORCER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678589#comment-17678589
]
Delany commented on MENFORCER-386:
--
Im quite happy with the way requireEncoding works - I get my parent project to
check the entire codebase for encoding issues.
Ok so I think we're getting 2 issues confused here. The one is caching within
the session. The other issue is persisting the results of the enforcer checks
so that in the next build enforcer doesn't run them again. If my build is
"clean install" then enforcer should check all the rules. If my build is
"install" it should not check any rules, because nothing has changed. Is this a
fair expectation?
> caching implementation
> --
>
> Key: MENFORCER-386
> URL: https://issues.apache.org/jira/browse/MENFORCER-386
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Priority: Major
> Fix For: wontfix-candidate
>
>
> The enforcer seems to cache results in a session but it does not persist them.
> The log will always say
> {noformat}
> [INFO] Adding ignore: META-INF/versions/*/module-info
> [INFO] Adding ignore: module-info{noformat}
> whether I add -D{{enforcer.ignoreCache}} or not. And in any case I don't see
> any module-info files being written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPMD-363) aggregate-cpd-check doesn't work on large projects
[
https://issues.apache.org/jira/browse/MPMD-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Delany updated MPMD-363:
Description:
I'm having some trouble with the aggregate-cpd-check goal in a large project.
The reactor build passes when it should fail. I know there are violations since
cpd-check fails a couple of modules individually. But on another smaller
project aggregate-cpd-check correctly fails the build.
I'm not able to share these projects, but I can share some logs. Here are the
relevant snippets starting after the first "[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.20.0:aggregate-cpd' with basic
configurator -->"
WORKING CORRECTLY (finds cpd violations):
{code:java}
[DEBUG] -- end configuration --
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[DEBUG] Exclusions:
**/*~,**/#*#,**/.#*,**/%*%,**/._*,**/CVS,**/CVS/**,**/.cvsignore,**/RCS,**/RCS/**,**/SCCS,**/SCCS/**,**/vssver.scc,**/project.pj,**/.svn,**/.svn/**,**/.arch-ids,**/.arch-ids/**,**/.bzr,**/.bzr/**,**/.MySCMServerInfo,**/.DS_Store,**/.metadata,**/.metadata/**,**/.hg,**/.hgignore,**/.hg/**,**/.git,**/.gitignore,**/.gitattributes,**/.git/**,**/BitKeeper,**/BitKeeper/**,**/ChangeSet,**/ChangeSet/**,**/_darcs,**/_darcs/**,**/.darcsrepo,**/.darcsrepo/**,**/-darcs-backup*,**/.darcs-temp-mail
[DEBUG] Inclusions: **/*.java
[DEBUG] Searching for files in directory
/git/izpack/customshortcutpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploydatabasepanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploydirectorypanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deployiiswebapppanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploywebapppanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/headlessdeploycomponentpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationmanagerpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationoptionspanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationospanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationselectionpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationstargetpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationsummarypanel/src/main/java
[DEBUG] Searching for files in directory /git/izpack/jrepathpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/licensepackpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/postinstallpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/preinstallpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/productpublicnamepanel/src/main/java
[DEBUG] Searching for files in directory /git/izpack/tomcatpanel/src/main/java
[INFO] PMD version: 6.53.0{code}
NOT WORKING CORRECTLY (doesn't find cpd violations):
{code:java}
[DEBUG] -- end configuration --
[DEBUG] Exclusions:
**/*~,**/#*#,**/.#*,**/%*%,**/._*,**/CVS,**/CVS/**,**/.cvsignore,**/RCS,**/RCS/**,**/SCCS,**/SCCS/**,**/vssver.scc,**/project.pj,**/.svn,**/.svn/**,**/.arch-ids,**/.arch-ids/**,**/.bzr,**/.bzr/**,**/.MySCMServerInfo,**/.DS_Store,**/.metadata,**/.metadata/**,**/.hg,**/.hgignore,**/.hg/**,**/.git,**/.gitignore,**/.gitattributes,**/.git/**,**/BitKeeper,**/BitKeeper/**,**/ChangeSet,**/ChangeSet/**,**/_darcs,**/_darcs/**,**/.darcsrepo,**/.darcsrepo/**,**/-darcs-backup*,**/.darcs-temp-mail
[DEBUG] Inclusions: **/*.java
[INFO] PMD version: 6.53.0{code}
Where are all the "Searching for files in directory"?
The only noticable difference between the configuration is the enormous
*reactorProjects* property (500 items).
was:
I'm having some trouble with the aggregate-cpd-check goal in a large
[jira] [Created] (MPMD-363) aggregate-cpd-check doesn't work on large projects
Delany created MPMD-363:
---
Summary: aggregate-cpd-check doesn't work on large projects
Key: MPMD-363
URL: https://issues.apache.org/jira/browse/MPMD-363
Project: Maven PMD Plugin
Issue Type: Bug
Components: CPD
Affects Versions: 3.20.0
Reporter: Delany
I'm having some trouble with the aggregate-cpd-check goal in a large project.
The reactor build passes when it should fail. I know there are violations since
cpd-check fails a couple of modules individually. But on another smaller
project aggregate-cpd-check correctly fails the build.
I'm not able to share these projects, but I can share some logs. Here are the
relevant snippets starting after the first "[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-pmd-plugin:3.20.0:aggregate-cpd' with basic
configurator -->"
WORKING CORRECTLY (finds cpd violations):
{code:java}
[DEBUG] -- end configuration --
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] Unable to locate Source XRef to link to - DISABLED
[DEBUG] Exclusions:
**/*~,**/#*#,**/.#*,**/%*%,**/._*,**/CVS,**/CVS/**,**/.cvsignore,**/RCS,**/RCS/**,**/SCCS,**/SCCS/**,**/vssver.scc,**/project.pj,**/.svn,**/.svn/**,**/.arch-ids,**/.arch-ids/**,**/.bzr,**/.bzr/**,**/.MySCMServerInfo,**/.DS_Store,**/.metadata,**/.metadata/**,**/.hg,**/.hgignore,**/.hg/**,**/.git,**/.gitignore,**/.gitattributes,**/.git/**,**/BitKeeper,**/BitKeeper/**,**/ChangeSet,**/ChangeSet/**,**/_darcs,**/_darcs/**,**/.darcsrepo,**/.darcsrepo/**,**/-darcs-backup*,**/.darcs-temp-mail
[DEBUG] Inclusions: **/*.java
[DEBUG] Searching for files in directory
/git/izpack/customshortcutpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploydatabasepanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploydirectorypanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deployiiswebapppanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/deploywebapppanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/headlessdeploycomponentpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationmanagerpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationoptionspanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationospanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationselectionpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationstargetpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/installationsummarypanel/src/main/java
[DEBUG] Searching for files in directory /git/izpack/jrepathpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/licensepackpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/postinstallpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/preinstallpanel/src/main/java
[DEBUG] Searching for files in directory
/git/izpack/productpublicnamepanel/src/main/java
[DEBUG] Searching for files in directory /git/izpack/tomcatpanel/src/main/java
[INFO] PMD version: 6.53.0{code}
NOT WORKING CORRECTLY (doesn't find cpd violations):
{code:java}
[DEBUG] -- end configuration --
[DEBUG] Exclusions:
**/*~,**/#*#,**/.#*,**/%*%,**/._*,**/CVS,**/CVS/**,**/.cvsignore,**/RCS,**/RCS/**,**/SCCS,**/SCCS/**,**/vssver.scc,**/project.pj,**/.svn,**/.svn/**,**/.arch-ids,**/.arch-ids/**,**/.bzr,**/.bzr/**,**/.MySCMServerInfo,**/.DS_Store,**/.metadata,**/.metadata/**,**/.hg,**/.hgignore,**/.hg/**,**/.git,**/.gitignore,**/.gitattributes,**/.git/**,**/BitKeeper,**/BitKeeper/**,**/ChangeSet,**/ChangeSet/**,**/_darcs,**/_darcs/**,**/.darcsrepo,**/.darcsrepo/**,**/-darcs-backup*,**/.darcs-temp-mail
[DEBUG] Inclusions: **/*.java
[INFO] PMD version: 6.53.0{code}
Where are all the "Searching for files in directory"?
[jira] [Commented] (MENFORCER-386) caching implementation
[
https://issues.apache.org/jira/browse/MENFORCER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678389#comment-17678389
]
Delany commented on MENFORCER-386:
--
I set lots of rules, but I especially want to avoid redoing
[https://www.mojohaus.org/extra-enforcer-rules/requireEncoding.html]
> caching implementation
> --
>
> Key: MENFORCER-386
> URL: https://issues.apache.org/jira/browse/MENFORCER-386
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Priority: Major
>
> The enforcer seems to cache results in a session but it does not persist them.
> The log will always say
> {noformat}
> [INFO] Adding ignore: META-INF/versions/*/module-info
> [INFO] Adding ignore: module-info{noformat}
> whether I add -D{{enforcer.ignoreCache}} or not. And in any case I don't see
> any module-info files being written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-405) purge-local-repository on multi-module project results in failure
[
https://issues.apache.org/jira/browse/MDEP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676512#comment-17676512
]
Delany commented on MDEP-405:
-
This goal seems broken by design - chicken-egg situation
> purge-local-repository on multi-module project results in failure
> -
>
> Key: MDEP-405
> URL: https://issues.apache.org/jira/browse/MDEP-405
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 2.6
>Reporter: Stephen Cooper
>Priority: Major
>
> I have several multi-module projects all suffering from this issue.
> As a post-build step in jenkins, we want to clean up the repository to keep
> disk space usage to a minimum.
> We execute the following:
> {code}
> mvn -f pom.xml -DsnapshotsOnly=false -DreResolve=false -Dverbose=true -e
> -Dmaven.repo.local=/var/lib/jenkins/maven-repositories/12
> dependency:purge-local-repository
> {code}
> We have reresolve set to false so that the files don't get downloaded again.
> This works fine for the first modules, but once we hit a module which has the
> same dependencies as a previous module, we get an error that we cannot
> resolve dependencies and the build fails.
> {code}
> [INFO] Building ften-rewind-1.0.2-SNAPSHOT 1.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.6:purge-local-repository (default-cli) @
> ften-rewind ---
> [INFO] Unable to resolve all dependencies for :
> com.ften.stream:ften-rewind:1.0.2-SNAPSHOT. Falling back to non-transitive
> mode for initial artifact resolution.
> [INFO] Purging dependencies for project:
> com.ften.stream:ften-rewind:jar:1.0.2-SNAPSHOT
> [INFO] Purging artifact: com.googlecode.jmockit:jmockit:jar:1.1
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/com/googlecode/jmockit/jmockit/1.1
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/com/googlecode/jmockit/jmockit/1.1
> [INFO] Purging artifact: junit:junit:jar:4.11
> [INFO] Deleting: /var/lib/jenkins/maven-repositories/12/junit/junit/4.11
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/junit/junit/4.11
> [INFO] Purging artifact: genium.common:risk-ring-framework:jar:1.0.2
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/risk-ring-framework/1.0.2
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/risk-ring-framework/1.0.2
> [INFO] Purging artifact: genium.common:imb:jar:2.0.48
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/imb/2.0.48
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/imb/2.0.48
> [INFO] Purging artifact: genium.common:framework-base:jar:1.2.5
> [INFO] Deleting:
> /var/lib/jenkins/maven-repositories/12/genium/common/framework-base/1.2.5
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/genium/common/framework-base/1.2.5
> [INFO] Purging artifact: amt:amt:jar:3.15.2
> [INFO] Deleting: /var/lib/jenkins/maven-repositories/12/amt/amt/3.15.2
> [WARNING] Unable to purge local repository location:
> /var/lib/jenkins/maven-repositories/12/amt/amt/3.15.2
> [INFO]
>
> [INFO]
>
> [INFO] Building ften-appmind-base 1.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.6:purge-local-repository (default-cli) @
> ften-appmind-base ---
> Downloading:
> http://nexus.carteret.ften.com//content/groups/public/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> Downloaded:
> http://nexus.carteret.ften.com//content/groups/public/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> (38 KB at 1687.5 KB/sec)
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] risk-ring-applications-1.0.2-SNAPSHOT . SUCCESS [4.565s]
> [INFO] ften-sequencer-1.0.2-SNAPSHOT . SUCCESS [4.587s]
> [INFO] sample-application-1.0.1-SNAPSHOT . SUCCESS [0.012s]
> [INFO] ften-rewind-1.0.2-SNAPSHOT SUCCESS [0.009s]
> [INFO] ften-appmind-base . FAILURE [0.183s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO]
[jira] [Commented] (MCHECKSTYLE-421) Audit events should use Maven logging
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654991#comment-17654991
]
Delany commented on MCHECKSTYLE-421:
Actually I don't agree - the authors of this plugin know how it interfaces with
checkstyle and whether its possible or not.
Its pointless me trying to log an issue with the checkstyle author
[https://github.com/checkstyle/checkstyle/issues/12585]
> Audit events should use Maven logging
> -
>
> Key: MCHECKSTYLE-421
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-421
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 3.2.0
>Reporter: Delany
>Priority: Major
>
> Firstly, it seems that the term "violation" is mutable - the plugin gets to
> decide what is and is not a violation. So when a checkstyle check fails I am
> calling that an "audit event".
> Audit events produced by configuring consoleOutput to true are being logged
> to stdout. I run all my builds with
> `-Dorg.slf4j.simpleLogger.defaultLogLevel=warn` so I dont see these.
> There should probably also be an example in the documentation of how to
> configure errors to fail the build while displaying warnings to the console,
> as this is surely the most natural assumption when someone runs the check
> goal?
> [https://stackoverflow.com/questions/10488137/maven-checkstyle-plugin-print-warnings-to-console]
> Please also make
> {noformat}
> Audit done.{noformat}
> like
> {noformat}
> [mvn-builder-artifact] [INFO]
> org.apache.maven.plugins.checkstyle.exec.DefaultCheckstyleExecutor - Starting
> audit...{noformat}
> as an info level event, or remove it.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-422) Print absolute paths
Delany created MCHECKSTYLE-422:
--
Summary: Print absolute paths
Key: MCHECKSTYLE-422
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-422
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Affects Versions: 3.2.0
Reporter: Delany
When the check goal prints a violation to the console it gives the relative path
{noformat}
[ERROR] src/main/java/...{noformat}
Off the top of my head all other plugins give absolute paths.
Absolute paths are necessary when running the build in IntelliJ's terminal. An
absolute path is recognized as such and one can simply click it to open the
file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-421) Audit events should use Maven logging
Delany created MCHECKSTYLE-421:
--
Summary: Audit events should use Maven logging
Key: MCHECKSTYLE-421
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-421
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Affects Versions: 3.2.0
Reporter: Delany
Firstly, it seems that the term "violation" is mutable - the plugin gets to
decide what is and is not a violation. So when a checkstyle check fails I am
calling that an "audit event".
Audit events produced by configuring consoleOutput to true are being logged to
stdout. I run all my builds with
`-Dorg.slf4j.simpleLogger.defaultLogLevel=warn` so I dont see these.
There should probably also be an example in the documentation of how to
configure errors to fail the build while displaying warnings to the console, as
this is surely the most natural assumption when someone runs the check goal?
[https://stackoverflow.com/questions/10488137/maven-checkstyle-plugin-print-warnings-to-console]
Please also make
{noformat}
Audit done.{noformat}
like
{noformat}
[mvn-builder-artifact] [INFO]
org.apache.maven.plugins.checkstyle.exec.DefaultCheckstyleExecutor - Starting
audit...{noformat}
as an info level event, or remove it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-514) Cant stack compiler plugin argument variations
[
https://issues.apache.org/jira/browse/MCOMPILER-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645146#comment-17645146
]
Delany commented on MCOMPILER-514:
--
Ok here's my workaround
{code:java}
-Xep:SuppressWarningsWithoutExplanation:WARN
...
-Xlint:all,-processing
-XDcompilePolicy=byfile
-Xplugin:ErrorProne -XepDisableAllChecks ${build.ep}
...
EPE
EPE
-Xep:${EPE}:ERROR
EPW
EPW
-Xep:${EPW}:WARN
EPP
EPP
-XepPatchLocation:IN_PLACE -XepPatchChecks:${EPP}
{code}
Then if I want the build to fail with DefaultCharset violations
{code:java}
./mvnw -DEPE=DefaultCharset {code}
> Cant stack compiler plugin argument variations
> --
>
> Key: MCOMPILER-514
> URL: https://issues.apache.org/jira/browse/MCOMPILER-514
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Delany
>Priority: Major
>
> This works
> {code:java}
>
> -Xlint:all,-processing
> -Xlint:all
> -XDcompilePolicy=byfile
> -Xplugin:ErrorProne
> -Xplugin:ErrorProne
> {code}
> But this
> {code:java}
>
> -Xlint:all,-processing
> -Xlint:all
> -XDcompilePolicy=byfile
> -Xplugin:ErrorProne
> -Xplugin:ErrorProne -XepDisableAllChecks
> {code}
> fails with this
> {noformat}
> [ERROR] org.apache.maven.cli.MavenCli - plug-in not found:
> ErrorProne{noformat}
> There is no problem stacking -Xlint argument variations, or stacking the
> -Xplugin argument (provided the argument is the same.) But it dies when the
> -Xplugin argument varies. Why should this be?
> Use case? I have separate profiles for activating various errorprone
> bugpatterns. I want a default configuration in place unless I activate one of
> these profiles. I dont want to have to edit source code every time to check a
> different bugpattern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-514) Cant stack compiler plugin argument variations
Delany created MCOMPILER-514:
Summary: Cant stack compiler plugin argument variations
Key: MCOMPILER-514
URL: https://issues.apache.org/jira/browse/MCOMPILER-514
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.10.1
Reporter: Delany
This works
{code:java}
-Xlint:all,-processing
-Xlint:all
-XDcompilePolicy=byfile
-Xplugin:ErrorProne
-Xplugin:ErrorProne
{code}
But this
{code:java}
-Xlint:all,-processing
-Xlint:all
-XDcompilePolicy=byfile
-Xplugin:ErrorProne
-Xplugin:ErrorProne -XepDisableAllChecks
{code}
fails with this
{noformat}
[ERROR] org.apache.maven.cli.MavenCli - plug-in not found: ErrorProne{noformat}
There is no problem stacking -Xlint argument variations, or stacking the
-Xplugin argument (provided the argument is the same.) But it dies when the
-Xplugin argument varies. Why should this be?
Use case? I have separate profiles for activating various errorprone
bugpatterns. I want a default configuration in place unless I activate one of
these profiles. I dont want to have to edit source code every time to check a
different bugpattern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-435) Plugin does not report actual error from ErrorProne when toolchain is used
[
https://issues.apache.org/jira/browse/MCOMPILER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645129#comment-17645129
]
Delany commented on MCOMPILER-435:
--
This is a problem with errorprone 2.4.0. I updated it to 2.16, ran it on JDK17
{noformat}
Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project maven-compiler-plugin-error-prone: Fatal error compiling:
-XepPatchChecks and -XepPatchLocation must be specified together{noformat}
> Plugin does not report actual error from ErrorProne when toolchain is used
> --
>
> Key: MCOMPILER-435
> URL: https://issues.apache.org/jira/browse/MCOMPILER-435
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Windows, Maven 3.6.3
>Reporter: Rocher Suchard
>Priority: Critical
> Attachments: maven-compiler-plugin-3.8.1-error-prone.zip
>
>
> Hello,
> I followed ErrorProne installation
> ([http://errorprone.info/docs/installation] and
> [http://errorprone.info/docs/patching]) but I did not provide a
> {{-XepPatchCheck}} which result in an error that {{maven-compiler-plugin}}
> fails to report when a toolchain is used:
> Without a toolchain, I get this error which is what I expect, eg: something
> that helps!
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on
> project maven-compiler-plugin-error-prone: Fatal error compiling:
> -XepPatchChecks and -XepPatchLocation must be specif
> ied together -> [Help 1]
> {code}
> With a JDK 11 toolchain, the error won't help, neither the (huge) stacktrace
> when using {{-e}}.
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on
> project maven-compiler-plugin-error-prone: Compilation failure -> [Help 1]
> {code}
> {{maven-compiler-plugin}} is unable to report correctly the
> {{com.google.errorprone.InvalidCommandLineOptionException}} thrown by
> ErrorProne when a toolchain is used (in this case, the toolchain is useless,
> but I have profile with Java 15).
> The attached file contains a sample project:
> - To test the case when it reports the ErrorProne exception, simply do
> {{./mvnw clean install}}
> - To test the case with a JDK 11 toolchain, simply do {{./mvnw
> -Puse-toolchain clean install}}
> Java 11 is both required to build, and as a toolchain.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-420) includes is broken
Delany created MCHECKSTYLE-420:
--
Summary: includes is broken
Key: MCHECKSTYLE-420
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-420
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Affects Versions: 3.2.0
Reporter: Delany
I thought I could achieve
[https://issues.apache.org/jira/projects/MCHECKSTYLE/issues/MCHECKSTYLE-412]
using *includes*
{code:java}
${build.root}/checkstyle.xml
src\/**\/*.java
{code}
but I dont get any violations. Neither with any of
{code:java}
src/**/*.java
**/src/**/*.java
**\/src\/**\/*.java{code}
I get 69 violations (files in src and target) using
{code:java}
${build.root}/checkstyle.xml
**\/*.java
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-829) excludes filter should function like exclusions
[
https://issues.apache.org/jira/browse/MDEP-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613935#comment-17613935
]
Delany commented on MDEP-829:
-
If its a problem to change, then maybe deprecate *includes* replacing with
{*}filter{*}, and *excludes* replacing with *exclusions*
> excludes filter should function like exclusions
> ---
>
> Key: MDEP-829
> URL: https://issues.apache.org/jira/browse/MDEP-829
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.3.0
>Reporter: Delany
>Priority: Major
>
> The -Dincludes parameter causes the tree goal to filter the resultant
> dependency tree: it returns matching dependencies {*}and their parents{*}.
> The -Dexcludes parameter uses the same logic, but returns non-matching
> dependencies {*}and their parents{*}. Why would anyone want this? Rather,
> excludes should remove matching dependencies from the initial dependency
> model (like dependency exclusions do), not just the resultant tree.
> Include is demonstrated at
> [https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html],
> but not exclude.
> If run the given exclude command
> {code:java}
> mvn dependency:tree -Dexcludes=org.codehaus.plexus{code}
> on the following tree
> {noformat}
> [INFO]
> org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0-alpha-5-SNAPSHOT
> [INFO] \- org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:compile
> [INFO] \- org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
> [INFO] \- velocity:velocity:jar:1.4:compile{noformat}
> the output is the same, since the velocity dependency needs to show its
> parent in the tree. This is pointless. Why would I only want to exclude the
> "leaves" of the tree?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-829) excludes filter should function like exclusions
[
https://issues.apache.org/jira/browse/MDEP-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613933#comment-17613933
]
Delany commented on MDEP-829:
-
Ok, I see in the last example on the page the use of excludes has some use
together with includes to remove snapshots from the output. But this is so
fringe case and could rather be accomplished with a negative glob filter which
better describes the intent
-Dincludes=org.codehaus.plexus:::!(*-SNAPSHOT)
> excludes filter should function like exclusions
> ---
>
> Key: MDEP-829
> URL: https://issues.apache.org/jira/browse/MDEP-829
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.3.0
>Reporter: Delany
>Priority: Major
>
> The -Dincludes parameter causes the tree goal to filter the resultant
> dependency tree: it returns matching dependencies {*}and their parents{*}.
> The -Dexcludes parameter uses the same logic, but returns non-matching
> dependencies {*}and their parents{*}. Why would anyone want this? Rather,
> excludes should remove matching dependencies from the initial dependency
> model (like dependency exclusions do), not just the resultant tree.
> Include is demonstrated at
> [https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html],
> but not exclude.
> If run the given exclude command
> {code:java}
> mvn dependency:tree -Dexcludes=org.codehaus.plexus{code}
> on the following tree
> {noformat}
> [INFO]
> org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0-alpha-5-SNAPSHOT
> [INFO] \- org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:compile
> [INFO] \- org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
> [INFO] \- velocity:velocity:jar:1.4:compile{noformat}
> the output is the same, since the velocity dependency needs to show its
> parent in the tree. This is pointless. Why would I only want to exclude the
> "leaves" of the tree?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MDEP-829) excludes filter should function like exclusions
[
https://issues.apache.org/jira/browse/MDEP-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613933#comment-17613933
]
Delany edited comment on MDEP-829 at 10/7/22 7:48 AM:
--
Ok, I see in the last example on the page the use of excludes has some use
together with includes to remove snapshots from the output. But this is so
fringe case and could rather be accomplished with a negative glob filter which
better describes the intent
{code:java}
-Dincludes=org.codehaus.plexus:::!(*-SNAPSHOT) {code}
was (Author: delany):
Ok, I see in the last example on the page the use of excludes has some use
together with includes to remove snapshots from the output. But this is so
fringe case and could rather be accomplished with a negative glob filter which
better describes the intent
-Dincludes=org.codehaus.plexus:::!(*-SNAPSHOT)
> excludes filter should function like exclusions
> ---
>
> Key: MDEP-829
> URL: https://issues.apache.org/jira/browse/MDEP-829
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.3.0
>Reporter: Delany
>Priority: Major
>
> The -Dincludes parameter causes the tree goal to filter the resultant
> dependency tree: it returns matching dependencies {*}and their parents{*}.
> The -Dexcludes parameter uses the same logic, but returns non-matching
> dependencies {*}and their parents{*}. Why would anyone want this? Rather,
> excludes should remove matching dependencies from the initial dependency
> model (like dependency exclusions do), not just the resultant tree.
> Include is demonstrated at
> [https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html],
> but not exclude.
> If run the given exclude command
> {code:java}
> mvn dependency:tree -Dexcludes=org.codehaus.plexus{code}
> on the following tree
> {noformat}
> [INFO]
> org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0-alpha-5-SNAPSHOT
> [INFO] \- org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:compile
> [INFO] \- org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
> [INFO] \- velocity:velocity:jar:1.4:compile{noformat}
> the output is the same, since the velocity dependency needs to show its
> parent in the tree. This is pointless. Why would I only want to exclude the
> "leaves" of the tree?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-829) excludes filter should function like exclusions
Delany created MDEP-829:
---
Summary: excludes filter should function like exclusions
Key: MDEP-829
URL: https://issues.apache.org/jira/browse/MDEP-829
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 3.3.0
Reporter: Delany
The -Dincludes parameter causes the tree goal to filter the resultant
dependency tree: it returns matching dependencies {*}and their parents{*}.
The -Dexcludes parameter uses the same logic, but returns non-matching
dependencies {*}and their parents{*}. Why would anyone want this? Rather,
excludes should remove matching dependencies from the initial dependency model
(like dependency exclusions do), not just the resultant tree.
Include is demonstrated at
[https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html],
but not exclude.
If run the given exclude command
{code:java}
mvn dependency:tree -Dexcludes=org.codehaus.plexus{code}
on the following tree
{noformat}
[INFO]
org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:2.0-alpha-5-SNAPSHOT
[INFO] \- org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-8:compile
[INFO] \- org.codehaus.plexus:plexus-velocity:jar:1.1.3:compile
[INFO] \- velocity:velocity:jar:1.4:compile{noformat}
the output is the same, since the velocity dependency needs to show its parent
in the tree. This is pointless. Why would I only want to exclude the "leaves"
of the tree?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHADE-141) keepDependenciesWithProvidedScope does not work
[ https://issues.apache.org/jira/browse/MSHADE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605290#comment-17605290 ] Delany commented on MSHADE-141: --- Still an issue with plugin version 3.4.0 in the dependency-reduced-pom.xml > keepDependenciesWithProvidedScope does not work > --- > > Key: MSHADE-141 > URL: https://issues.apache.org/jira/browse/MSHADE-141 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Steve Tynor >Priority: Major > Fix For: waiting-for-feedback > > Attachments: pom-direct.xml, pom-indirect.xml > > > keepDependenciesWithProvidedScope option does not seem to work. > Expected behavior from both poms is to create an uber jar from the following > transitive dependencies: > [INFO] Including org.apache.activemq:activemq-client:jar:5.8.0 in the shaded > jar. > [INFO] Including org.slf4j:slf4j-api:jar:1.6.6 in the shaded jar. > [INFO] Including org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1 in > the shaded jar. > [INFO] Including org.fusesource.hawtbuf:hawtbuf:jar:1.9 in the shaded jar. > [INFO] Including > org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0.1 in the > shaded jar. > I've attached two test cases >mvn -f pom-direct.xml clean install > will create an empty jar. >mvn -f pom-indirect.xml clean install > will not include the slf4j-api which is a dependency of activemq-client, but > is marked provided in the pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MENFORCER-431) Skip specific rules
[
https://issues.apache.org/jira/browse/MENFORCER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Delany updated MENFORCER-431:
-
Description:
I can select rules like
{code:java}
mvn verify -Drules=alwaysPass,alwaysFail {code}
or skip all rules with
{code:java}
mvn verify -Denforcer.skip
{code}
But what if I want to skip a single rule?
{code:java}
mvn verify -DrulesSkip=BanVulnerableDependencies{code}
Or multiple
{code:java}
mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
Vulnerabilities could be discovered and published at any time. This would be a
useful to quickly allow my builds to continue, since I can't always upgrade
dependencies as they appear.
I don't want to turn off ALL my enforcer checks and I also dont want to list
all the checks in the build command.
Skipping a rule is an exceptional circumstance so I don't want to commit it to
the pom.
was:
I can select rules like
{code:java}
mvn verify -Drules=alwaysPass,alwaysFail {code}
or skip all rules with
{code:java}
mvn verify -Denforcer.skip
{code}
But what if I want to skip a single rule?
{code:java}
mvn verify -DrulesSkip=BanVulnerableDependencies{code}
Vulnerabilities could be discovered and published at any time. This would be a
useful to quickly allow my builds to continue, since I can't always upgrade
dependencies as they appear.
I don't want to turn off ALL my enforcer checks and I also dont want to list
all the checks in the build command.
Skipping a rule is an exceptional circumstance so I don't want to commit it to
the pom.
> Skip specific rules
> ---
>
> Key: MENFORCER-431
> URL: https://issues.apache.org/jira/browse/MENFORCER-431
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Delany
>Priority: Minor
>
> I can select rules like
> {code:java}
> mvn verify -Drules=alwaysPass,alwaysFail {code}
> or skip all rules with
> {code:java}
> mvn verify -Denforcer.skip
> {code}
> But what if I want to skip a single rule?
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies{code}
> Or multiple
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
> Vulnerabilities could be discovered and published at any time. This would be
> a useful to quickly allow my builds to continue, since I can't always upgrade
> dependencies as they appear.
> I don't want to turn off ALL my enforcer checks and I also dont want to list
> all the checks in the build command.
> Skipping a rule is an exceptional circumstance so I don't want to commit it
> to the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-431) Skip specific rules
Delany created MENFORCER-431:
Summary: Skip specific rules
Key: MENFORCER-431
URL: https://issues.apache.org/jira/browse/MENFORCER-431
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Plugin
Affects Versions: 3.1.0
Reporter: Delany
I can select rules like
{code:java}
mvn verify -Drules=alwaysPass,alwaysFail {code}
or skip all rules with
{code:java}
mvn verify -Denforcer.skip
{code}
But what if I want to skip a single rule?
{code:java}
mvn verify -DrulesSkip=BanVulnerableDependencies{code}
Vulnerabilities could be discovered and published at any time. This would be a
useful to quickly allow my builds to continue, since I can't always upgrade
dependencies as they appear.
I don't want to turn off ALL my enforcer checks and I also dont want to list
all the checks in the build command.
Skipping a rule is an exceptional circumstance so I don't want to commit it to
the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MDEP-738) Can't copy dependency from a 3rd party repository
[
https://issues.apache.org/jira/browse/MDEP-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599452#comment-17599452
]
Delany edited comment on MDEP-738 at 9/2/22 12:50 PM:
--
My requirement was to "download all direct dependencies of a pom at URL to a
directory". If that pom relies on its parent to configure repositories, and its
not a SNAPSHOT, its impossible to achieve this using this plugin, either with 3
cli commands for get/copy/copy-dependencies, or even via a pom.xml
The workaround was to publish the pom with its own repo pointing to the
third-party repo, do the get/copy with the pom.xml, and copy-dependencies with
the command.
was (Author: delany):
My requirement was to "download all direct dependencies of a pom at URL to a
directory". If that pom relies on its parent to configure repositories, and its
not a SNAPSHOT, its impossible to achieve this using this plugin, either with 3
cli commands for get/copy/copy-dependencies, or even via a pom.xml
The workaround was to publish the pom with its own repo pointing to the
third-party repo or a repo to override and block central.
I went with 3 commands each for simplicity. If I'd gone with the pom.xml
approach, then for each dependency I'd need an execution for the get goal and
an artifactItem for the copy goal. If I wanted to use the list-repositories
goal I'd have to specify the dependency yet again as a dependency.
> Can't copy dependency from a 3rd party repository
> -
>
> Key: MDEP-738
> URL: https://issues.apache.org/jira/browse/MDEP-738
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: copy
>Affects Versions: 3.1.2
> Environment: Linux (fc33)
>Reporter: Pawel Veselov
>Priority: Major
> Attachments: copy-X.txt, get-X.txt
>
>
> I can't seem to be able to copy a dependency that I previously downloaded
> from a 3rd party repository, when referring to it using metaversion.
> This doesn't work, unless I refer to the version directly in the :copy
> invocation:
> {noformat}
> $ # rm -rf ~/.m2/repository/org/openconext/ # clean up
> $ mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:get \
> -DremoteRepositories=excelfore.publichttps://dev-esync.excelfore.com/artifactory/excelfore.public
> \
> -Dartifact=org.openconext:mujina-idp:LATEST:jar
> $ mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:copy \
> -Dartifact=org.openconext:mujina-idp:LATEST:jar -DoutputDirectory=/tmp
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:copy (default-cli) on
> project standalone-pom: Unable to find/resolve artifact.: Failed to read
> artifact descriptor for org.openconext:mujina-idp:jar:LATEST: Failed to
> resolve version for org.openconext:mujina-idp:jar:LATEST: Could not find
> metadata org.openconext:mujina-idp/maven-metadata.xml in local
> (/home/vps/.m2/repository) -> [Help 1]
> {noformat}
> (this is from a real public repo)
> I figure this has something to do with the fact that plugin has no knowledge
> of the repository ID, and needs it to find the right metadata file. So maybe
> the plugin should have "repositoryId" property that can be supplied to it so
> it knows which metadata file to check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-738) Can't copy dependency from a 3rd party repository
[
https://issues.apache.org/jira/browse/MDEP-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599452#comment-17599452
]
Delany commented on MDEP-738:
-
My requirement was to "download all direct dependencies of a pom at URL to a
directory". If that pom relies on its parent to configure repositories, and its
not a SNAPSHOT, its impossible to achieve this using this plugin, either with 3
cli commands for get/copy/copy-dependencies, or even via a pom.xml
The workaround was to publish the pom with its own repo pointing to the
third-party repo or a repo to override and block central.
I went with 3 commands each for simplicity. If I'd gone with the pom.xml
approach, then for each dependency I'd need an execution for the get goal and
an artifactItem for the copy goal. If I wanted to use the list-repositories
goal I'd have to specify the dependency yet again as a dependency.
> Can't copy dependency from a 3rd party repository
> -
>
> Key: MDEP-738
> URL: https://issues.apache.org/jira/browse/MDEP-738
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: copy
>Affects Versions: 3.1.2
> Environment: Linux (fc33)
>Reporter: Pawel Veselov
>Priority: Major
> Attachments: copy-X.txt, get-X.txt
>
>
> I can't seem to be able to copy a dependency that I previously downloaded
> from a 3rd party repository, when referring to it using metaversion.
> This doesn't work, unless I refer to the version directly in the :copy
> invocation:
> {noformat}
> $ # rm -rf ~/.m2/repository/org/openconext/ # clean up
> $ mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:get \
> -DremoteRepositories=excelfore.publichttps://dev-esync.excelfore.com/artifactory/excelfore.public
> \
> -Dartifact=org.openconext:mujina-idp:LATEST:jar
> $ mvn org.apache.maven.plugins:maven-dependency-plugin:3.1.2:copy \
> -Dartifact=org.openconext:mujina-idp:LATEST:jar -DoutputDirectory=/tmp
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.1.2:copy (default-cli) on
> project standalone-pom: Unable to find/resolve artifact.: Failed to read
> artifact descriptor for org.openconext:mujina-idp:jar:LATEST: Failed to
> resolve version for org.openconext:mujina-idp:jar:LATEST: Could not find
> metadata org.openconext:mujina-idp/maven-metadata.xml in local
> (/home/vps/.m2/repository) -> [Help 1]
> {noformat}
> (this is from a real public repo)
> I figure this has something to do with the fact that plugin has no knowledge
> of the repository ID, and needs it to find the right metadata file. So maybe
> the plugin should have "repositoryId" property that can be supplied to it so
> it knows which metadata file to check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-819) Unable to delete with purge-local-repository
Delany created MDEP-819:
---
Summary: Unable to delete with purge-local-repository
Key: MDEP-819
URL: https://issues.apache.org/jira/browse/MDEP-819
Project: Maven Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 3.3.0
Environment: This is happening on Windows Server 2016 running Jenkins
as a service. Maven is 3.8.6 running on JDK11
Reporter: Delany
I cant use this goal. Resolve works fine.
{noformat}
15:11:36 java.io.IOException: File
C:\Windows\system32\config\systemprofile\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar
unable to be deleted.
15:11:36 at org.codehaus.plexus.util.FileUtils.forceDelete
(FileUtils.java:1403)
15:11:36 at org.codehaus.plexus.util.FileUtils.cleanDirectory
(FileUtils.java:1658)
15:11:36 at org.codehaus.plexus.util.FileUtils.deleteDirectory
(FileUtils.java:1604)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeArtifacts
(PurgeLocalRepositoryMojo.java:649)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeLocalRepository
(PurgeLocalRepositoryMojo.java:384)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.execute
(PurgeLocalRepositoryMojo.java:345)
15:11:36 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
15:11:36 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
15:11:36 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
15:11:36 at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
15:11:36 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
15:11:36 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
15:11:36 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
15:11:36 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
15:11:36 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
15:11:36 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
15:11:36 at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
15:11:36 at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
15:11:36 at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
15:11:36 at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:53)
15:11:36 at org.apache.maven.wrapper.WrapperExecutor.execute
(WrapperExecutor.java:152)
15:11:36 at org.apache.maven.wrapper.MavenWrapperMain.main
(MavenWrapperMain.java:76){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRRESOURCES-117) Inherit resourceBundle version
[
https://issues.apache.org/jira/browse/MRRESOURCES-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Delany updated MRRESOURCES-117:
---
Affects Version/s: 1.7.0
Description:
[~lachiew...@plusnet.pl] please reopen, this is still an issue.
The resourceBundle requires a version number
{code:java}
com.sloan:pestle
...
com.sloan:pestle:${pestle.version} {code}
The version number for this dependency is in the model (it was set in the
dependencyManagement section of the parent). So why can't I use it for the
resourceBundle? Im forced to use a property, or hardcode it.
For reference the artifactSet of the maven-shade-plugin has no problem deriving
the dependency version from the model.
> Inherit resourceBundle version
> --
>
> Key: MRRESOURCES-117
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-117
> Project: Maven Remote Resources Plugin
> Issue Type: Improvement
>Affects Versions: 1.7.0
>Reporter: Delany
>Priority: Minor
>
> [~lachiew...@plusnet.pl] please reopen, this is still an issue.
> The resourceBundle requires a version number
> {code:java}
> com.sloan:pestle
> ...
> com.sloan:pestle:${pestle.version} {code}
> The version number for this dependency is in the model (it was set in the
> dependencyManagement section of the parent). So why can't I use it for the
> resourceBundle? Im forced to use a property, or hardcode it.
> For reference the artifactSet of the maven-shade-plugin has no problem
> deriving the dependency version from the model.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552774#comment-17552774 ] Delany commented on SUREFIRE-1631: -- What's the upshot of this thread. Does the issue persist in Surefire 3.0.0-M7? After reading this and these pages * [https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#enableProcessChecker] * [https://maven.apache.org/surefire/maven-surefire-plugin/faq.html#kill-jvm] Im no wiser whether to use enableProcessChecker. > Forked VM terminated without properly saying goodbye with AciveMQ on > Windows10 and MinTTY(Cygwin) console > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MCOMPILER-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://issues.apache.org/jira/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528130#comment-17528130 ] Delany commented on MCOMPILER-187: -- This is still an issue > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://issues.apache.org/jira/browse/MCOMPILER-187 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > Attachments: no-class-in-java-file.zip > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2078) systemPropertyVariables not working
[
https://issues.apache.org/jira/browse/SUREFIRE-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528042#comment-17528042
]
Delany commented on SUREFIRE-2078:
--
In any case, if I set a user property with my build
`mvn test -Dotel.traces.exporter=logging`
I get
{noformat}
[WARNING] The system property otel.traces.exporter is configured twice! The
property appears in and any of ,
or user property.{noformat}
If instead of _user property_ and _argLine_ I employ _user property_ and
_systemPropertyVariables_ I don't get this message.
> systemPropertyVariables not working
> ---
>
> Key: SUREFIRE-2078
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2078
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Delany
>Priority: Major
>
> Hi. Im trying to use the opentelemetry java agent, but either surefire is not
> passing through the parameters, or the agent is not picking them up.
> It works if I pass via the {*}argLine{*}, but not via
> *systemPropertyVariables* or {*}systemProperties{*}.
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html]
> [https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/]
> Here is my up-to-date reproducer
> [https://github.com/delanym/java-maven-junit-helloworld/tree/opentelemetry]
> Run `mvn test` and you should get a line on the console like
> {noformat}
> [otel.javaagent 2022-04-26 10:33:44:015 +0200] [main] INFO
> io.opentelemetry.exporter.logging.LoggingSpanExporter -
> 'HelloTest.testSayHelloAFewTimes' : be46c05e6d80182590d5289426358fb7
> e4c19bfc7c2d INTERNAL [tracer: io.opentelemetry.opentelemetry-anno
> tations-1.0:1.13.0-alpha] AttributesMap{data={thread.id=1, thread.name=main},
> capacity=128, totalAddedValues=2}{noformat}
> Try to use the systemPropertyVariables instead and it will not show.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2078) systemPropertyVariables not working
[
https://issues.apache.org/jira/browse/SUREFIRE-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528041#comment-17528041
]
Delany commented on SUREFIRE-2078:
--
I see there is a note at the bottom of the surefire docs I linked to above
about "Special VM Properties".
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html]
The only conclusion I can draw from this note is that "sometimes things work,
and sometimes they don't"!
> systemPropertyVariables not working
> ---
>
> Key: SUREFIRE-2078
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2078
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Delany
>Priority: Major
>
> Hi. Im trying to use the opentelemetry java agent, but either surefire is not
> passing through the parameters, or the agent is not picking them up.
> It works if I pass via the {*}argLine{*}, but not via
> *systemPropertyVariables* or {*}systemProperties{*}.
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html]
> [https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/]
> Here is my up-to-date reproducer
> [https://github.com/delanym/java-maven-junit-helloworld/tree/opentelemetry]
> Run `mvn test` and you should get a line on the console like
> {noformat}
> [otel.javaagent 2022-04-26 10:33:44:015 +0200] [main] INFO
> io.opentelemetry.exporter.logging.LoggingSpanExporter -
> 'HelloTest.testSayHelloAFewTimes' : be46c05e6d80182590d5289426358fb7
> e4c19bfc7c2d INTERNAL [tracer: io.opentelemetry.opentelemetry-anno
> tations-1.0:1.13.0-alpha] AttributesMap{data={thread.id=1, thread.name=main},
> capacity=128, totalAddedValues=2}{noformat}
> Try to use the systemPropertyVariables instead and it will not show.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SUREFIRE-2078) systemPropertyVariables not working
Delany created SUREFIRE-2078:
Summary: systemPropertyVariables not working
Key: SUREFIRE-2078
URL: https://issues.apache.org/jira/browse/SUREFIRE-2078
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.0.0-M6
Reporter: Delany
Hi. Im trying to use the opentelemetry java agent, but either surefire is not
passing through the parameters, or the agent is not picking them up.
It works if I pass via the {*}argLine{*}, but not via *systemPropertyVariables*
or {*}systemProperties{*}.
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html]
[https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/]
Here is my up-to-date reproducer
[https://github.com/delanym/java-maven-junit-helloworld/tree/opentelemetry]
Run `mvn test` and you should get a line on the console like
{noformat}
[otel.javaagent 2022-04-26 10:33:44:015 +0200] [main] INFO
io.opentelemetry.exporter.logging.LoggingSpanExporter -
'HelloTest.testSayHelloAFewTimes' : be46c05e6d80182590d5289426358fb7
e4c19bfc7c2d INTERNAL [tracer: io.opentelemetry.opentelemetry-anno
tations-1.0:1.13.0-alpha] AttributesMap{data={thread.id=1, thread.name=main},
capacity=128, totalAddedValues=2}{noformat}
Try to use the systemPropertyVariables instead and it will not show.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-1892) systemPropertyVariables does not support interpolated values which are not string like settings.offline
[ https://issues.apache.org/jira/browse/SUREFIRE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527963#comment-17527963 ] Delany commented on SUREFIRE-1892: -- I see the PR was closed > systemPropertyVariables does not support interpolated values which are not > string like settings.offline > --- > > Key: SUREFIRE-1892 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1892 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M5 >Reporter: Romain Manni-Bucau >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSHADE-413) Maven share plugin enters endless loop
[
https://issues.apache.org/jira/browse/MSHADE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525446#comment-17525446
]
Delany commented on MSHADE-413:
---
[https://github.com/hunterhacker/jdom/issues/199]
> Maven share plugin enters endless loop
> ---
>
> Key: MSHADE-413
> URL: https://issues.apache.org/jira/browse/MSHADE-413
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Robert Stupp
>Priority: Critical
>
> Two issues at play here:
> * {{ShadeMojo.createDependencyReducedPom()}} pulls in {{origDeps =
> project.getDependencies()}} and later modifies these {{Dependency}} objects.
> * {{ShadeMojo.updateExcludesInDeps()}} enters it's own endless loop,
> endlessly adding the exact same exclusions.
> This leads to a
> [reproducible|https://github.com/projectnessie/nessie/issues/3678] endless
> loop (see below).
> If the Shade plugin's not using the {{Dependency}} objects "owned by Maven
> itself" (by setting {{promoteTransitiveDependencies}} to {{true}}), the build
> passes fine.
> I think, _modifying_ the {{Dependency}} objects "owned by Maven itself" is
> bad for two reasons (which IMO justify the increased priority of this
> ticket):
> # the reproducible endless loop
> # it breaks the correctness of the project build - at least plugins running
> after the {{shade}} goal that use those dependencies.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
