apache / apache/maven

[MNG-7376] Maven artifact caching breaks in context of Jenkins Artifactory Plugin

Open
#7,939 2 comments 0 reactions 0 assignees View on GitHub
bug priority:major
Dominant language
Java
Stars
5.3k
Forks
3.1k
Avg merge
20h 40m
Merged PRs (30d)
275

Description

**[Christian Frommeyer](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=JIRAUSER282689)** opened **[MNG-7376](https://issues.apache.org/jira/browse/MNG-7376?redirect=false)** and commented

We recently run into a build issue after a library update. While local builds would still work as expected, builds on our build machine would cause reproducible failures. The actual failure happens during site-reports are generated in the surefire report plugin but I believe the actual place is just a coincidence.

Unfortunately I wasn't able to find the trigger for the changed behavior. All we did was update the version of pact-jvm in the pom. Before the change no failure after the change every build fails. As this is proprietary code base I unfortunately currently cannot provide a sample project. However there is a couple of information I was able to find:

As there is little related logging even on debug level I had a look at the code. Using the stacktrace from the Jenkins log this pointed [here](https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/DefaultProjectArtifactsCache.java#L207). Complaining about a re-caching of the project artifacts.

Looking at the calling code [here ](https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleDependencyResolver.java#L147) this doesn't seems to be possible. As the Cache-put is only called after the Cache-get returns `{}null{`}. This would only be the case if the cache was behaving incorrect (it's backed by a Java Concurrent HashMap, so pretty unlikely), or the key is not behaving as expected.

Looking at the [CacheKey](https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/DefaultProjectArtifactsCache.java#L58) reveals that this key in fact has been crafted to explicitly make it behave nicely. Most fields are immutable. However there is a small set of (potentially) mutable fields that would alter hashcode and equals result. If e.g. the RemoteRepositories stored in the `repositories` property would be altered this would change hashcode and equals. While the property is `final` and the constructor assures that it contains a fresh ArrayList, this is neither unmodifiable, nor are the repositories added to the list immutable.

To be sure I created a java-agent to monitor the behavior. I logged the key for both `get` and `put` and actually found different URLs for the repositories. Apparently the Jenkins-Artifactory-Plugin had changed them. And actually looking at the debug log there are log lines saying _Replacing resolution repository URL..._.

While this seems to happen very rarely it happens and if it does it's not fun debugging. I still don't know why it only happens rarely as I assume the plugin does rewrite the URLs always. But maybe there is only rare cases where the cache actually has data.

This are the updated artifacts:

```xml


au.com.dius.pact.consumer
junit5
${pact.version}
test


au.com.dius.pact.provider
junit5spring
${pact.version}
test


au.com.dius.pact.provider
maven
${pact.version}

```

The variable `pact.version` changed from 4.2.14 to 4.3.11

---

**Affects:** 3.8.4

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.