How do I convince plugins to be fetched in full fr...
# community-support
d
How do I convince plugins to be fetched in full from somewhere other than the gradle plugin repo? I've tried adding the repo in pluginManagement { } in settings.gradle.kts without any luck, both as mavenCentral() as well as manual maven("https://repo1.maven.org/maven2/") but yet it fails to fetch the asc, that is obviously there, https://repo1.maven.org/maven2/org/flywaydb/flyway-gradle-plugin/10.15.2/ ... what might I be missing?
Also have this for gradle plugin portal based on previous attempts,
Copy code
maven("<https://plugins.gradle.org/m2/>") {
	metadataSources {
		mavenPom()
		ignoreGradleMetadataRedirection()
	}
}
So pluginManagement in full:
Copy code
pluginManagement {
	repositories {
		mavenCentral()
		maven("<https://plugins.gradle.org/m2/>") {
			metadataSources {
				mavenPom()
				ignoreGradleMetadataRedirection()
			}
		}
	}
}
And output:
Copy code
Error resolving plugin [id: 'org.flywaydb.flyway', version: '10.15.2']
> Dependency verification failed for configuration 'detachedConfiguration1':
    - On artifact org.flywaydb.flyway.gradle.plugin-10.15.2.pom (org.flywaydb.flyway:org.flywaydb.flyway.gradle.plugin:10.15.2) in repository 'maven': checksum is missing from verification metadata.
So the
maven
part there in the output seems to hint that it comes from the right place, as when I had
maven("<https://repo1.maven.org/maven2/>")
in there that output said
maven2
yet no .asc downloaded as with other stuff in ~/.gradle/cache
If I check spotless plugin for example I find:
Copy code
caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/cb611567da4a72dbea2ba4af138ea3de50b57dac:
.rw-r--r--@ 650 daniel  5 Jul 17:23  spotless-plugin-gradle-6.25.0.module.asc

caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/ebd0cefde974032b71b9a16b7adfb41b582fe1da:
.rw-r--r--@ 650 daniel  5 Jul 17:23  spotless-plugin-gradle-6.25.0.jar.asc
So seems like it can fetch signatures for plugins, but for some reason doesn't in this case.
v
I don't use verification, but from the message I'd say it is not having problems to download the asc, but in your local verification metadata there is no checksum for that dependency.
d
There is no .asc file downloaded for flyway, and I don't persist checksums as that would be annoying. It's a relaxed choice, but signatures is better than nothing.
Copy code
find . -name '*flyway*'
./caches/modules-2/metadata-2.106/descriptors/org.flywaydb.flyway
./caches/modules-2/metadata-2.106/descriptors/org.flywaydb.flyway/org.flywaydb.flyway.gradle.plugin
./caches/modules-2/files-2.1/org.flywaydb.flyway
./caches/modules-2/files-2.1/org.flywaydb.flyway/org.flywaydb.flyway.gradle.plugin
./caches/modules-2/files-2.1/org.flywaydb.flyway/org.flywaydb.flyway.gradle.plugin/10.15.2/802dfee3aef6ec86ec0b6430ff176f194c85356f/org.flywaydb.flyway.gradle.plugin-10.15.2.pom
Copy code
find . -name '*spotless*gradle*'
./caches/modules-2/metadata-2.106/descriptors/com.diffplug.spotless/spotless-plugin-gradle
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/b3ecf46486431f7c640c36473eec47d4b5f84948/spotless-plugin-gradle-6.25.0.module
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/cb611567da4a72dbea2ba4af138ea3de50b57dac/spotless-plugin-gradle-6.25.0.module.asc
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/fa0a659760fac2bb6ed257da917fe06658f195a4/spotless-plugin-gradle-6.25.0.pom
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/837bfb4f743a2994c2b8d19872b4bd02fc2fe2b4/spotless-plugin-gradle-6.25.0.jar
./caches/modules-2/files-2.1/com.diffplug.spotless/spotless-plugin-gradle/6.25.0/ebd0cefde974032b71b9a16b7adfb41b582fe1da/spotless-plugin-gradle-6.25.0.jar.asc
./caches/transforms-4/b8eb501f0f9d424875c19b06a6eeebe9/transformed/spotless-plugin-gradle-6_25_0_jar-snapshot.bin
./caches/transforms-4/3a65d5973876a59e14f345c45a274a2b/transformed/instrumented/instrumented-spotless-plugin-gradle-6.25.0.jar
v
Again, it is not complaining about the asc, but that you have dependency verification enabled but do not have the checksum in your local dependency verification metadata
d
For the flyway library that the application uses, there's a .asc downloaded though, and it's correctly used for validation. Just the gradle plugin that's not being verified.
v
Btw. you should usually not disable GMM redirect. There could for example be different plugin variants for different Gradle versions and thus could then not be resolved properly
Can you maybe knit an MCVE that demonstrates your problem?
d
It's just a matter of enabling dependency verification, and not adding a checksum entry to the metadata. Would take longer for someone to checkout the code than to write it other their own.
🤷‍♂️ 1
So as for not having checksums there. I don't want to have checksums there, and that's true for most other deps of the project as long as they have signatures, I rely on signatures alone. There's no marking of a specific dep to say that it should or should not have a checksum. Checksum is verified if it exists, and as long as a key exists that's used.
So if I add a dependency with a key, and don't have the key in the ring, gradle will complain that it can't resolve the key. I add it to the keyring after checking if it can be trusted, and associate it with the group/name in the metadata.xml file and everything is fine. But in the case of flyway, the signature is simply not fetched.
So the checksum complaint in the gradle output I expect comes from the fact that it doesn't fetch the asc, as otherwise that would be a common thing to see, except it's not. Because if the asc is fetched and the key is not found you would instead get output like this:
Copy code
> Dependency verification failed for configuration ':detachedConfiguration1':
    - On artifact java-dogstatsd-client-4.4.2.pom (com.datadoghq:java-dogstatsd-client:4.4.2) in repository 'MavenRepo': Artifact was signed with key '090D938D2819E5CD' but it wasn't found in any key server so it couldn't be verified
@Vampire you follow?
@Vampire as for your "Btw. you should usually not disable GMM redirect" recommendation. That's needed for many other plugins to fetch the asc from the right place. If I disable that, then jooq, jib, sonar gradle plugins etc no longer finds .asc.
Humm... but maybe that just means that the pom have different checksum in those cases... and that if those are refreshed it will get to flyway, and perhaps that'll work. Worth a try. The ignoring metadat was from the jcenter debacle. jooq, sonar etc are not signed.
v
As I said, I did not use verification yet. But as far as I understood it, you have to have the checksum in the verification metadata. And if you need to disable GMM redirection for it to work, I'd tend to say there is a bug somewhere.
d
Nopes, that wasn't it either. Removing the ignore GMM resulted in .modules fetched, which was not checksummed before and that's the reason it complained on jooq, sonar etc when I removed that. It did not result in fetching the signature for flyway .. only adding it to checksum section with "Artifact is not signed" comment, which is a sign that it looks for the plugin in the wrong repo fwict.
I don't think ignore GMM needs to be in the build setup any longer as the jcenter() crap is behind us, removing it only results in an extra entry per unsigned dep in the verification-metadat.xml file so that's fine, not more effort to manage than it already is. But it's odd that the flyway plugin signatures are not fetched when they're obviously in the repo😕