[MRESOLVER-236] Make it possible to resolve .asc on a 'fail' <checksumPolicy/> respository.

[jira-importer]

Rod Widdowson opened MRESOLVER-236 and commented

(I'm guessing the resolver version - maven version is 3.8.4).

We accidently made one of our repositories <checksumPolicy>fail</checksumPolicy> some time ago and over the weekend an plugin we run started failing.

After some digging I discovered that the problem was when the code was programmatically trying to resolve a jar.asc file. Eventually the code ended up in

org.eclipse.aether.internal.impl.Maven2RepositoryLayoutFactory line 196

        public List<Checksum> getChecksums {
            if ( isSignature( artifact.getExtension() ) )
            {
                return Collections.emptyList();
            }

This means that when the resolution hit the correct repository it (silently) failed the checksum check and moved on to the next one, eventually falling off the end of the list and failing to resolve.

Our work around is to set the <checksumPolicy> to warn (which is what it used to be).

'It would be nice if'

• The failure was slightly less quiet
• If it was possible - programmatically or by configuration - to resolve signatures from checksuming repositories.

I have not dived very deeply into the code - just enough to diagnose why our CI was exploding so spectacularly so I may have missed some trick in which case I apologise for asking for existing function

---

Affects: 1.7.3

Issue Links:

• MRESOLVER-241 Resolver checksum calculation should be driven by layout
  ("is caused by")
• MRESOLVER-242 When no remote checksums provided by layout, transfer inevitably fails/warns
  ("is caused by")

Remote Links:

• GitHub Pull Request #159
  

0 votes, 6 watchers

[jira-importer]

Tamas Cservenak commented

This seems as a bug to me: for signature files (ext: asc) by default resolver should not enforce checksums (this is also configurable by static final String CONFIG_PROP_SIGNATURE_CHECKSUMS = "aether.checksums.forSignature"; that by default is false.
Rod Widdowson questions:

• is this a plugin on central or some private one?
• does the plugin have signature checksums published? (.asc.sha1 files). If yes, can you try using -Daether.checksums.forSignature=true on CLI?

[jira-importer]

Rod Widdowson commented

Tamas Cservenak I'm not completely sure that I understand what you are asking but let me try

Our plugin (the thing which tries to resolve asc files) isn't up on central. Source is here and the latest version is up on our snapshot repository

I just provoked the failure when looking at central (suitably configured to enforce checksums) when looking for spring-jdbc.jar which does not have a checksum.

setting {{-D aether.checksums.forSignature=true} makes no difference

[DEBUG] Resolving artifact org.springframework:spring-jdbc:jar.asc:5.3.14 from [shib-releases (https://build.shibboleth.net/maven/releases/, default, releases), shib-snapshots (https://build.shibboleth.net/maven/snapshots/, default, snapshots), shib-thirdparty (https://build.shibboleth.net/maven/thirdparty/, default, releases), shib-thirdparty-snapshots (https://build.shibboleth.net/maven/thirdparty-snapshots/, default, snapshots), shib-release (https://build.shibboleth.net/nexus/content/groups/public, default, releases), shib-snapshot (https://build.shibboleth.net/nexus/content/repositories/snapshots, default, snapshots), shib-thirdparty-snapshot (https://build.shibboleth.net/nexus/content/repositories/thirdparty-snapshots, default, snapshots), central (https://repo1.maven.org/maven2, default, releases)]
[DEBUG] Skipped remote request for org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this session
[DEBUG] Skipped remote request for org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this session
[DEBUG] Skipped remote request for org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this session
[DEBUG] Skipped remote request for org.springframework:spring-jdbc:jar.asc:5.3.14, already updated during this session

Note also that another project has programmed around it but I'd sooner avoid that kludge.

[jira-importer]

Tamas Cservenak commented

Reproducer: make sure demo snippets always operate with empty local repository (to make sure remote transport happens), alter highlighted line and run the demo snippet:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.7.3/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples/ResolveArtifact.java#L51

It fetches this:
https://repo.maven.apache.org/maven2/org/apache/maven/resolver/maven-resolver-util/1.3.3/

Variations (on artifact value):

• as-is "org.apache.maven.resolver:maven-resolver-util:1.3.3" -- passes OK (as expected, this is part of build tests)
• "org.apache.maven.resolver:maven-resolver-util:jar.sha1:1.3.3" -- fails*
• "org.apache.maven.resolver:maven-resolver-util:jar.asc:1.3.3" -- fails*

Explanation: the demo snippet WARNs about absence of checksums, but would fail if checksum policy is FAIL.

[jira-importer]

Tamas Cservenak commented

Fixed as Commited as 16b12f1

I wont close out this one yet, I'd like to add an "IT" (demo snippet that runs as part of build, kinda integration test) for this one.

[jira-importer]

Tamas Cservenak commented

merged demo as well as a3fa401

[jira-importer]

Slawomir Jaranowski commented

great - is it possibility to use it in Maven 3.x - do you have such plan?

[jira-importer]

Tamas Cservenak commented

The fix will be present in maven-resolver 1.8.0 (with many other nice features). Resolver since 1.7.x is Java8. AFAIR, we planned to up resolver in Maven 3.9.x, maybe even to 1.8.0 if resolver released in time, unsure.

[jira-importer]

Tamas Cservenak commented

This is becoming ridiculous. Since CI changes Jenkins is really lala. Here, the failure was

java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.aether.internal.test.util.TestFileUtils
at org.eclipse.aether.transport.file.FileTransporterTest.setUp(FileTransporterTest.java:77)

which smells like local repository is shared and JARs overwritten? I keep asking are jobs isolated properly or not...

[jira-importer]

Olivier Lamy commented

they are isolated as every job is using his own local repository
see https://github.com/apache/maven-jenkins-lib/blob/cb83da3826d940793902fd9964dd023133b4a4f5/vars/asfMavenTlpStdBuild.groovy#L112
with mavenLocalRepo:'.repository' the repository is related to the folder where the sources have been checkout.
sadly the stack trace doesn't give us much more details and especially about the file(s) causing problem
grhh why surefire has a default trimStackTrace true.
I will change Jenkins to run CI jobs with trimStackTrace false to get more trace