Thank you, Tamas! That did the trick. Thank you for detailed explanation of what is going on.
I simply added to maven.config -Daether.connector.smartChecksums=false And now it is doing exactly what I got when maven 3.8.x and before. I do have the checksums algorithms set as indicated and personally would love to remove the older ones but as noted everything would need there and in our platforms we still have some md5 even so I need all unfortunately. One day I'm sure that will change. Thanks for noting you will extend documentation, that will significantly help others I'm sure. At the moment, we are not actually doing anything with the checksums and I discovered it while researching separate issue few weeks back as we have a lot of network problems in general due to large scale / limited resources. Ultimately, we plan to start verifications and it was somewhat perplexing. For us, we are planning on jacking up the default retries from 3 to 10 on failed pulls due to varied network issues (as to my original issue) and seeing checksum issue concerned me if that would even work given same module and recent add of that logic to the resolver. Now I feel more confident. Looking forward to maven 3.9.2 otherwise when it lands. For my day job, we already have this scaled out on 2k repos at 3.9.1 and I've been doing same with maven wrapper across all OSS projects I work and will continue doing so. Loving the overall progress of maven! Thanks, Jeremy -----Original Message----- From: Tamás Cservenák <[email protected]> Sent: Saturday, April 22, 2023 5:03 AM To: Maven Developers List <[email protected]> Subject: Re: [HEADS UP] Maven 3.9.2 is around the corner Verified, and as I assumed: it works Jeremy, but there are other things that may end up in unexpected results. I tested locally, and "it works for me": $ mvn -s settings.xml dependency:resolve -Daether.checksums.algorithms=SHA-512,SHA-256,SHA-1,MD5 -Daether.connector.smartChecksums=false $ tree local/org/test/test/1.0 local/org/test/test/1.0 ├── _remote.repositories ├── test-1.0.pom ├── test-1.0.pom.sha512 ├── test-1.0.txt └── test-1.0.txt.sha512 So what I did is to explicitly DISABLE "smart checksums". And here is what happens in details when smart checksums not disabled: - ANY modern MRM (Artifactory, Nexus, etc, but same is true for Central) sends sha1/md5 in response headers - "smart checksums" hits BEFORE (when artifact response arrives) checksum is requested from remote - checksums are satisfied even BEFORE SHA-512 or SHA-256 would be asked for (as header contains SHA-1 that is enabled, and it matched) So what happens is that smart checksums from header matches, and resolver is satisfied with SHA-1 (or MD5) as those two are enabled => all ok Alternative would be to not enable SHA-1/MD5 that are delivered by majority of remote repositories and MRMs and consumed by "smart checksum": $ mvn -s settings.xml dependency:resolve -Daether.checksums.algorithms=SHA-512,SHA-256 But this requires that EVERYTHING, every artifact have SHA-512, SHA-256 available. Will extend this page https://maven.apache.org/resolver/about-checksums.html as things are getting more involved if you factor in "trusted" and "provided" checksums... HTH Tamas On Sat, Apr 22, 2023 at 8:26 AM Tamás Cservenák <[email protected]> wrote: > My assumption: have you tried SHA-256 with > aether.connector.smartChecksums disabled? > > T > > On Sat, Apr 22, 2023, 07:18 Tamás Cservenák <[email protected]> wrote: > >> Howdy, >> >> This sounds strange, will try to reproduce it. One remark though: >> checksum names as mentioned in doco are case sensitive... >> >> T >> >> On Fri, Apr 21, 2023, 23:47 Jeremy Landis <[email protected]> >> wrote: >> >>> Since maven 3.9.0, sha 256/512 checksums no longer are being pulled >>> if available and requested either through command line are or maven.config. >>> Has this been reported? Dropping back to maven 3.8.8 it works again. >>> >>> Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for >>> Android<https://na01.safelinks.protection.outlook.com/?url=https%3A%25 >>> 2F%2Faka.ms%2FAAb9ysg&data=05%7C01%7C%7C5b9826aee85e46efd5f508db4310 >>> 788f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638177510250427080 >>> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI >>> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BMLO%2FcAzRU9OpnLw%2 >>> BB7PqBbK8wNyDMkTY3zTStHJTgo%3D&reserved=0> >>> ________________________________ >>> From: Tamás Cservenák <[email protected]> >>> Sent: Friday, April 21, 2023 9:33:38 AM >>> To: Maven Developers List <[email protected]> >>> Subject: Re: [HEADS UP] Maven 3.9.2 is around the corner >>> >>> Howdy, >>> >>> There is one (IMHO) blocker bug reported for resolver 1.9.8 >>> >>> https://iss/ >>> ues.apache.org%2Fjira%2Fbrowse%2FMRESOLVER-352&data=05%7C01%7C%7C5b9 >>> 826aee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1 >>> %7C0%7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD >>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda >>> ta=8XDjUgs8LWeis9JOhgsc3MQMb3KCdI5VrGG8TZSeZKM%3D&reserved=0 >>> <https://is/ >>> sues.apache.org%2Fjira%2Fbrowse%2FMRESOLVER-352&data=05%7C01%7C%7C5b >>> 9826aee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C >>> 1%7C0%7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM >>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd >>> ata=8XDjUgs8LWeis9JOhgsc3MQMb3KCdI5VrGG8TZSeZKM%3D&reserved=0> >>> >>> That means Maven 3.9.2 needs to wait for bugfix release of resolver >>> (if nothing else crops up). >>> >>> Thanks >>> T >>> >>> On Mon, Apr 17, 2023 at 4:04 PM Tamás Cservenák >>> <[email protected]> >>> wrote: >>> >>> > Howdy, >>> > >>> > The 3.9.2 is nearly done: >>> > >>> > >>> https://iss/ >>> ues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520MNG% >>> 2520AND%2520fixVersion%2520%253D%25203.9.2&data=05%7C01%7C%7C5b9826a >>> ee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 >>> %7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC >>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h >>> siKQ%2Bk2DNOEojwIzOllZm%2BdQ4v0J4WAg9S%2FC84UKpM%3D&reserved=0 >>> < >>> https://iss/ >>> ues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520MNG% >>> 2520AND%2520fixVersion%2520%253D%25203.9.2&data=05%7C01%7C%7C5b9826a >>> ee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 >>> %7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC >>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h >>> siKQ%2Bk2DNOEojwIzOllZm%2BdQ4v0J4WAg9S%2FC84UKpM%3D&reserved=0 >>> > >>> > >>> > There are some candidates as well: >>> > >>> > >>> https://iss/ >>> ues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520MNG% >>> 2520AND%2520fixVersion%2520%253D%25203.9.x-candidate&data=05%7C01%7C >>> %7C5b9826aee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaa >>> aa%7C1%7C0%7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w >>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% >>> 7C&sdata=dIW7uNxluTqHRLlPhTGDMSRKGJ2ILFoBLEoOTd0EqUM%3D&reserved=0 >>> < >>> https://iss/ >>> ues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520MNG% >>> 2520AND%2520fixVersion%2520%253D%25203.9.x-candidate&data=05%7C01%7C >>> %7C5b9826aee85e46efd5f508db4310788f%7C84df9e7fe9f640afb435aaaaaaaaaa >>> aa%7C1%7C0%7C638177510250427080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w >>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% >>> 7C&sdata=dIW7uNxluTqHRLlPhTGDMSRKGJ2ILFoBLEoOTd0EqUM%3D&reserved=0 >>> > >>> > >>> > As usual, please raise your voice if there are some other issues >>> > not in these two sets above, or if you have a candidate that >>> > should be moved >>> to >>> > 3.9.2. >>> > >>> > Thanks >>> > T >>> > >>> >>
