happy to pull down an rc tag to test in the meantime as well

thanks for the help all!

@wonderful-yak-59945 You can run

pants_from_sources

against the 2.10.x branch if you like

the CP is there now

Thanks for finding us a weirdness!

always happy to find weirdness!

We're interested in getting more insight into which of your biggest pain points Pants has had the greatest impact on for you. What were you experiencing the most pain on before? How did Pants make a difference? Thanks for helping us learn more about where our team's efforts have been most meaningful for your team!

you can also consume the SHA via https://www.pantsbuild.org/v2.10/docs/installation#running-pants-from-unreleased-builds once the branch finishes building

with sha

781bb1bad0916eb33d3a2998675ee9e563aa4f10

… which appears to be available now, actually.

ah so! under the fix I still seem to be running into the same issue if I have more than just the

<https://repo.osgeo.org/repository/release>

repo listed in our coursier config. seems like the "coursier eagerly choosing a bad pom from repo1.maven.org" problem persists if that repo is specified in the pants config

but if I remove those from our config and only specify the osgeo repo, the

--no-default

patch looks to do its job and pants can download and cache the jar (and subsequent resolves consume that just fine when the other repos are added back)

huh, with that osgeo repo ahead of the maven repo in the config?

I think order matters

seems like it?

the coursier command does have osgeo first but apparently still didn't choose it? ¯\_(ツ)_/¯

I'm at least unblocked having the resolve now cached though

That's good, sorry for the trouble though, we'll figure this out.

all good!

If it were the Pikachu jar, then Coursier probably would have worked. (Because “Pikachu! I (Coursier) choose you!“)

lol

I've missed the bad puns

Hmm, so if I run that coursier command outside Pants:

cs  fetch -r=<https://repo.osgeo.org/repository/release> -r=<https://maven-central.storage-download.googleapis.com/maven2> -r=<https://repo1.maven.org/maven2> --no-default --json-output-file=coursier_report.json org.geotools:gt-main:9.2 com.google.geometry:s2-geometry:2.0.0 com.twitter:util-logging_2.11:20.1.0 org.mongodb:bson:3.11.2 joda-time:joda-time:2.10.3 com.fasterxml.jackson.core:jackson-core:2.6.7 com.twitter:util-core_2.11:20.1.0 com.fasterxml.jackson.core:jackson-databind:2.6.7 com.vividsolutions:jts:1.12 com.fasterxml.jackson.module:jackson-module-scala_2.11:2.6.7.1 org.apache.thrift:libthrift:0.9.0 org.codehaus.jackson:jackson-core-asl:1.9.8

It works fine.

So now I'm wondering if there's a race of some kind and order of repos doesn't actually matter

Or, possibly the problem was that the pom was cached via the maven central location, so coursier still expected the jar to come from there too.

@ancient-vegetable-10556 where does Pants place the coursier download cache, is it ~/.cache/pants/coursier?

@wonderful-yak-59945 maybe try temporarily moving that dir (once Chris confirms it as the cache location) and see if re-resolving without cache works?

~/.cache/pants/named_caches/coursier/

maybe?

trying that

hm still generates the

"file":null

json and breaks the post processing script

I am gonna call it for the night but happy to poke more tomorrow