Fixed as described

This was a disaster. It turns out that mvn dependency:get has a couple of dependencies which are not in that repo. I found the key for one of the plugins in the keying for org.apache.maven.shared and slammed it in to the keyring for org.apache.maven.plugin but the other isn’t available in a pre-trusted form (its for a 11 year old version of maven-antrun-plugin.

We cannot “just blindly trust” that key (things have moved on) and anyway there is also the bit about “always relying on the old version”. So I think that the answer is to grab the pom as well as the jar inside the enforcer.

This will do the trick, but it sort of relies on us always using the latest version.

I’ll think about it. On one hand one doesn’t clutter up the pom with irrelevances, on the other it might fail in a weird way

Ah, hoisted by ones own petard. The whole thing about the enforcer data is that it isnt a dependency. So it doesn’t get onto the classpath so people cannot smuggle fake keyrings in.

But because it isn’t a dependency when we resolve the jar file we only resolve the jar file. Not the pom file. So when the M2 discovers the jar file it looks for the pom file of the same name in the same directory. But it aint there - because we didn’t need it.
I think that the solution is to add this to the pom file of the dist project

It might be nicer to do this on the command line (mvn dependency:get -DartifactId=maven-dist-enforcer-data -DgroupId=net.shibboleth.maven.enforcer.rules -Dversion=1.0.0-SNAPSHOT ) but that would separate the coordinates of the data into twi places (plus it doesn’t work).

I’ll poke at this over the Holidays when Jenkins is quiet.

Supressed M2 checking in the idp-nightly build while I look at this.