Hello,
In my teams, we have the dreaded : "The artifact was found in the local repository but you have explicitly stated that it should be downloaded from a remote one". I know there is already some closed issue on this and, for spring cloud contract dev team, it's a normal behavior. However I want to explain our current problem and why we really don't know how to solve this on our side.
The context is we have a Jenkins CI with shared maven repository. As soon as we build and deploy a contract producer jar, it's pushed on this shared maven repository (on install) and on the nexus remote repository (on deploy). For the consumer, we have set the repositoryRoot (because the stub jar could not be in local repo).
However as soon as we build one consumer, we have the error.
for example, this is the state of the repository for a producer service :
drwxr-xr-x 2 10000 10000 4096 Feb 9 11:06 **20180209-110444-931e7c44b2**
-rw-r--r-- 1 10000 10000 353 Feb 9 11:06 maven-metadata-local.xml
-rw-r--r-- 1 10000 10000 1529 Feb 9 11:07 maven-metadata-nexus-xxx.xml
-rw-r--r-- 1 10000 10000 40 Feb 9 11:07 maven-metadata-nexus-xxx.xml.sha1
-rw-r--r-- 1 10000 10000 1529 Feb 9 11:14 maven-metadata-remote0.xml
-rw-r--r-- 1 10000 10000 40 Feb 9 11:14 maven-metadata-remote0.xml.sha1
-rw-r--r-- 1 10000 10000 253 Feb 9 11:14 resolver-status.properties
the directory contains:
-rw-r--r-- 1 10000 10000 280 Feb 9 11:06 _remote.repositories
-rw-r--r-- 1 10000 10000 2683 Feb 9 11:06 **producer-service-20180209-110444-931e7c44b2-stubs.jar**
-rw-r--r-- 1 10000 10000 47240293 Feb 9 11:06 producer-service-20180209-110444-931e7c44b2.jar
-rw-r--r-- 1 10000 10000 14166 Feb 9 11:05 producer-service-20180209-110444-931e7c44b2.pom
To make the consumer builds correctly and remove the error, we have to delete the repository by hand. After deleting and relaunching the CI for the consumer, it downloads the stubs .... recreate the same 20180209-110444-931e7c44b2 directory which contains now:
-rw-r--r-- 1 10000 10000 193 Feb 9 11:38 _remote.repositories
-rw-r--r-- 1 10000 10000 2683 Feb 9 11:38 **producer-service-20180209-110444-931e7c44b2-stubs.jar**
-rw-r--r-- 1 10000 10000 40 Feb 9 11:38 producer-service-20180209-110444-931e7c44b2-stubs.jar.sha1
For information, the stubs jar is again present with the same size and same SHA (only the file date is of course more recent because it was now downloaded from remote as expected).
So is there a possibility to configure Spring Cloud contract to avoid this problem ?
BTW, if we look ath this line : https://github.com/spring-cloud/spring-cloud-contract/blob/748e512f4d92d67dd6d40e994163788592e7b612/spring-cloud-contract-stub-runner/src/main/java/org/springframework/cloud/contract/stubrunner/AetherStubDownloader.java#L174 it seems to say that if we tell to download repositoryRoot and there is any jar in local repository, it will fail. It seems a bit hard in our context: we want to download it from remote if not present and no error if already present (or even force the download).
Thanks a lot for your time on this matter :)
As you said you're not the first to have this problem. I guess it's high time to make this parametrizable. Obviously, you have to know what you're doing and you take responsibility for it but I guess we should allow an option to disable this check. WDYT about it?
I think it could be a great idea for make our life easier :)
Just to fully understand, why it's not normal from your point view ? (especially compared to the scenario I present you ).
I looked at the code to propose a PR but I think I don't enough skill to really understand and do something interesting :(
For 1.2.x, since I don't want to break the backward compatibility of the API, I've added assertion of
stubrunner.snapshot-check-skip system propertySTUBRUNNER_SNAPSHOT_CHECK_SKIP environment variableif either of them is set then we WILL NOT check if the jar is local or remote. So in Jenkins in each job just set the env var STUBRUNNER_SNAPSHOT_CHECK_SKIP and your builds should stop failing.
The rationale to introduce this change was that when building the project locally, you could have your build passing even though it shouldn't due to the fact that the remote stubs were ignored for some reason, and the local ones where picked. Now you'll be able to switch it off. In master I'll add the standard Spring / Maven / Gradle plugin mechanism to toggle this flag.
Thanks a lot! Seems a simple solution to make our life better :)
In which version, will it be available on mvn repository ?
1.2.4.RELEASE - should be out quite soon.
@marcingrzejszczak Thank you for this option! May I know when you want to make this a plugin parameter that can be set in pom?
AFAIR it's already there in 2.0.0.M7 milestone
So its only for 2.x and not for 1.x releases?
I want to do something like the following:
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
....
<configuration>
....
<stubRunnerSnapShotCheckSkip>true</stubRunnerSnapShotCheckSkip>
...
</configuration>
</plugin>
Update:
Thanks - I found "contractsSnapshotCheckSkip" in 2.0.0.M7 reference but is this available for 1.2.4 as well?
Yeah, the plugin entry is for 2.x. For 1.x (and 2.x too), you can set an env var on the machine, or pass the system property via e.g. surefire https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20.1</version>
<configuration>
<systemPropertyVariables>
<stubrunner.snapshot-check-skip>true</stubrunner.snapshot-check-skip>
[...]
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
[...]
</project>
Perfect! Thank you @marcingrzejszczak
Hey @marcingrzejszczak ,
<configuration>
<systemPropertyVariables>
<stubrunner.snapshot-check-skip>true</stubrunner.snapshot-check-skip>
[...]
</systemPropertyVariables>
</configuration>
Can you say when this fix is available for version 1.2.3?
Will this fix available before 2.0.0 release?
What Spring cloud version is needed to get the 2.0.0 milestones?
Thanks in advance 馃憤
Can you say when this fix is available for version 1.2.3?
Currently, there's no date - https://github.com/spring-cloud/spring-cloud-release/milestones . I guess we'll first do 2.0.0 GA and then the 1.2.3 one. But we'll have some internal discussions to maybe release SR3 before Finchley cc @spencergibb @ryanjbaxter @dsyer
Will this fix available before 2.0.0 release?
Answered above
What Spring cloud version is needed to get the 2.0.0 milestones?
Finchley.M8 should have it. In which case you can use the plugin property too.
Most helpful comment
Currently, there's no date - https://github.com/spring-cloud/spring-cloud-release/milestones . I guess we'll first do 2.0.0 GA and then the
1.2.3one. But we'll have some internal discussions to maybe releaseSR3before Finchley cc @spencergibb @ryanjbaxter @dsyerAnswered above
Finchley.M8should have it. In which case you can use the plugin property too.