[jira] [Created] (MDEP-943) appendOutput for tree goal broken for multi-module project
Jim Sellers created MDEP-943:
Summary: appendOutput for tree goal broken for multi-module project
Key: MDEP-943
URL: https://issues.apache.org/jira/browse/MDEP-943
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 3.7.0
Reporter: Jim Sellers
[appendOutput|https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#appendOutput]
no longer seems to work for a multi-module project. It only has the dependency
tree for the last module.
{code}
# use example spring project
git clone https://github.com/spring-guides/gs-multi-module.git
cd gs-multi-module/complete
# do a dependency tree
mvn org.apache.maven.plugins:maven-dependency-plugin:3.6.1:tree
-DoutputFile=/tmp/tree-3.6.1.txt -DappendOutput=true
mvn org.apache.maven.plugins:maven-dependency-plugin:3.7.0:tree
-DoutputFile=/tmp/tree-3.7.0.txt -DappendOutput=true
diff /tmp/tree-3.6.1.txt /tmp/tree-3.7.0.txt
wc -l /tmp/tree-3.*txt
123 /tmp/tree-3.6.1.txt
1 /tmp/tree-3.7.0.txt
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8114) install plugin failed with NPE for profiles activated by files existing
[
https://issues.apache.org/jira/browse/MNG-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849709#comment-17849709
]
Jim Sellers commented on MNG-8114:
--
This has been fixed in 4.0.0-beta-4-SNAPSHOT at least.
Please close this ticket.
> install plugin failed with NPE for profiles activated by files existing
> ---
>
> Key: MNG-8114
> URL: https://issues.apache.org/jira/browse/MNG-8114
> Project: Maven
> Issue Type: Bug
> Environment: Apache Maven 4.0.0-alpha-14-SNAPSHOT
> (9fc4f499172637c403f27808d5c0ccd0c770f93c)
> Maven home:
> C:\Users\sellersj\Downloads\apache-maven-4.0.0-alpha-14-20240425.054714-33-bin
> Java version: 21.0.3, vendor: Eclipse Adoptium, runtime:
> C:\devtools\java\jdk21
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "winnt"
>Reporter: Jim Sellers
>Priority: Major
>
> This is a change between apache-maven-4.0.0-alpha-13 and
> 4.0.0-alpha-14-SNAPSHOT which I understand is not released yet.
> This happens both on windows and linux. If an app has a profile that's
> activated by a file existing or not, it will generate a NPE
> {code:XML|title=pom.xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.example
> Zminimal
> 0.0.1-SNAPSHOT
> jar
>
> 8
> 8
> UTF-8
> UTF-8
>
>
>
> is-webapp
>
>
> ${basedir}/src/main/webapp/
>
>
>
>
>
> {code}
> {code:title=log snipit}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project Zminimal: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Cannot
> invoke
> "org.apache.maven.internal.impl.model.ProfileActivationFilePathInterpolator.interpolate(String,
> org.apache.maven.api.services.model.ProfileActivationContext)" because
> "this.profileActivationFilePathInterpolator" is null -> [Help 1]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8114) install plugin failed with NPE for profiles activated by files existing
Jim Sellers created MNG-8114:
Summary: install plugin failed with NPE for profiles activated by
files existing
Key: MNG-8114
URL: https://issues.apache.org/jira/browse/MNG-8114
Project: Maven
Issue Type: Bug
Environment: Apache Maven 4.0.0-alpha-14-SNAPSHOT
(9fc4f499172637c403f27808d5c0ccd0c770f93c)
Maven home:
C:\Users\sellersj\Downloads\apache-maven-4.0.0-alpha-14-20240425.054714-33-bin
Java version: 21.0.3, vendor: Eclipse Adoptium, runtime: C:\devtools\java\jdk21
Default locale: en_CA, platform encoding: UTF-8
OS name: "windows 10", version: "10.0", arch: "amd64", family: "winnt"
Reporter: Jim Sellers
This is a change between apache-maven-4.0.0-alpha-13 and
4.0.0-alpha-14-SNAPSHOT which I understand is not released yet.
This happens both on windows and linux. If an app has a profile that's
activated by a file existing or not, it will generate a NPE
{code:XML|title=pom.xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.example
Zminimal
0.0.1-SNAPSHOT
jar
8
8
UTF-8
UTF-8
is-webapp
${basedir}/src/main/webapp/
{code}
{code:title=log snipit}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
on project Zminimal: Execution default-install of goal
org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Cannot
invoke
"org.apache.maven.internal.impl.model.ProfileActivationFilePathInterpolator.interpolate(String,
org.apache.maven.api.services.model.ProfileActivationContext)" because
"this.profileActivationFilePathInterpolator" is null -> [Help 1]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767262#comment-17767262
]
Jim Sellers commented on MNG-7705:
--
3.9.4 works for me and I am now unable to reproduce the issue.
Works great, thank you for all your work.
Please close this ticket.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apa
[jira] [Commented] (MNG-7733) maven4 user settings mirrorOf-external:* does not override global settings external:http:*
[
https://issues.apache.org/jira/browse/MNG-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17740286#comment-17740286
]
Jim Sellers commented on MNG-7733:
--
Thanks [~gnodet]!
Also worked for me with 4.0.0-alpha-7 and 4.0.0-alpha-8-SNAPSHOT.
> maven4 user settings mirrorOf-external:* does not override global settings
> external:http:*
> ---
>
> Key: MNG-7733
> URL: https://issues.apache.org/jira/browse/MNG-7733
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-4
>Reporter: James Nord
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: regresion
>
> I have a settings file in my home directory (~/.m2/settings.xml) that works
> fine with maven 3.x (including 3.9.0)
> containing
> {code}
>
>
> myco-internal
> external:*
> https://nexus-cache.mycorp.com/content/groups/staged
>
>
> {code}
> with maven 4.0.0-alpha4 when building a project it will fail in dependency
> resolution due to the `maven-default-http-blocker` mirror.
> {noformat}
> unable to create flattened dependencies: caught exception when flattening
> dependencies: Failed to read artifact descriptor for
> javax.servlet:javax.servlet-api::3.1.0: Could not transfer artifact
> net.java:jvnet-parent:pom:3 from/to maven-default-http-blocker
> (http://0.0.0.0/): Blocked mirror for repositories: [glassfish-repository
> (http://download.java.net/maven/glassfish, default, releases+snapshots)] -
> {noformat}
> However I expect that my user settings should override global settings.
> as {{external:\*}} used in my local settings should also match anything that
> is matched by {{external:http:\*}} in the global settings I would not expect
> that the global settings mirror would be used.
> However this is infact the case.
> if I use --global-settings to specify my local settings file then the builds
> work
> Additionally changing my mirror defintion to be
> {{external:\*,external:http:\*}} still does not work
> initial output from {{mvn -x install}}
> {noformat}
> [DEBUG] Reading global settings from
> 'c:\java\maven-4.0.0-alpha-4\conf\settings.xml'
> [DEBUG] Reading user settings from 'C:\Users\me\.m2\settings.xml'
> [DEBUG] Created adapter factory; available factories [file-lock,
> rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
> file-gav, file-hgav, gav, static]
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> C:\Users\me\.m2\repository
> [DEBUG] Creating adapter using nameMapper 'gav' and factory 'rwlock-local'
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for central
> (https://repo.maven.apache.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for apache.snapshots
> (https://repository.apache.org/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> repository.jboss.org (http://repository.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> snapshots.jboss.org (http://snapshots.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> oss.sonatype.org/jboss-snapshots
> (http://oss.sonatype.org/content/repositories/jboss-snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for jgit-repository
> (https://repo.eclipse.org/content/repositories/jgit-releases/).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for spy
> (http://files.couchbase.com/maven2/).
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739975#comment-17739975
]
Jim Sellers commented on MNG-7705:
--
Using 3.9.3 this seems better, but I can still get it to fail on a clean repo
with 3 concurrent builds using the same gav lockfile setup. But now it's on a
resolver-status.properties file.
{code:title=stacktrace on failing resolver-status.properties}
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-apache-connector/maven-metadata.xml
(3.5 kB at 130 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/bundles/jaxrs-ri/maven-metadata.xml
(3.3 kB at 127 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-apache5-connector/maven-metadata.xml
(861 B at 32 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jdk-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jdk-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jetty-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jetty-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
(1.0 kB at 48 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
(4.1 kB at 145 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jnh-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jnh-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[WARNING] Failed to write tracking file
'/home/bamboo/.m2/repository/org/glassfish/jersey/connectors/jersey-grizzly-connector/resolver-status.properties'
build 28-Jun-2023 13:52:41java.io.IOException: Resource deadlock avoided
build 28-Jun-2023 13:52:41at sun.nio.ch.FileDispatcherImpl.lock0
(Native Method)
build 28-Jun-2023 13:52:41at sun.nio.ch.FileDispatcherImpl.lock
(FileDispatcherImpl.java:94)
build 28-Jun-2023 13:52:41at sun.nio.ch.FileChannelImpl.lock
(FileChannelImpl.java:1072)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultTrackingFileManager.fileLock
(DefaultTrackingFileManager.java:140)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
(DefaultTrackingFileManager.java:85)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
(DefaultUpdateCheckManager.java:527)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchMetadata
(DefaultUpdateCheckManager.java:501)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.re
[jira] [Commented] (MNG-7733) maven4 user settings mirrorOf-external:* does not override global settings external:http:*
[
https://issues.apache.org/jira/browse/MNG-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739972#comment-17739972
]
Jim Sellers commented on MNG-7733:
--
Hi [~gnodet]
I checked the nightly 4.0.0-alpha-6-SNAPSHOT and it seems to resolve it for me
without needing to change from the mirrorOf * setup that I had.
This seems better for me, thanks!
> maven4 user settings mirrorOf-external:* does not override global settings
> external:http:*
> ---
>
> Key: MNG-7733
> URL: https://issues.apache.org/jira/browse/MNG-7733
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-4
>Reporter: James Nord
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: regresion
>
> I have a settings file in my home directory (~/.m2/settings.xml) that works
> fine with maven 3.x (including 3.9.0)
> containing
> {code}
>
>
> myco-internal
> external:*
> https://nexus-cache.mycorp.com/content/groups/staged
>
>
> {code}
> with maven 4.0.0-alpha4 when building a project it will fail in dependency
> resolution due to the `maven-default-http-blocker` mirror.
> {noformat}
> unable to create flattened dependencies: caught exception when flattening
> dependencies: Failed to read artifact descriptor for
> javax.servlet:javax.servlet-api::3.1.0: Could not transfer artifact
> net.java:jvnet-parent:pom:3 from/to maven-default-http-blocker
> (http://0.0.0.0/): Blocked mirror for repositories: [glassfish-repository
> (http://download.java.net/maven/glassfish, default, releases+snapshots)] -
> {noformat}
> However I expect that my user settings should override global settings.
> as {{external:\*}} used in my local settings should also match anything that
> is matched by {{external:http:\*}} in the global settings I would not expect
> that the global settings mirror would be used.
> However this is infact the case.
> if I use --global-settings to specify my local settings file then the builds
> work
> Additionally changing my mirror defintion to be
> {{external:\*,external:http:\*}} still does not work
> initial output from {{mvn -x install}}
> {noformat}
> [DEBUG] Reading global settings from
> 'c:\java\maven-4.0.0-alpha-4\conf\settings.xml'
> [DEBUG] Reading user settings from 'C:\Users\me\.m2\settings.xml'
> [DEBUG] Created adapter factory; available factories [file-lock,
> rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
> file-gav, file-hgav, gav, static]
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> C:\Users\me\.m2\repository
> [DEBUG] Creating adapter using nameMapper 'gav' and factory 'rwlock-local'
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for central
> (https://repo.maven.apache.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for apache.snapshots
> (https://repository.apache.org/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> repository.jboss.org (http://repository.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> snapshots.jboss.org (http://snapshots.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> oss.sonatype.org/jboss-snapshots
> (http://oss.sonatype.org/content/repositories/jboss-snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for jgit-repository
> (https://repo.eclipse.org/content/repositories/jgit-releases/).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for spy
> (http://files.couchbase.com/maven2/).
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-862) warns about depending on plexus-container-default
Jim Sellers created MDEP-862:
Summary: warns about depending on plexus-container-default
Key: MDEP-862
URL: https://issues.apache.org/jira/browse/MDEP-862
Project: Maven Dependency Plugin
Issue Type: Improvement
Affects Versions: 3.5.0
Environment: Apache Maven 3.9.2
(c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-3.9.2
Java version: 17.0.6, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch: "amd64",
family: "unix"
Reporter: Jim Sellers
When using 3.9.2 it warns about using plexus-container-default
{code:title=sample command, path to maven specific}
~/Downloads/apache-maven-3.9.2/bin/mvn -V -B --lax-checksums
org.apache.maven.plugins:maven-dependency-plugin:RELEASE:unpack
-Dtransitive=false -DoutputDirectory=. -Dmdep.stripVersion=true
-Dartifact="org.apache.maven:apache-maven:3.9.2:zip:bin"
-Dmaven.plugin.validation=VERBOSE
{code}
{code:title=sample warning}
[WARNING]
[WARNING] Plugin validation issues were detected in 1 plugin(s)
[WARNING]
[WARNING] * org.apache.maven.plugins:maven-dependency-plugin:3.5.0
[WARNING] Declared at location(s):
[WARNING]* unknown
[WARNING] Used in module(s):
[WARNING]* org.apache.maven:standalone-pom:1
[WARNING] Plugin issue(s):
[WARNING]* Plugin depends on plexus-container-default, which is EOL
[WARNING]
[WARNING]
[WARNING] Fix reported issues by adjusting plugin configuration or by upgrading
above listed plugins. If no upgrade available, please notify plugin maintainers
about reported issues.
[WARNING] For more or less details, use 'maven.plugin.validation' property with
one of the values (case insensitive): [BRIEF, DEFAULT, VERBOSE]
[WARNING]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709457#comment-17709457
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] No, I've not had a lot of time to get back to this. I've still got
a dev env using the 3.9.x stream for evaluation, but I'm holding everything
else back to 3.8.x for now.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractD
[jira] [Commented] (MNG-7733) maven4 user settings mirrorOf-external:* does not override global settings external:http:*
[
https://issues.apache.org/jira/browse/MNG-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707400#comment-17707400
]
Jim Sellers commented on MNG-7733:
--
I ran across this when using
{code:XML}
org.ehcache
ehcache
3.10.8
{code}
Which has a dependency on
{code:XML}
org.glassfish.jaxb
jaxb-runtime
[2.2,3)
runtime
{code}
which in central resolves to version 2.3.0-b170127.1453 which seems to be a
nightly build and eventually a snapshot http repo.
> maven4 user settings mirrorOf-external:* does not override global settings
> external:http:*
> ---
>
> Key: MNG-7733
> URL: https://issues.apache.org/jira/browse/MNG-7733
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-4
>Reporter: James Nord
>Priority: Major
>
> I have a settings file in my home directory (~/.m2/settings.xml) that works
> fine with maven 3.x (including 3.9.0)
> containing
> {code}
>
>
> myco-internal
> external:*
> https://nexus-cache.mycorp.com/content/groups/staged
>
>
> {code}
> with maven 4.0.0-alpha4 when building a project it will fail in dependency
> resolution due to the `maven-default-http-blocker` mirror.
> {noformat}
> unable to create flattened dependencies: caught exception when flattening
> dependencies: Failed to read artifact descriptor for
> javax.servlet:javax.servlet-api::3.1.0: Could not transfer artifact
> net.java:jvnet-parent:pom:3 from/to maven-default-http-blocker
> (http://0.0.0.0/): Blocked mirror for repositories: [glassfish-repository
> (http://download.java.net/maven/glassfish, default, releases+snapshots)] -
> {noformat}
> However I expect that my user settings should override global settings.
> as {{external:\*}} used in my local settings should also match anything that
> is matched by {{external:http:\*}} in the global settings I would not expect
> that the global settings mirror would be used.
> However this is infact the case.
> if I use --global-settings to specify my local settings file then the builds
> work
> Additionally changing my mirror defintion to be
> {{external:\*,external:http:\*}} still does not work
> initial output from {{mvn -x install}}
> {noformat}
> [DEBUG] Reading global settings from
> 'c:\java\maven-4.0.0-alpha-4\conf\settings.xml'
> [DEBUG] Reading user settings from 'C:\Users\me\.m2\settings.xml'
> [DEBUG] Created adapter factory; available factories [file-lock,
> rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
> file-gav, file-hgav, gav, static]
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> C:\Users\me\.m2\repository
> [DEBUG] Creating adapter using nameMapper 'gav' and factory 'rwlock-local'
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for central
> (https://repo.maven.apache.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for apache.snapshots
> (https://repository.apache.org/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> repository.jboss.org (http://repository.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> snapshots.jboss.org (http://snapshots.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> oss.sonatype.org/jboss-snapshots
> (http://oss.sonatype.org/content/repositories/jboss-snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for jgit-repository
> (https://repo.eclipse.org/content/repositories/jgit-releases/).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for spy
> (http://files.couchbase.com/maven2/).
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707310#comment-17707310
]
Jim Sellers commented on MNG-7752:
--
Aside, I've found many places in projects where they used a filtered properties
file to capture the build version with {{pom.version}}.
I don't know if it's possible to log warnings for that, or if there's some kind
of open rewrite formula that can be used to check for things dropped from maven
when moving from 3 to 4.
https://docs.openrewrite.org/
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information available
> [WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
> missing, no dependency information available
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 10.993 s
> [INFO] Finished at: 2023-03-29T15:07:34-04:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
> project standalone-pom: Couldn't download artifact:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved:
> org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
> org.apache.tiles:tiles-template:jar:${pom.version} (absent):
> org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
> https://example.com/maven-proxy/content/groups/all-released during a previous
> attempt. This failure was cached in the local repository and resolution is
> not reattempted until the update interval of asb-repository has elapsed or
> updates are forced -> [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 verbose output
> [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/MojoExecutionException
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707069#comment-17707069
]
Jim Sellers edited comment on MNG-7752 at 3/30/23 11:34 PM:
Understandable about staying on 3.x for old dependencies. Have quite a few
projects stuck on JEE 6 and the vendor has support until 2030. Been trying to
move those off for years. :-(
No warning for 3.9.1 or anything before that that I saw. [~michael-o]
{code}
mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
-Dartifact=org.apache.tiles:tiles-jsp:2.2.2
Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /usr/local/Cellar/maven/3.9.1/libexec
Java version: 19.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/19.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "11.7.4", arch: "x86_64", family: "mac"
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom >---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom ]-
[INFO]
[INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
dependencies
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.119 s
[INFO] Finished at: 2023-03-30T19:30:45-04:00
[INFO]
{code}
was (Author: sellersj):
Understandable about staying on 3.x for old dependencies. Have quite a few
projects stuck on JEE 6 and the vendor has support until 2030. Been trying to
move those off for years. :-(
No warning for 3.9.1 or anything before that that I saw.
{code}
mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
-Dartifact=org.apache.tiles:tiles-jsp:2.2.2
Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /usr/local/Cellar/maven/3.9.1/libexec
Java version: 19.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/19.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "11.7.4", arch: "x86_64", family: "mac"
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom >---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom ]-
[INFO]
[INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
dependencies
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.119 s
[INFO] Finished at: 2023-03-30T19:30:45-04:00
[INFO]
{code}
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information a
[jira] [Commented] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707069#comment-17707069
]
Jim Sellers commented on MNG-7752:
--
Understandable about staying on 3.x for old dependencies. Have quite a few
projects stuck on JEE 6 and the vendor has support until 2030. Been trying to
move those off for years. :-(
No warning for 3.9.1 or anything before that that I saw.
{code}
mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
-Dartifact=org.apache.tiles:tiles-jsp:2.2.2
Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /usr/local/Cellar/maven/3.9.1/libexec
Java version: 19.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/19.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "11.7.4", arch: "x86_64", family: "mac"
[INFO] Scanning for projects...
[INFO]
[INFO] --< org.apache.maven:standalone-pom >---
[INFO] Building Maven Stub Project (No POM) 1
[INFO] [ pom ]-
[INFO]
[INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
dependencies
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.119 s
[INFO] Finished at: 2023-03-30T19:30:45-04:00
[INFO]
{code}
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information available
> [WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
> missing, no dependency information available
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 10.993 s
> [INFO] Finished at: 2023-03-29T15:07:34-04:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
> project standalone-pom: Couldn't download artifact:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved:
> org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
> org.apache.tiles:tiles-template:jar:${pom.version} (absent):
> org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
> https://example.com/maven-proxy/content/groups/all-released during a previous
> attempt. This failure was cached in the local repository and resolution is
> not reattempted until the update interval of asb-repository has elapsed or
> updates are forced -> [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 v
[jira] [Commented] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707042#comment-17707042
]
Jim Sellers commented on MNG-7752:
--
Okay, I can accept that. Not sure how I'm going to work around it, but I
understand.
I don't know why I didn't find anything in my initial searches. Maybe I was
being too specific. Sorry about the noise.
Please close this ticket because I don't seem to have the rights.
Thanks
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information available
> [WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
> missing, no dependency information available
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 10.993 s
> [INFO] Finished at: 2023-03-29T15:07:34-04:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
> project standalone-pom: Couldn't download artifact:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved:
> org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
> org.apache.tiles:tiles-template:jar:${pom.version} (absent):
> org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
> https://example.com/maven-proxy/content/groups/all-released during a previous
> attempt. This failure was cached in the local repository and resolution is
> not reattempted until the update interval of asb-repository has elapsed or
> updates are forced -> [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 verbose output
> [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/MojoExecutionException
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707041#comment-17707041
]
Jim Sellers commented on MNG-7752:
--
Linking possible related tickets
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information available
> [WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
> missing, no dependency information available
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 10.993 s
> [INFO] Finished at: 2023-03-29T15:07:34-04:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
> project standalone-pom: Couldn't download artifact:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved:
> org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
> org.apache.tiles:tiles-template:jar:${pom.version} (absent):
> org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
> https://example.com/maven-proxy/content/groups/all-released during a previous
> attempt. This failure was cached in the local repository and resolution is
> not reattempted until the update interval of asb-repository has elapsed or
> updates are forced -> [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 verbose output
> [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/MojoExecutionException
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
[
https://issues.apache.org/jira/browse/MNG-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707033#comment-17707033
]
Jim Sellers commented on MNG-7752:
--
These are some other artifact that can be failed due to this
{code}
org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating
org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating
org.apache.abdera:abdera-parser:jar:0.4.0-incubating
org.apache.httpcomponents:httpmime:jar:4.0.3
org.apache.neethi:neethi:jar:2.0.4
org.apache.tiles:tiles-core:jar:2.2.2
org.apache.tiles:tiles-jsp:jar:2.2.2
org.apache.tiles:tiles-servlet:jar:2.2.2
org.apache.tiles:tiles-template:jar:2.2.2
org.apache.ws.commons.axiom:axiom-impl:jar:1.2.5
org.springframework.security:spring-security-core:jar:2.0.8.RELEASE
org.springframework.webflow:spring-js:jar:2.3.4.RELEASE
org.springframework:spring-webmvc:jar:3.2.14.RELEASE
org.springframework:spring-webmvc:jar:3.2.17.RELEASE
org.springframework:spring-webmvc:jar:3.2.18.RELEASE
org.springframework:spring-webmvc:jar:3.2.9.RELEASE
org.springframework:spring-webmvc:jar:4.1.6.RELEASE
org.springframework:spring-webmvc:jar:4.2.9.RELEASE
org.springframework:spring-webmvc:jar:4.3.14.RELEASE
org.springframework:spring-webmvc:jar:4.3.2.RELEASE
org.springframework:spring-webmvc:jar:4.3.25.RELEASE
org.springframework:spring-webmvc:jar:4.3.30.RELEASE
{code}
> can't download transitive dependencies if there is an expression in the pom
> ---
>
> Key: MNG-7752
> URL: https://issues.apache.org/jira/browse/MNG-7752
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
> Environment: Apache Maven 4.0.0-alpha-5
> (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
> Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en, platform encoding: UTF-8
> OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch:
> "amd64", family: "unix"
>Reporter: Jim Sellers
>Priority: Major
>
> The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
> as far as I can tell.
> {code:title=command to run}
> mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
> -Dartifact=org.apache.tiles:tiles-jsp:2.2.2
> {code}
> {code:title=log}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] ---<
> org.apache.maven:standalone-pom >
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO] -[ pom
> ]--
> [INFO]
> [INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
> [INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
> dependencies
> [WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
> missing, no dependency information available
> [WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
> missing, no dependency information available
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 10.993 s
> [INFO] Finished at: 2023-03-29T15:07:34-04:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
> project standalone-pom: Couldn't download artifact:
> org.eclipse.aether.resolution.DependencyResolutionException: The following
> artifacts could not be resolved:
> org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
> org.apache.tiles:tiles-template:jar:${pom.version} (absent):
> org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
> https://example.com/maven-proxy/content/groups/all-released during a previous
> attempt. This failure was cached in the local repository and resolution is
> not reattempted until the update interval of asb-repository has elapsed or
> updates are forced -> [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 verbose output
> [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/MojoExecutionException
> {code}
--
This message was sent by
[jira] [Created] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
Jim Sellers created MNG-7752:
Summary: can't download transitive dependencies if there is an
expression in the pom
Key: MNG-7752
URL: https://issues.apache.org/jira/browse/MNG-7752
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-5
Environment: Apache Maven 4.0.0-alpha-5
(26d10a4bf9a2df75feef60da01d8706f2bf77a47)
Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
Java version: 17.0.6, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch: "amd64",
family: "unix"
Reporter: Jim Sellers
The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
as far as I can tell.
{code:title=command to run}
mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
-Dartifact=org.apache.tiles:tiles-jsp:2.2.2
{code}
{code:title=log}
[INFO] Scanning for projects...
[INFO]
[INFO] ---<
org.apache.maven:standalone-pom >
[INFO] Building Maven Stub Project (No POM) 1
[INFO] -[ pom
]--
[INFO]
[INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
dependencies
[WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
missing, no dependency information available
[WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
missing, no dependency information available
[INFO]
--
[INFO] BUILD FAILURE
[INFO]
--
[INFO] Total time: 10.993 s
[INFO] Finished at: 2023-03-29T15:07:34-04:00
[INFO]
--
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
project standalone-pom: Couldn't download artifact:
org.eclipse.aether.resolution.DependencyResolutionException: The following
artifacts could not be resolved:
org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
org.apache.tiles:tiles-template:jar:${pom.version} (absent):
org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
https://example.com/maven-proxy/content/groups/all-released during a previous
attempt. This failure was cached in the local repository and resolution is not
reattempted until the update interval of asb-repository has elapsed or updates
are forced -> [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 verbose output
[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/MojoExecutionException
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698914#comment-17698914
]
Jim Sellers commented on MNG-7705:
--
Reproduced with {{file-lock}} and {{file-hgav}} on my mac.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Major
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698629#comment-17698629
]
Jim Sellers commented on MNG-7705:
--
No, thank you [~michael-o] ! I feel I've dumped a pile of work on your lap. A
not-easy problem at that.
Unfortunately I won't be able to get back to this until the week of the 20th.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDep
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698607#comment-17698607
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] I had originally reproduced this on apfs on my mac, so I don't
think that it's isolated to xfs.
I don't think that I'll be able to change the filesystem for the build machine.
I think that'll be a non-starter in my env.
The links that you provided say that xfs has poor performance with small files.
Doesn't that just indicate that there is something wrong with the file locking
that only shows up with poor performance, not that the file system is broken?
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
>
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: xad-1.xz
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz, xad-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.mav
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: xac-1.xz
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz, xac-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: xab-1.xz
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz, xab-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependenc
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: xaa-1.xz
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar, xaa-1.xz
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolver
[jira] [Comment Edited] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697631#comment-17697631
]
Jim Sellers edited comment on MNG-7705 at 3/7/23 9:31 PM:
--
Attaching
xaa.xz
xab.xz
xac.xz
xad.xz
I used
{code}
split -b 250MB *.log
{code}
and then
{code}
xz -v -9e x*
{code}
to compress them.
Thanks again for all your work and time.
was (Author: sellersj):
Attaching
xaa.xz
xab.xz
xac.xz
xad.xz
I used {{split -b 250MB *.log}} and then {{xz -v -9e x*}} to compress them.
Thanks again for all your work and time.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (Ab
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697631#comment-17697631
]
Jim Sellers commented on MNG-7705:
--
Attaching
xaa.xz
xab.xz
xac.xz
xad.xz
I used {{split -b 250MB *.log}} and then {{xz -v -9e x*}} to compress them.
Thanks again for all your work and time.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugi
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697557#comment-17697557
]
Jim Sellers commented on MNG-7705:
--
* 1 of the 3 branches failed with the new build.
* Log {{failed_plan-377290782-JOB1-15.zip}} should be attached
* Feel free to double check the version in case I messed something up.
* At the bottom of the log it has the {{aether}} settings from the
{{settings.xml}} file.
* I think the success logs are about 1G uncompressed and 150 mb compressed, so
if you want a specific part from them I can snip that out and attach it.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMo
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: failed_plan-377290782-JOB1-15.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz, failed_plan-377290782-JOB1-15.zip,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.depe
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: (was: MNG-7705_2023-03-07_just_failed_logs.zip)
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: MNG-7705_2023-03-07_just_failed_logs.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip,
> MNG-7705_2023-03-07_just_failed_logs.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar-1.gz,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.m
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697502#comment-17697502
]
Jim Sellers commented on MNG-7705:
--
I'll do a search around to try to figure out why the file lock might not be
working. It's very strange. I did reproduce the original issue on my old mac
through, so I don't think that the issue is exclusively with this RHEL vm.
Here is what I have.
{code:title=the vm}
cat /etc/redhat-release && java -version
Red Hat Enterprise Linux release 8.7 (Ootpa)
openjdk version "1.8.0_362"
OpenJDK Runtime Environment (build 1.8.0_362-b09)
OpenJDK 64-Bit Server VM (build 25.362-b09, mixed mode)
{code}
{code:title=command run}
strace -f -tt -o out-1 java -cp . demo.TestNioLock perform /tmp/my-lock 15000
{code}
{code:title=logs around the similar part}
1033373 10:34:51.704179 openat(AT_FDCWD, "/tmp/my-lock", O_RDWR|O_CREAT, 0666)
= 8
1033373 10:34:51.704285 fstat(8, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
1033373 10:34:51.704356 fcntl(8, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET,
l_start=0, l_len=1}) = 0
1033373 10:34:51.704450 write(1, "1033372@hpvsdev268 > WON", 24) = 24
1033373 10:34:51.704513 write(1, "\n", 1) = 1
# ... a lot of these lines
1033388 10:35:03.215731 futex(0x7f0834137d78, FUTEX_WAIT_PRIVATE, 0, {tv_sec=0,
tv_nsec=4495}) = -1 ETIMEDOUT (Connection timed out)
1033388 10:35:03.265923 futex(0x7f0834137d28, FUTEX_WAKE_PRIVATE, 1) = 0
1033388 10:35:03.265981 futex(0x7f0834137d78, FUTEX_WAIT_PRIVATE, 0, {tv_sec=0,
tv_nsec=4498}) = -1 ETIMEDOUT (Connection timed out)
1033388 10:35:03.318878 futex(0x7f0834137d28, FUTEX_WAKE_PRIVATE, 1) = 0
1033388 10:35:03.318937 futex(0x7f0834137d78, FUTEX_WAIT_PRIVATE, 0, {tv_sec=0,
tv_nsec=4395}) = -1 ETIMEDOUT (Connection timed out)
1033388 10:35:03.369074 futex(0x7f0834137d28, FUTEX_WAKE_PRIVATE, 1) = 0
# ...
1033380 10:35:06.654916 <... futex resumed>) = -1 ETIMEDOUT (Connection timed
out)
1033380 10:35:06.654976 futex(0x7f08340db128, FUTEX_WAKE_PRIVATE, 1) = 0
1033380 10:35:06.655046 futex(0x7f08340db178, FUTEX_WAIT_PRIVATE, 0, {tv_sec=0,
tv_nsec=99671}
1033388 10:35:06.698991 <... futex resumed>) = -1 ETIMEDOUT (Connection timed
out)
1033388 10:35:06.699049 futex(0x7f0834137d28, FUTEX_WAKE_PRIVATE, 1) = 0
1033388 10:35:06.699098 futex(0x7f0834137d78, FUTEX_WAIT_PRIVATE, 0, {tv_sec=0,
tv_nsec=25999660}
1033373 10:35:06.704960 <... futex resumed>) = -1 ETIMEDOUT (Connection timed
out)
1033373 10:35:06.705350 futex(0x7f0834003d28, FUTEX_WAKE_PRIVATE, 1) = 0
1033373 10:35:06.705523 fcntl(8, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET,
l_start=0, l_len=1}) = 0
1033373 10:35:06.705835 close(8)= 0
1033373 10:35:06.705922 fcntl(6, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET,
l_start=0, l_len=1}) = 0
1033373 10:35:06.706023 close(6)= 0
{code}
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixE
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697482#comment-17697482
]
Jim Sellers commented on MNG-7705:
--
Thank you for all your help.
Should I look into getting truss installed instead of just strace? I'd have to
put in a request since I don't have admin on that vm.
FYI:
I'm not using /tmp for this work since the way this RHEL 8 vm is setup, there
is different rules for that mount like for non-executable for files there. Any
temp dirs that I need for the java process are on another mount.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697459#comment-17697459
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] attached MNG-7705-2023-03-07.zip that has the console output from
the TestNioLock test.
I tried launching them both as quickly as possible so they ran at the same time.
The strace command used is at the top of the file.
I didn't see any "Resource temporarily unavailable" in the logs, or any mention
of {{O_EXLOCK}}.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDep
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: MNG-7705-2023-03-07.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705-2023-03-07.zip, MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696277#comment-17696277
]
Jim Sellers commented on MNG-7705:
--
I've not yet fully setup redisson yet. It's new to me and I have to figure out
a config file to get it running.
I've got the builds just using the latest maven snapshots. I re-ran the test
(delete m2 repo to force lots of writes, kick off 3 parallel builds). I noticed
that all 3 builds unlink the lock file before it's logged that it's acquiring a
lock. Then they grab a lock at different times. Is this the expected behavour?
{code:title=command to filter the build log files}
grep "2.2.10-b140802.1033" *.log | grep jaxb-core | grep -e lock -e write
{code}
{code:title=failed around 11:48:57}
error 03-Mar-2023 11:48:57[pid 4126891] 11:48:57.123969 openat(AT_FDCWD,
"/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock",
O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65
error 03-Mar-2023 11:48:57[pid 4126891] 11:48:57.124055
unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock")
= 0
build 03-Mar-2023 11:48:5719222 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock]
build 03-Mar-2023 11:48:5719223 [main] [TRACE] Acquiring write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:48:5719350 [main] [WARNING] Failed to write tracking
file
'/home/bamboo/.m2/repository/org/glassfish/jaxb/jaxb-core/2.2.10-b140802.1033/jaxb-core-2.2.10-b140802.1033.pom.lastUpdated'
build 03-Mar-2023 11:48:5719375 [main] [TRACE] Releasing write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
{code}
{code:title=failed around 11:50:12}
error 03-Mar-2023 11:48:57[pid 4126950] 11:48:57.099587 openat(AT_FDCWD,
"/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock",
O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65
error 03-Mar-2023 11:48:57[pid 4126950] 11:48:57.099707
unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock")
= 0
build 03-Mar-2023 11:50:1218999 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock]
build 03-Mar-2023 11:50:1218999 [main] [TRACE] Acquiring write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:50:1219066 [main] [TRACE] Releasing write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
{code}
{code:title=successful build}
error 03-Mar-2023 11:48:57[pid 4126962] 11:48:57.118526 openat(AT_FDCWD,
"/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock",
O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65
error 03-Mar-2023 11:48:57[pid 4126962] 11:48:57.118618
unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock")
= 0
build 03-Mar-2023 11:52:0918917 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock]
build 03-Mar-2023 11:52:0918917 [main] [TRACE] Acquiring write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:52:0919050 [main] [TRACE] Releasing write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:53:004091 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock]
error 03-Mar-2023 11:53:00[pid 4130224] 11:53:00.635067 openat(AT_FDCWD,
"/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock",
O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65
error 03-Mar-2023 11:53:00[pid 4130224] 11:53:00.635171
unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock")
= 0
build 03-Mar-2023 11:53:004092 [main] [TRACE] Acquiring write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:53:004093 [main] [TRACE] Releasing write lock for
'/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock'
build 03-Mar-2023 11:53:113924 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock]
error 03-Mar-2023 11:53:11[pid 4130272] 11:53:11.154681 openat(AT_FDCWD,
"/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695237#comment-17695237
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] I'm unfamiliar with Redisson. Is there a setup doc somewhere this
is mentioned for debugging or anything?
I can also set an env to use a nightly snapshot to see if I can reproduce this
if that helps. Would it be best to use the 3.9.x version then?
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:40
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695084#comment-17695084
]
Jim Sellers commented on MNG-7705:
--
If it helps to know, for me on mac it's {{apfs}} and on the linus machine it's
{{xfs}}
I'm glad that you were able to reproduce it. Sorry it's not easy too though.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependen
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694703#comment-17694703
]
Jim Sellers commented on MNG-7705:
--
Sorry about that. I updated the versions.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.ma
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694627#comment-17694627
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] I hope that this helps. I made a repo that I can reproduce the
issue, including on my old mac. It's a bit rough, but hopefully should let you
see what's happening on your side. Please let me know if you can get it to fail.
The readme is just a general guideline. Hopefully that helps.
https://github.com/sellersj/maven-troubleshooting-MNG-7705
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.depen
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694543#comment-17694543
]
Jim Sellers commented on MNG-7705:
--
I've attached 2023-02-28_failure.zip. I had missed setting the MAVEN_OPS so
maybe that was missing generating what you need.
However, I suspect that this won't give you enough info so I'm going to see if
I can make a git repo where this will be reproducible.
Thanks for all your help and time. I really appreciate it.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependen
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: 2023-02-28_failure.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip,
> MNG-7705.zip, MNG-7705_strace_2023-02-27.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doEx
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: MNG-7705_strace_2023-02-27.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705-2023-02-27.zip, MNG-7705.zip,
> MNG-7705_strace_2023-02-27.zip, apache-maven-3.9.1-SNAPSHOT-bin.tar.gz,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (Resolv
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694181#comment-17694181
]
Jim Sellers commented on MNG-7705:
--
I tried to use {{strace -f -tt -e trace=file mvn}} for all the commands. I'm
attaching a zip where 1 of 3 concurrent builds failed.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705-2023-02-27.zip, MNG-7705.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:34
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694157#comment-17694157
]
Jim Sellers commented on MNG-7705:
--
I'm sorry, I thought that the s was a typo and you had meant just the log. Was
there any specific flags that you wanted to make sure that I have set?
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705-2023-02-27.zip, MNG-7705.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependency
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694053#comment-17694053
]
Jim Sellers commented on MNG-7705:
--
Attached the log. Sorry I didn't see your earlier comment.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705-2023-02-27.zip, MNG-7705.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDe
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: MNG-7705-2023-02-27.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705-2023-02-27.zip, MNG-7705.zip,
> apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (ResolveDependenciesMojo.java:103)
> at
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694022#comment-17694022
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] I can still reproduce the error with that snapshot build. It
always seems to be on the {{.lastUpdated}} files. Sometimes on pom's, sometimes
on other artifacts like the javadocs.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Fix For: 3.9.2
>
> Attachments: MNG-7705.zip, apache-maven-3.9.1-SNAPSHOT-bin.tar.gz,
> maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692405#comment-17692405
]
Jim Sellers commented on MNG-7705:
--
[~michael-o] I replaced the jar and I still get the same issue.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip, maven-resolver-util-1.9.6-SNAPSHOT.jar
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (ResolveDependenciesMojo.java:103)
> at
> org.apache.mave
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692370#comment-17692370
]
Jim Sellers commented on MNG-7705:
--
I've got the file lock working, but I can still trigger the issue, specifically
for the {{.lastUpdated}} files.
In the below log snipit, you can see that a file lock is acquired for
spring-beans, but then it fails while writing the tracking file (or files).
{code:title=partial failing log}
12079 [main] [TRACE] Need 1 write lock(s) for
[/home/bamboo/.m2/repository/.locks/org.springframework~spring-beans~3.0.6.RELEASE.lock]
12079 [main] [TRACE] Acquiring write lock for
'/home/bamboo/.m2/repository/.locks/org.springframework~spring-beans~3.0.6.RELEASE.lock'
12079 [main] [TRACE] Total locks acquired: 1
12079 [main] [DEBUG] Resolving artifact
org.springframework:spring-beans:pom:3.0.6.RELEASE from [asb-repository
(https://example.com/maven-proxy/content/groups/all-released, default,
releases+snapshots), asb-snapshot-repository
(https://example.com/maven-proxy/content/groups/all-snapshots, default,
snapshots)]
12079 [main] [DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://example.com/maven-proxy/content/groups/all-released
12079 [main] [DEBUG] Using connector BasicRepositoryConnector with priority 0.0
for https://example.com/maven-proxy/content/groups/all-released
12079 [main] [INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/springframework/spring-beans/3.0.6.RELEASE/spring-beans-3.0.6.RELEASE.pom
12084 [main] [INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/springframework/spring-beans/3.0.6.RELEASE/spring-beans-3.0.6.RELEASE.pom
(2.2 kB at 442 kB/s)
12084 [main] [DEBUG] Writing tracking file
'/home/bamboo/.m2/repository/org/springframework/spring-beans/3.0.6.RELEASE/_remote.repositories'
12085 [main] [WARNING] Failed to write tracking file
'/home/bamboo/.m2/repository/org/springframework/spring-beans/3.0.6.RELEASE/spring-beans-3.0.6.RELEASE.pom.lastUpdated'
java.nio.file.NoSuchFileException:
/home/bamboo/.m2/repository/org/springframework/spring-beans/3.0.6.RELEASE/spring-beans-3.0.6.RELEASE.pom.lastUpdated
at sun.nio.fs.UnixException.translateToIOException (UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel
(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel (Files.java:361)
at java.nio.file.Files.newByteChannel (Files.java:407)
at java.nio.file.spi.FileSystemProvider.newInputStream
(FileSystemProvider.java:384)
at java.nio.file.Files.newInputStream (Files.java:152)
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
(DefaultTrackingFileManager.java:90)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
(DefaultUpdateCheckManager.java:604)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
(DefaultUpdateCheckManager.java:539)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
(DefaultArtifactResolver.java:701)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:592)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:478)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:278)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:255)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
(DefaultArtifactDescriptorReader.java:228)
at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
(DefaultArtifactDescriptorReader.java:169)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor
(DfDependencyCollector.java:316)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult
(DfDependencyCollector.java:301)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:188)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java:137)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process
(DfDependencyCollector.java:125)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doRecurse
(DfDependencyCollector.java:284)
at
org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency
(DfDependencyCollector.java
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692351#comment-17692351
]
Jim Sellers commented on MNG-7705:
--
Thank you [~sjaranowski]. That seems to work for my test project.
I've got multiple activeByDefault enabled. I'll take a close look at this for
maven 3.9.0.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (ResolveDepe
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692276#comment-17692276
]
Jim Sellers commented on MNG-7705:
--
If it helps, I created a minimal maven project that shows this.
https://github.com/sellersj/maven-hello-world
I don't think that you can see the log from the github actions, but here's the
start of it.
{code}
Run ./mvnw -V --batch-mode help:effective-settings help:active-profiles
--settings maven/lock-on-file-settings.xml
-Dorg.slf4j.simpleLogger.showDateTime=true
-Dorg.slf4j.simpleLogger.log.org.eclipse.aether=trace
-Dorg.slf4j.simpleLogger.showThreadName=true
Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home:
/home/runner/.m2/wrapper/dists/apache-maven-3.9.0-bin/31cc4014/apache-maven-3.9.0
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/usr/lib/jvm/temurin-17-jdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-1033-azure", arch: "amd64", family: "unix"
1118 [main] [DEBUG] Created adapter factory; available factories [file-lock,
rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
file-gav, file-hgav, gav, static]
1187 [main] [DEBUG] Using manager EnhancedLocalRepositoryManager with priority
10.0 for /home/runner/.m2/repository
1188 [main] [INFO] Scanning for projects...
1261 [main] [DEBUG] Creating adapter using nameMapper 'gav' and factory
'rwlock-local'
{code}
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692221#comment-17692221
]
Jim Sellers commented on MNG-7705:
--
Yes, local to the network nexus, so at least things are cached there.
Yes, the profile is active. I added {{help:active-profiles}} to the above
command and when I run it in a minimal pom I see
{code}
9913 [main] [INFO]
9913 [main] [INFO] --- help:3.3.0:active-profiles (default-cli) @ Zminimal ---
9915 [main] [INFO]
Active Profiles for Project 'com.example:Zminimal:jar:0.0.1-SNAPSHOT':
The following profiles are active:
- testing-lock (source: external)
{code}
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
>
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692212#comment-17692212
]
Jim Sellers commented on MNG-7705:
--
Failure maybe about once a week. I can more easily trigger it by clearing out
the ~/.m2/repository and forcing checks of different branches of the BOM build
(logs attached) which downloads a lot.
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDe
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692208#comment-17692208
]
Jim Sellers commented on MNG-7705:
--
Thank you. I've attached a log where I've used the command line parms and can
see it file locking, which is great.
I've tried porting those parms as properties in the settings.xml and when I do
the logging I see it just using the jvm ones.
{code:title=Sample settings.xml}
http://maven.apache.org/SETTINGS/1.2.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.2.0
http://maven.apache.org/xsd/settings-1.2.0.xsd";>
testing-lock
true
file-lock
file-gav
{code}
{code:title=command used}
apache-maven-3.9.0/bin/mvn --settings settings-lock-example.xml
help:effective-settings -V -Dorg.slf4j.simpleLogger.showDateTime=true
-Dorg.slf4j.simpleLogger.log.org.eclipse.aether=trace
-Dorg.slf4j.simpleLogger.showThreadName=true | grep -e "Created adapter
factory" -e "Creating adapter using nameMapper"
{code}
{code:title=result}
[main] [DEBUG] Created adapter factory; available factories [file-lock,
rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
file-gav, file-hgav, gav, static]
[main] [DEBUG] Creating adapter using nameMapper 'gav' and factory
'rwlock-local'
{code}
[~loginatnine] or [~cstamas] do you have any hints what I am doing wrong?
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:
[jira] [Updated] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Sellers updated MNG-7705:
-
Attachment: MNG-7705.zip
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
> Attachments: MNG-7705.zip
>
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
> (AbstractDependencyFilterMojo.java:340)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
> (ResolveDependenciesMojo.java:103)
> at
> org.apache.maven.plugins.dependency.resolvers.ResolveDependencySourcesMojo.doExecute
> (ResolveDependencySourcesMojo.java:52)
> at org.apac
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691788#comment-17691788
]
Jim Sellers commented on MNG-7705:
--
Thank you [~michael-o] for the links. Helpful and part of maven I never dug
into before.
So, would the proper way to have it setup on a CI server with a shared maven
local would be to have the system args or set at properties in the
{{settings.xml}} file?
{code:title=Additional args to use file locking}
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
{code}
> Sporadic failures on multiple builds sharing the same local repo when writing
> the .lastUpdated file
> ---
>
> Key: MNG-7705
> URL: https://issues.apache.org/jira/browse/MNG-7705
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0
> Environment: Apache Maven 3.9.0
> (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: /data00/bamboo/maven/maven-next
> Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
> Default locale: en_CA, platform encoding: ISO-8859-1
> OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Jim Sellers
>Priority: Minor
>
> On a CI server, we have multiple builds running on the same host and sharing
> the same repo.
> While testing 3.9.0, I started to see a NIO exception for the
> {{.lastUpdated}} file. This has worked fine for years, all the way up to
> 3.8.7.
> If you re-run the build, it will work. I think that it's just a collision
> between the different processes.
> {code:title=example command}
> mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
> # this uses dependency:3.5.0:sources
> {code}
> {code:title=stracktrace}
> [WARNING] Failed to write tracking file
> '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
> java.nio.file.NoSuchFileException:
> /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
> at sun.nio.fs.UnixException.translateToIOException
> (UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException
> (UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel
> (UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel (Files.java:361)
> at java.nio.file.Files.newByteChannel (Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream
> (FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream (Files.java:152)
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:90)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
> (DefaultUpdateCheckManager.java:604)
> at
> org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
> (DefaultUpdateCheckManager.java:539)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:701)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:97)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
> (Maven31ArtifactResolver.java:78)
> at
> org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:70)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
> (AbstractDependencyFilterMojo.java:464)
> at
> org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
> (AbstractDependencyFilterMojo.java:408)
> at
> org.apache.maven.plugins.dependency.fromD
[jira] [Created] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
Jim Sellers created MNG-7705:
Summary: Sporadic failures on multiple builds sharing the same
local repo when writing the .lastUpdated file
Key: MNG-7705
URL: https://issues.apache.org/jira/browse/MNG-7705
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.0
Environment: Apache Maven 3.9.0
(9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /data00/bamboo/maven/maven-next
Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre
Default locale: en_CA, platform encoding: ISO-8859-1
OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family:
"unix"
Reporter: Jim Sellers
On a CI server, we have multiple builds running on the same host and sharing
the same repo.
While testing 3.9.0, I started to see a NIO exception for the {{.lastUpdated}}
file. This has worked fine for years, all the way up to 3.8.7.
If you re-run the build, it will work. I think that it's just a collision
between the different processes.
{code:title=example command}
mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc
# this uses dependency:3.5.0:sources
{code}
{code:title=stracktrace}
[WARNING] Failed to write tracking file
'/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated'
java.nio.file.NoSuchFileException:
/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated
at sun.nio.fs.UnixException.translateToIOException
(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException
(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException
(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel
(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel (Files.java:361)
at java.nio.file.Files.newByteChannel (Files.java:407)
at java.nio.file.spi.FileSystemProvider.newInputStream
(FileSystemProvider.java:384)
at java.nio.file.Files.newInputStream (Files.java:152)
at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
(DefaultTrackingFileManager.java:90)
at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
(DefaultUpdateCheckManager.java:604)
at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact
(DefaultUpdateCheckManager.java:539)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
(DefaultArtifactResolver.java:701)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:592)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:478)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:278)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:255)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
(DefaultRepositorySystem.java:296)
at
org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
(Maven31ArtifactResolver.java:97)
at
org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact
(Maven31ArtifactResolver.java:78)
at
org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact
(DefaultArtifactResolver.java:70)
at
org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve
(AbstractDependencyFilterMojo.java:464)
at
org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies
(AbstractDependencyFilterMojo.java:408)
at
org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets
(AbstractDependencyFilterMojo.java:340)
at
org.apache.maven.plugins.dependency.resolvers.ResolveDependenciesMojo.doExecute
(ResolveDependenciesMojo.java:103)
at
org.apache.maven.plugins.dependency.resolvers.ResolveDependencySourcesMojo.doExecute
(ResolveDependencySourcesMojo.java:52)
at org.apache.maven.plugins.dependency.AbstractDependencyMojo.execute
(AbstractDependencyMojo.java:159)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:342)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:330)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.ja
[jira] [Commented] (MJLINK-6) Allow set the jmods path
[ https://issues.apache.org/jira/browse/MJLINK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16528393#comment-16528393 ] Jim Sellers commented on MJLINK-6: -- [~andrioli] is this the use case you're looking for? [https://stackoverflow.com/a/47611708/2055199] > Allow set the jmods path > > > Key: MJLINK-6 > URL: https://issues.apache.org/jira/browse/MJLINK-6 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-2 >Reporter: Roberto Araujo >Priority: Minor > > The current version of the plugin hard-coded the `jmods` folder (based on > `jlink` binary location). But, for instance, if I want to build a runtime > image for Linux running the build in a OSX the runtime image will not be > compatible. > I suggest to allow users define the JDK `jmods` folder, and if nothing is > set, use the one based on the JAVA_HOME/Toolchain configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJLINK-19) update plexus-java / asm so it will work on java 10.0.1
Jim Sellers created MJLINK-19:
-
Summary: update plexus-java / asm so it will work on java 10.0.1
Key: MJLINK-19
URL: https://issues.apache.org/jira/browse/MJLINK-19
Project: Maven JLink Plugin
Issue Type: Improvement
Affects Versions: 3.0.0-alpha-2
Reporter: Jim Sellers
To get it to work on mac / java 10, I had to bump up asm 6.2. This is similar
to MCOMPILER-342
plexus-java 0.9.10 uses asm 6.2 transitively.
I'm not sure if some versions are being held back for compatibility reasons
(like maven core) but here's what's out of date.
{code:title=versions:display-dependency-updates}
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] org.apache.commons:commons-lang3 .. 3.6 -> 3.7
[INFO] org.apache.maven:maven-core . 3.0 -> 3.5.4
[INFO] org.apache.maven:maven-plugin-api ... 3.0 -> 3.5.4
[INFO] org.assertj:assertj-core . 1.7.1 -> 3.10.0
[INFO] org.codehaus.plexus:plexus-archiver . 3.5 -> 3.6.0
[INFO] org.codehaus.plexus:plexus-java .. 0.9.7 -> 0.9.10
[INFO] org.mockito:mockito-core ... 1.10.19 -> 2.19.0
[INFO]
[INFO] artifact org.apache.maven.shared:maven-shared-resources: checking for
updates from central
[INFO] No dependencies in pluginManagement of plugins have newer versions.
[INFO]
[INFO] artifact org.codehaus.mojo:extra-enforcer-rules: checking for updates
from central
[INFO] The following dependencies in Plugin Dependencies have newer versions:
[INFO] org.codehaus.mojo:extra-enforcer-rules .. 1.0-beta-7 -> 1.0-beta-9
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365156#comment-365156
]
Jim Sellers commented on MJAVADOC-424:
--
2.10.3-SNAPSHOT resolves this issue for me.
Thanks!
> Compile errors and warning when generating the test-javadoc
> ---
>
> Key: MJAVADOC-424
> URL: https://jira.codehaus.org/browse/MJAVADOC-424
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Jim Sellers
>
> With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
> means now I get javadoc warnings and errors when creating a site. The errors
> fail the build.
> This showed up because code in src/test/java used constants defined in
> src/main/java.
> Work around was to revert to 2.9.1
> {code:XML|title=Sample pom snipit}
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> 2.10.1
>
> false
> true
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
> true
>
>
>
> default
>
> javadoc
> test-javadoc
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365117#comment-365117
]
Jim Sellers commented on MJAVADOC-424:
--
I'll try to test 2.10.3-SNAPSHOT tomorrow.
> Compile errors and warning when generating the test-javadoc
> ---
>
> Key: MJAVADOC-424
> URL: https://jira.codehaus.org/browse/MJAVADOC-424
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Jim Sellers
>
> With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
> means now I get javadoc warnings and errors when creating a site. The errors
> fail the build.
> This showed up because code in src/test/java used constants defined in
> src/main/java.
> Work around was to revert to 2.9.1
> {code:XML|title=Sample pom snipit}
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> 2.10.1
>
> false
> true
>
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> false
> true
>
>
>
> default
>
> javadoc
> test-javadoc
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
Jim Sellers created MJAVADOC-424:
Summary: Compile errors and warning when generating the
test-javadoc
Key: MJAVADOC-424
URL: https://jira.codehaus.org/browse/MJAVADOC-424
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10.1
Reporter: Jim Sellers
With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
means now I get javadoc warnings and errors when creating a site. The errors
fail the build.
This showed up because code in src/test/java used constants defined in
src/main/java.
Work around was to revert to 2.9.1
{code:XML|title=Sample pom snipit}
org.apache.maven.plugins
maven-javadoc-plugin
2.10.1
false
true
org.apache.maven.plugins
maven-javadoc-plugin
false
true
default
javadoc
test-javadoc
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ https://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282157#comment-282157 ] Jim Sellers commented on SUREFIRE-377: -- Thanks all for the solution. Note: I ran into an issue when using it with sonar. See SONAR-2408 > When JUnit and TestNG tests are in same project, only one set gets run > -- > > Key: SUREFIRE-377 > URL: https://jira.codehaus.org/browse/SUREFIRE-377 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 >Reporter: Dan Fabulich > Fix For: 2.4 > > Attachments: surefire377.patch, testng-junit-together.zip > > > The attached Maven project has two tests: one JUnit test and one TestNG test. > According to the documentation, in this case TestNG should run both tests. > Run "mvn test". Only the TestNG test will run. If you modify the pom to set > the property "junit=true", only the JUnit test will run. > > org.apache.maven.plugins > maven-surefire-plugin > 2.4-SNAPSHOT > > > > junit > true > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match
[ http://jira.codehaus.org/browse/MECLIPSE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=269187#action_269187 ] Jim Sellers commented on MECLIPSE-655: -- Mark: I don't know why it's not been fixed. Perhaps because I didn't submit a unit test? We've been using a patched version of the eclipse plugin for a year now in order to get around this issue. You might want to do the same. > does not correctly resolve SNAPSHOTS from CI server with projects in > workspace because versions do not match > > > Key: MECLIPSE-655 > URL: http://jira.codehaus.org/browse/MECLIPSE-655 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.8 > Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.5.0_16 >Reporter: Jim Sellers > Attachments: maven-eclipse-snapshot-issue.txt > > > Scenario: > 1) Check out a library into your workspace, in SNAPSHOT mode. e.g. the > version is 2.0-SNAPSHOT. > 2) This project is being built by a CI server, using the standard snapshot > artifact naming convention. e.g. 2.0-20100513.210009-65 > 3) In project in workspace that uses the library, when you run > eclipse:eclipse, in the .classpath file it will link to the jar in the > .m2/repository location. In the log you'll see a message like: > [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a > workspace project, but with different version. Expected: > 2.0-20100513.210009-65, found: 2.0-SNAPSHOT > The weird issues: > W1) The difficult part is that if in the library you run a "mvn install" > command first, and then in the other project run "mvn eclipse:eclipse", it > will correctly depend on your project in the workspace. > W2) After doing W1, if the next day you re-run "mvn eclipse:eclipse" in the > non-library project, it will then resolve to the artifact built in the CI > server and no longer link the project to the library in the workspace. > The workaround: > Each day run "mvn install" in the library before running "mvn > eclipse:eclipse" in the other project. > The solution (no patch yet, can't make it through the firewall at work): > Instead of using org.apache.maven.artifact.Artifact#getVersion(), > getBaseVersion() should be used instead. > In the AbstractIdeSupportMojo#doDependencyResolution() method, near the > bottom where it passing in the version, it should use the getBaseVersion() > http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685 > In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) > method, it should compare the "version" in the workspace to the "baseVersion" > http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-201) Add option to tree goal to generate tree based on dependencyManagement
[ http://jira.codehaus.org/browse/MDEP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221930#action_221930 ] Jim Sellers commented on MDEP-201: -- I posted our workaround for resolving dependencies from dependencyManagement in MDEP-213. That might be useful for you as well. > Add option to tree goal to generate tree based on dependencyManagement > -- > > Key: MDEP-201 > URL: http://jira.codehaus.org/browse/MDEP-201 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Paul Gier >Assignee: Brian Fox > > I have a parent pom that controls the dependency versions for a multimodule > project. I would like to be able to generate a dependency tree from this > pom, so that I can see the tree for the entire project, but currently the > tree goal only looks at actual dependencies and not those in dependency > management. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-213) resolve dependencyManagement section with option to fail the build
[
http://jira.codehaus.org/browse/MDEP-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221929#action_221929
]
Jim Sellers commented on MDEP-213:
--
As a work around I created a groovy script that will that:
1) take the pom, copy it to the target directory
2) remove the dependencyManagement tags so that the pom just has dependencies
3) run dependency:resolve on that modified pom, failing the build if
dependency:resolve fails.
In the pom:
{noformat}
org.codehaus.groovy.maven
gmaven-plugin
generate-test-sources
execute
${pom.basedir}/src/main/script/resolveDepMgmt.groovy
{noformat}
The contents of resolveDepMgmt.groovy is:
{noformat}
import org.apache.commons.lang.SystemUtils
log.info('About to run check on the dependency management section...')
// read the pom, remove the dependencyManagement tags
File sourceFile = new File('pom.xml')
String text = sourceFile.text.replaceAll('',
'').replaceAll('', '')
// make the outputDirectory if it does not exist
File outputDir = new File('target')
if (!outputDir.exists())
outputDir.mkdirs()
File ouputFile = new File(outputDir.getAbsolutePath() +
'/pom-only-dependencies.xml')
ouputFile.write(text)
String mvnCommand = "mvn dependency:resolve -f " + ouputFile.getAbsolutePath()
// because mvn is not an executable program on windows
if (SystemUtils.IS_OS_WINDOWS)
mvnCommand = 'cmd /c ' + mvnCommand
outputCatcher = new StringBuffer()
errorCatcher = new StringBuffer()
proc = mvnCommand.execute()
proc.consumeProcessOutput(outputCatcher, errorCatcher)
proc.waitFor()
// print the output / errors to the screen
println outputCatcher
// have the calling process share the exit value of the maven command if there
was an error
if (0 != proc.exitValue())
fail('failed resolving dependencies')
{noformat}
> resolve dependencyManagement section with option to fail the build
> --
>
> Key: MDEP-213
> URL: http://jira.codehaus.org/browse/MDEP-213
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: resolve
>Affects Versions: 2.0
>Reporter: Jim Sellers
>Assignee: Brian Fox
>
> When using the dependencyManagement section of a pom of type "pom" to create
> a bill of materials, it's currently possible to specify an invalid version.
> eg:
> {code:xml}
>
>
>
> commons-logging
> commons-logging
> 9.9
>
>
>
> {code}
> It would be really useful for these types of pom's to be able to force all
> the dependencies to be resolved when running something like "install" and
> have that fail the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-655) does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match
does not correctly resolve SNAPSHOTS from CI server with projects in workspace because versions do not match Key: MECLIPSE-655 URL: http://jira.codehaus.org/browse/MECLIPSE-655 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.8 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) Java version: 1.5.0_16 Reporter: Jim Sellers Attachments: maven-eclipse-snapshot-issue.txt Scenario: 1) Check out a library into your workspace, in SNAPSHOT mode. e.g. the version is 2.0-SNAPSHOT. 2) This project is being built by a CI server, using the standard snapshot artifact naming convention. e.g. 2.0-20100513.210009-65 3) In project in workspace that uses the library, when you run eclipse:eclipse, in the .classpath file it will link to the jar in the .m2/repository location. In the log you'll see a message like: [INFO] Artifact com.example:MyLibrary:jar:2.0-SNAPSHOT already available as a workspace project, but with different version. Expected: 2.0-20100513.210009-65, found: 2.0-SNAPSHOT The weird issues: W1) The difficult part is that if in the library you run a "mvn install" command first, and then in the other project run "mvn eclipse:eclipse", it will correctly depend on your project in the workspace. W2) After doing W1, if the next day you re-run "mvn eclipse:eclipse" in the non-library project, it will then resolve to the artifact built in the CI server and no longer link the project to the library in the workspace. The workaround: Each day run "mvn install" in the library before running "mvn eclipse:eclipse" in the other project. The solution (no patch yet, can't make it through the firewall at work): Instead of using org.apache.maven.artifact.Artifact#getVersion(), getBaseVersion() should be used instead. In the AbstractIdeSupportMojo#doDependencyResolution() method, near the bottom where it passing in the version, it should use the getBaseVersion() http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/ide/AbstractIdeSupportMojo.html#685 In the EclipsePlugin#isAvailableAsAWorkspaceProject( Artifact artifact ) method, it should compare the "version" in the workspace to the "baseVersion" http://maven.apache.org/plugins/maven-eclipse-plugin/xref/org/apache/maven/plugin/eclipse/EclipsePlugin.html#1941 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-171) link to "Unpacking the Project Dependencies" is broken - website
[ http://jira.codehaus.org/browse/MDEP-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204619#action_204619 ] Jim Sellers commented on MDEP-171: -- I did as requested and I figured out something. 1) in the site.xml files, the text and number of bullets do not match the text I was looking at. Apparently the stuff from the site.xml file goes into the sidenav. 2) the index.html page that gets generated seems to come from src/site/apt/index.apt See line 123 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-dependency-plugin/src/site/apt/index.apt?revision=801211&view=markup > link to "Unpacking the Project Dependencies" is broken - website > > > Key: MDEP-171 > URL: http://jira.codehaus.org/browse/MDEP-171 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jim Sellers >Assignee: Brian Fox >Priority: Trivial > Fix For: 2.1 > > > On the website [1] the link for "Unpacking the Project Dependencies" goes to > the "Copying Project Dependencies" page. It should go to the correct page > [2]. > [1] http://maven.apache.org/plugins/maven-dependency-plugin/ > [2] > http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-project-dependencies.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MDEP-171) link to "Unpacking the Project Dependencies" is broken - website
[ http://jira.codehaus.org/browse/MDEP-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Sellers reopened MDEP-171: -- Still looks broken to me. It's in the "example" section as follows: Examples The following examples show how to use the dependency plugin in more advanced use-cases: * Instructions on how to prepare your dependencies for upgrade to Maven 2.0.6 / 2.1. * Copying Specific Artifacts * Copying Project Dependencies * Unpacking Specific Artifacts * Unpacking the Project Dependencies > link to "Unpacking the Project Dependencies" is broken - website > > > Key: MDEP-171 > URL: http://jira.codehaus.org/browse/MDEP-171 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jim Sellers >Assignee: Brian Fox >Priority: Trivial > Fix For: 2.1 > > > On the website [1] the link for "Unpacking the Project Dependencies" goes to > the "Copying Project Dependencies" page. It should go to the correct page > [2]. > [1] http://maven.apache.org/plugins/maven-dependency-plugin/ > [2] > http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-project-dependencies.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-615) WTP does not link war's to a jar module if it also uses a test-jar
[
http://jira.codehaus.org/browse/MECLIPSE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196537#action_196537
]
Jim Sellers edited comment on MECLIPSE-615 at 10/29/09 9:51 AM:
Oie.
This can be lined up to improper configuration by someone else and me not being
able to catch it. Thankfully another set of eyes was able to see it.
In the war, the improper config was along the lines of:
{code:xml}
com.example
WhatWTPTroubleJar
0.0.1-SNAPSHOT
tests
test
{code}
- using a "classifier"
The proper config for a testing jar is:
{code:xml}
com.example
WhatWTPTroubleJar
0.0.1-SNAPSHOT
test-jar
test
{code}
- using a "type" of test-jar
Sorry for the noise in jira / mailing list.
was (Author: sellersj):
Oie.
This can be lined up to improper configuration by someone else and me not being
able to catch it.
In the war, the improper config was along the lines of:
com.example
WhatWTPTroubleJar
0.0.1-SNAPSHOT
tests
test
- using a "classifier"
The proper config for a testing jar is:
com.example
WhatWTPTroubleJar
0.0.1-SNAPSHOT
test-jar
test
- using a "type" of test-jar
Sorry for the noise in jira / mailing list.
> WTP does not link war's to a jar module if it also uses a test-jar
> --
>
> Key: MECLIPSE-615
> URL: http://jira.codehaus.org/browse/MECLIPSE-615
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Affects Versions: 2.7
> Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
> Java version: 1.5.0_16
> Java home: C:\devtools\java\jdk1.5.0_16\jre
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Jim Sellers
> Fix For: 2.7
>
> Attachments: WhatWTPTrouble.zipx
>
>
> If a war file refers to a jar module in the same project AND a test-jar from
> that same project it will
> 1) not link to the actual project [1]
> 2) not deploy the packaged .jar file
> 3) put both the jar and the jar's dependencies in the manifest.mf for the war
> 4) it puts the jar's dependencies into the war
> The war project is now in an inconsistent state.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-615) WTP does not link war's to a jar module if it also uses a test-jar
[ http://jira.codehaus.org/browse/MECLIPSE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Sellers closed MECLIPSE-615. Resolution: Not A Bug Fix Version/s: 2.7 Oie. This can be lined up to improper configuration by someone else and me not being able to catch it. In the war, the improper config was along the lines of: com.example WhatWTPTroubleJar 0.0.1-SNAPSHOT tests test - using a "classifier" The proper config for a testing jar is: com.example WhatWTPTroubleJar 0.0.1-SNAPSHOT test-jar test - using a "type" of test-jar Sorry for the noise in jira / mailing list. > WTP does not link war's to a jar module if it also uses a test-jar > -- > > Key: MECLIPSE-615 > URL: http://jira.codehaus.org/browse/MECLIPSE-615 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.7 > Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.5.0_16 > Java home: C:\devtools\java\jdk1.5.0_16\jre > Default locale: en_CA, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Jim Sellers > Fix For: 2.7 > > Attachments: WhatWTPTrouble.zipx > > > If a war file refers to a jar module in the same project AND a test-jar from > that same project it will > 1) not link to the actual project [1] > 2) not deploy the packaged .jar file > 3) put both the jar and the jar's dependencies in the manifest.mf for the war > 4) it puts the jar's dependencies into the war > The war project is now in an inconsistent state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-615) WTP does not link war's to a jar module if it also uses a test-jar
[ http://jira.codehaus.org/browse/MECLIPSE-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196478#action_196478 ] Jim Sellers commented on MECLIPSE-615: -- this is using eclipse 3.5 > WTP does not link war's to a jar module if it also uses a test-jar > -- > > Key: MECLIPSE-615 > URL: http://jira.codehaus.org/browse/MECLIPSE-615 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.7 > Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.5.0_16 > Java home: C:\devtools\java\jdk1.5.0_16\jre > Default locale: en_CA, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Jim Sellers > Attachments: WhatWTPTrouble.zipx > > > If a war file refers to a jar module in the same project AND a test-jar from > that same project it will > 1) not link to the actual project [1] > 2) not deploy the packaged .jar file > 3) put both the jar and the jar's dependencies in the manifest.mf for the war > 4) it puts the jar's dependencies into the war > The war project is now in an inconsistent state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-615) WTP does not link war's to a jar module if it also uses a test-jar
WTP does not link war's to a jar module if it also uses a test-jar -- Key: MECLIPSE-615 URL: http://jira.codehaus.org/browse/MECLIPSE-615 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.7 Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) Java version: 1.5.0_16 Java home: C:\devtools\java\jdk1.5.0_16\jre Default locale: en_CA, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Jim Sellers Attachments: WhatWTPTrouble.zipx If a war file refers to a jar module in the same project AND a test-jar from that same project it will 1) not link to the actual project [1] 2) not deploy the packaged .jar file 3) put both the jar and the jar's dependencies in the manifest.mf for the war 4) it puts the jar's dependencies into the war The war project is now in an inconsistent state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-213) resolve dependencyManagement section with option to fail the build
resolve dependencyManagement section with option to fail the build
--
Key: MDEP-213
URL: http://jira.codehaus.org/browse/MDEP-213
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: resolve
Affects Versions: 2.0
Reporter: Jim Sellers
Assignee: Brian Fox
When using the dependencyManagement section of a pom of type "pom" to create a
bill of materials, it's currently possible to specify an invalid version. eg:
{code:xml}
commons-logging
commons-logging
9.9
{code}
It would be really useful for these types of pom's to be able to force all the
dependencies to be resolved when running something like "install" and have that
fail the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-565) Classpath entries to be marked as NOT exported
[ http://jira.codehaus.org/browse/MECLIPSE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=177135#action_177135 ] Jim Sellers commented on MECLIPSE-565: -- Found a workaround: "As a workaround these warnings can be filtered out by removing selection from "Classpath Dependency Validator Message" in Problems view filter configuration." http://code.google.com/p/q4e/issues/detail?id=162 > Classpath entries to be marked as NOT exported > -- > > Key: MECLIPSE-565 > URL: http://jira.codehaus.org/browse/MECLIPSE-565 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.6 >Reporter: Jim Sellers > > This is the other side of the MECLIPSE-230. > In my war project, for all the jar's that are provided, test, or otherwise > NOT to be exported, eclipse complains with a warning: > "Classpath entry M2_REPO/junit/junit/4.4/junit-4.4.jar will not be exported > or published. Runtime ClassNotFoundExceptions may result." > The work around is the "quick fix", but that means that you have to do this > every time you run eclipse:eclipse. > The fix would be to add that it is a non-dependency: >sourcepath="M2_REPO/junit/junit/4.4/junit-4.4-sources.jar"> > >name="org.eclipse.jst.component.nondependency" value=""/> > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-565) Classpath entries to be marked as NOT exported
[
http://jira.codehaus.org/browse/MECLIPSE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=176461#action_176461
]
Jim Sellers commented on MECLIPSE-565:
--
I'm using eclipse 3.4.2.
Actually the exported=[true|false] doesn't show up. For the ones which are
exported, they show up as follows.
{noformat}
{noformat}
I have not actually dug through the code to check exactly where this is or how
it gets from the export to being an attribute.
> Classpath entries to be marked as NOT exported
> --
>
> Key: MECLIPSE-565
> URL: http://jira.codehaus.org/browse/MECLIPSE-565
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.6
>Reporter: Jim Sellers
>
> This is the other side of the MECLIPSE-230.
> In my war project, for all the jar's that are provided, test, or otherwise
> NOT to be exported, eclipse complains with a warning:
> "Classpath entry M2_REPO/junit/junit/4.4/junit-4.4.jar will not be exported
> or published. Runtime ClassNotFoundExceptions may result."
> The work around is the "quick fix", but that means that you have to do this
> every time you run eclipse:eclipse.
> The fix would be to add that it is a non-dependency:
>sourcepath="M2_REPO/junit/junit/4.4/junit-4.4-sources.jar">
>
>name="org.eclipse.jst.component.nondependency" value=""/>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-565) Classpath entries to be marked as NOT exported
Classpath entries to be marked as NOT exported -- Key: MECLIPSE-565 URL: http://jira.codehaus.org/browse/MECLIPSE-565 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Reporter: Jim Sellers This is the other side of the MECLIPSE-230. In my war project, for all the jar's that are provided, test, or otherwise NOT to be exported, eclipse complains with a warning: "Classpath entry M2_REPO/junit/junit/4.4/junit-4.4.jar will not be exported or published. Runtime ClassNotFoundExceptions may result." The work around is the "quick fix", but that means that you have to do this every time you run eclipse:eclipse. The fix would be to add that it is a non-dependency: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-201) Add option to tree goal to generate tree based on dependencyManagement
[ http://jira.codehaus.org/browse/MDEP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=175078#action_175078 ] Jim Sellers commented on MDEP-201: -- This would also be useful for when you are using a pom strictly as a "bill of materials" for other projects (imported with scope=import). If this goal existed, I'd configure it to run as part of the install phase for this pom in order to determine if an dependency exists. > Add option to tree goal to generate tree based on dependencyManagement > -- > > Key: MDEP-201 > URL: http://jira.codehaus.org/browse/MDEP-201 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Paul Gier >Assignee: Brian Fox > > I have a parent pom that controls the dependency versions for a multimodule > project. I would like to be able to generate a dependency tree from this > pom, so that I can see the tree for the entire project, but currently the > tree goal only looks at actual dependencies and not those in dependency > management. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3553) cannot resolve dependency with scope import
[
http://jira.codehaus.org/browse/MNG-3553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=173290#action_173290
]
Jim Sellers commented on MNG-3553:
--
Hi all.
It wasn't clear to me when I read this ticket the first time, but there is a
hack-ish work around.
Project_A depends on LIB_B imports Bill_of_Materials_C
In LIB_B I added the "repositories" section to that pom that points to our
corporate proxy. Not ideal, but until this is addressed it's the only suitable
work around that I found.
Hope that helps!
> cannot resolve dependency with scope import
> ---
>
> Key: MNG-3553
> URL: http://jira.codehaus.org/browse/MNG-3553
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9, 2.1.0
>Reporter: Thomas Diesler
>Priority: Critical
> Fix For: 2.0.11, 2.1.1
>
> Attachments: mng-3553.zip
>
>
> This pom when added as a dependency of another project does not see
> repository http://snapshots.jboss.org/maven2
>
>
>
>
> org.jboss.jbossas
> jboss-as-component-matrix
> ${jboss.version}
> pom
> import
>
>
>
> with effective settings
> [tdies...@tddell trunk]$ mvn help:effective-settings
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] JBoss Web Services - Stack CXF
> [INFO] JBoss Web Services - Stack CXF Management
> [INFO] JBoss Web Services - Stack CXF Runtime Server
> [INFO] JBoss Web Services - Stack CXF Runtime Client
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building JBoss Web Services - Stack CXF
> [INFO]task-segment: [help:effective-settings] (aggregator-style)
> [INFO]
>
> [INFO] [help:effective-settings]
> [INFO]
> Effective settings:
>
> /home/tdiesler/.m2/repository
>
>
>
>
> !jboss.repository.off
>
>
>
>
>
> snapshots.jboss.org
> http://snapshots.jboss.org/maven2
>
>
>
> false
>
> repository.jboss.org
> http://repository.jboss.org/maven2
>
>
> jboss.repository
>
>
>
> user-profile
>
>
> org.jboss.maven.plugins
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-178) symbolic links need to able to be specified in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=172964#action_172964 ] Jim Sellers commented on MECLIPSE-178: -- The plugin *does* write links, but it looks like it only does it on specific conditions. I just took a quick peek and it seems to be in org.apache.maven.plugin.eclipse.writers.EclipseProjectWriter. Not sure if you can force it to do so with config. Good luck! > symbolic links need to able to be specified in the pom > -- > > Key: MECLIPSE-178 > URL: http://jira.codehaus.org/browse/MECLIPSE-178 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Jim Sellers > > In eclipse, you can make a symbolic link to a file. > create new file -> advanced -> "link to file in the system". > This will create a part in the .project file like this: > > > src/test/resources/oracle-ds.xml > 1 > > C://jboss/server/default/deploy/oracle-ds.xml > > > When you run "mvn eclipse:eclipse" this gets wipped out. It would be great > if this soft link didn't have to be re-created someone runs the command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-318) test classes and resources need to be first in .classpath file
[ http://jira.codehaus.org/browse/MECLIPSE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146087#action_146087 ] Jim Sellers commented on MECLIPSE-318: -- Thank you. ;-) > test classes and resources need to be first in .classpath file > -- > > Key: MECLIPSE-318 > URL: http://jira.codehaus.org/browse/MECLIPSE-318 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Jim Sellers >Assignee: Benjamin Bentmann > Fix For: 2.5.2 > > > They have changed the core dependancy resolution to be "tests first". I'm > assuming that the plug-in will need to be changed to reflect this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-171) link to "Unpacking the Project Dependencies" is broken - website
link to "Unpacking the Project Dependencies" is broken - website Key: MDEP-171 URL: http://jira.codehaus.org/browse/MDEP-171 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Jim Sellers Assignee: Brian Fox Priority: Trivial On the website [1] the link for "Unpacking the Project Dependencies" goes to the "Copying Project Dependencies" page. It should go to the correct page [2]. [1] http://maven.apache.org/plugins/maven-dependency-plugin/ [2] http://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-project-dependencies.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[ http://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122176 ] Jim Sellers commented on MECLIPSE-94: - Just to add another use case: 1) you check out the pom project and its nested modules (eclipse generates the parent .project file) 2) you run eclipse:eclipse to generate all needed files 3) you'd like to clean something up, so you call eclipse:clean 4) now eclipse doesn't recognize the project at all so you can't make any changes to the parent pom since the .project files is gone This has happened quite often where I work. The work around is usually to comment out the modules section, change the type from "pom" to "jar", call eclipse:eclipse, and then undo the changes to the pom.xml file. That's pretty annoying. It would be great (as many have suggested) to just create a simple .project for projects of type pom. > Allow eclipse:eclipse to work on pom (and other) projects > - > > Key: MECLIPSE-94 > URL: http://jira.codehaus.org/browse/MECLIPSE-94 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Felipe Leme > Attachments: MECLIPSE-94.patch > > > I'm creating a Java EE project based on the m2book (which I was reviewing; > it's not available yet...) and one of the projects is a pom-packaging project > used for integration tests. According to Vincent, currently this project must > be a pom (in fact, I tried to set it as jar, but then the test phase would be > run anyway, which would cause the tests to fail), as it doesn't produces a > jar. But as it has java files (on the src/main/it/java directory), I tried to > call eclipse:eclipse but it fails, saying that "Not running eclipse plugin > goal for pom project". > For these scenarios, I think a propery would be enough. At first I thought > something about a 'force' or 'forceGeneration' property, would enough, which > the code change being from: > if ( "pom".equals( packaging ) && eclipseProjectDir == null ) > to: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > Then I realized there is other place where the pom nature is checked: > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !forceGeneration ) > So, I think a better name for the property would be 'javaProject' and the > change would be: > final boolean isJavaProjectProperty = // read property; defaults to false... > if ( "pom".equals( packaging ) && eclipseProjectDir == null && > !isJavaProjectProperty ) > isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) && > !"pom".equals( packaging ); > If nobody objects and someone is willing to apply the changes, I can provide > such patch (with the proper test cases). > -- Felipe > PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features > already existed :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-127) exclude option does not work when an external app places files into location
[ http://jira.codehaus.org/browse/MWAR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120367 ] Jim Sellers commented on MWAR-127: -- Thank you very much. That solved the issue. ;-) > exclude option does not work when an external app places files into location > > > Key: MWAR-127 > URL: http://jira.codehaus.org/browse/MWAR-127 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows 2000" version: "5.0" arch: "x86" >Reporter: Jim Sellers >Assignee: Stephane Nicoll > Attachments: WarPluginIssue.zip > > > In MyEclipse I set the source output to be src/main/webapp/WEB-INF/classes to > allow me to use the hotdeploy feature. This deploys both the test classes / > resources as well as everything in src/main to the war. > When I package up my ear / war for a release, I don't want anything that > eclipse put into src/main/webapp/WEB-INF/classes to be copied over, however I > can't get the exclude to work. > I've asked on the mailing list and tried the suggestions there, but none seem > to work. I've attached a simple project to demo the problem. Just run mvn > package. > Thanks for your time! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-48) Failed to copy full contents from
[
http://jira.codehaus.org/browse/MRESOURCES-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113723
]
Jim Sellers commented on MRESOURCES-48:
---
This might be an issue with the java version itself. I ran into a problem that
looks the same.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6481955
When I upgraded to Java version: 1.5.0_11 it fixed it.
HTH
> Failed to copy full contents from
> -
>
> Key: MRESOURCES-48
> URL: http://jira.codehaus.org/browse/MRESOURCES-48
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Thomas Hart
>Priority: Blocker
> Attachments: error.log
>
>
> Every time i execute a maven i get the message: 'Failed to copy full
> contents'. I check the code from the class FileUtils and there is a simle
> File#length() compare.
> {code}
> if( source.length() != destination.length() )
> {
> final String message = "Failed to copy full contents from " + source +
> " to " + destination;
> throw new IOException( message );
> }
> {code}
> mvn -version
> Maven version: 2.0.7
> Java version: 1.5.0_04
> OS name: "windows xp" version: "5.1" arch: "x86"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-127) exclude option does not work when an external app places files into location
exclude option does not work when an external app places files into location Key: MWAR-127 URL: http://jira.codehaus.org/browse/MWAR-127 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-1 Environment: Maven version: 2.0.7 Java version: 1.5.0_11 OS name: "windows 2000" version: "5.0" arch: "x86" Reporter: Jim Sellers Attachments: WarPluginIssue.zip In MyEclipse I set the source output to be src/main/webapp/WEB-INF/classes to allow me to use the hotdeploy feature. This deploys both the test classes / resources as well as everything in src/main to the war. When I package up my ear / war for a release, I don't want anything that eclipse put into src/main/webapp/WEB-INF/classes to be copied over, however I can't get the exclude to work. I've asked on the mailing list and tried the suggestions there, but none seem to work. I've attached a simple project to demo the problem. Just run mvn package. Thanks for your time! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-318) test classes and resources need to be first in .classpath file
test classes and resources need to be first in .classpath file -- Key: MECLIPSE-318 URL: http://jira.codehaus.org/browse/MECLIPSE-318 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Reporter: Jim Sellers They have changed the core dependancy resolution to be "tests first". I'm assuming that the plug-in will need to be changed to reflect this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-178) symbolic links need to able to be specified in the pom
symbolic links need to able to be specified in the pom -- Key: MECLIPSE-178 URL: http://jira.codehaus.org/browse/MECLIPSE-178 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: Jim Sellers In eclipse, you can make a symbolic link to a file. create new file -> advanced -> "link to file in the system". This will create a part in the .project file like this: src/test/resources/oracle-ds.xml 1 C://jboss/server/default/deploy/oracle-ds.xml When you run "mvn eclipse:eclipse" this gets wipped out. It would be great if this soft link didn't have to be re-created someone runs the command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
