[13:27:31] o/ [13:37:15] MacOS security update...depending on how it takes I could be late to pairing in ~20m [13:59:02] back [15:49:56] quick break, back in ~20 [16:31:37] back [16:50:42] taking 1h break [17:06:56] lunch, back in ~1h [17:59:28] back [18:26:19] not particularly important, but I noticed we have some host-specific hiera files for hosts that don't exist anymore (like cloudelastic1001) in the puppet repo. probably should get rid of those [19:10:37] having odd maven problem: Could not resolve dependencies for project org.wikimedia.discovery.cirrus.updater:cirrus-streaming-updater-consumer:jar:0.1.0-SNAPSHOT: Could not find artifact org.wikimedia.discovery.cirrus.updater:common:jar:tests:0.1.0-SNAPSHOT in pfischer (https://people.wikimedia.org/~pfischer/maven/) [19:10:51] i can't see why it's trying to source common from people [19:13:56] Do you have an entry in your settings.xml ? Or a repository entry in your pom.xml ? [19:14:46] the people.wikimedia.org is part of the consumer pom.xml, but it should only be used to source the elasticsearch connector (which iiuc will be replaced soon) [19:15:16] i did find duplicate sections for the test-jar, but removing them didn't change anything. hmm [19:15:35] Do you do a full build? Or just one of the modules? [19:16:10] this is `./mvnw -U clean spotbugs:check`, with a java-11 openjdk [19:16:11] We should upload that jar to Archiva instead of people.wm.o [19:17:25] You might want to try a mvn install first. Some of the goals don't properly support reactor build (multi modules) and try to fetch other modules from the same project from remote repos. I never entirely understood why. [19:17:41] oh! i guess that would make sense. lemme try a full build [19:17:53] i always disliked install...it seems like it opens opportunity to use mismatched versions [19:18:18] Mvn install will put all the artifacts in your local repo, where they are easier to find. Once they are there, you could run just the spotbugs goal again and it might work. [19:18:33] sure, but then when i run spotbugs tomorrow it will use yesterdays files intead of whats in the repo? [19:18:35] Yeah, exactly about the mismatched versions. [19:18:49] Yeah, it might do strange things! [19:20:29] it takes awhile to build :P [19:20:56] https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html might be useful to clean up regularly [19:22:02] I never understood if that issue is maven itself, or some plugins doing non standard things [19:22:21] looks like it does indeed work if i do a full `./mvnw clean package`, perhaps spoiled by some of the actions like spotless:apply that just work [19:23:30] Does spotless only look at the source? In which case, it does not need the dependency [19:23:43] yea, its a formatter. Reasonable chance it doesn't look at what things really are [19:23:54] Spotbugs goes deeper in the analysis and needs more stuff. [19:24:39] I suspect that spotbugs does not depend explicitly on compile, so if you do only clean spotbugs:check, it is missing a bunch of stuff. [19:24:56] that seems sensible [19:25:45] Btw, mvn -T 1C might spin more threads and be a bit faster [19:26:37] https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=18153538#content/view/18153538 [19:31:00] ebernhardson: you can also run spotbugs from intellij, which takes care of the dependencies. Not sure if it reads the config from the pom.xml [19:32:59] hmm, i'll check that. might be easier. Mostly i'm just trying to recreate the CI errors without waiting so long :) [19:44:56] -DskipTests might also help! [19:57:33] ebernhardson: I just checked, `./mvnw -T 1C compile spotbugs:check` should work and only runs the minimal amount of stuff to get spotbugs working. Much faster than `./mvnw clean verify`