@witty-crayon-22786: thanks, I'll check it out

@witty-crayon-22786: There are some examples in the pydocs of ManagedJarLibraries

(Which should show up in the build dict)?

And then just miscellaneous pydocs in managed_jar_dependencies.py and jar_dependency_management.py

@jolly-chef-92794: doesn't seem to... http://pantsbuild.github.io/build_dictionary.html

Hmm, the build dictionary is only including the first line or so?

would be good to move some of that to http://pantsbuild.github.io/3rdparty_jvm.html

of the description for a target, yea

It’s probably missing a lot of stuff elsewhere too then

...no terribly good reason not to include more, aside from the issue of formatting

Like, all the examples of how to do shading

Yeah, looks like all the examples in the shading_* rules aren’t displayed either

I’m OK not having that information displayed there, but there are some valuable docs there that should live somewhere

yes.

it's never been the case that that info has been displayed on the site

It was definitely there before we did the expandy arrows >

I distinctly remember paying close attention to it when I was writing the shading rules

hm

for the fun of learning build systems. would someone like to explain why it's desirable to have one ivy resolution for all targets (included in a ::) instead of per-target?

@jolly-chef-92794: apologies.

For one, it causes excessive cache invalidation

@gentle-potato-32845: Partly it’s a performance thing. Shelling out to ivy once per target would be expensive.

also, each resolve may have differing version picking decisions

(Oh I misunderstood, I thought you were discussing whether to pin deps for an entire repo)

so a graph like A -> B, A -> C. There may be a jar that resolves to a different version for each of A, B and C when they are resolved independently

(not good, I know, but …)

Also, we use those jar versions as part of the compile fingerprint.

@gentle-potato-32845: the answer is: it's not super desirable. what you want is per-binary or per-test resolves

...which is what Square is getting close to via pinning binaries with

managed_jar_libraries

, and what twitter is headed toward via another path

At Square we’re realizing that we may be needing more than just managed_jar_libraries, or something augmenting it. Because the transitive jar dependencies get included in the fingerprint of every java library, you can have two builds that are 99% the same, but with one different version of a transitively resolved external jar, and have the whole thing invalidated. I spent all last week tracking down why certain builds (eg, running tests, then building a binary afterward) would rebuild tons of common libraries that hadn’t changed.