I'm explicitly specifying the Artifact details here instead using methods on PomModuleDescriptorBuilder (which I was doing in a previous attempt) because that sets the type to "source" and "javadoc" which makes it look artifacts at

~/.ivy2/cache/com.dwijnand/sbt-gh1750-bippy_2.11/sources/sbt-gh1750-bippy_2.11-0.1.0-SNAPSHOT-sources.jar
~/.ivy2/cache/com.dwijnand/sbt-gh1750-bippy_2.11/javadocs/sbt-gh1750-bippy_2.11-0.1.0-SNAPSHOT-javadoc.jar

rather than

~/.ivy2/cache/com.dwijnand/sbt-gh1750-bippy_2.11/srcs/sbt-gh1750-bippy_2.11-0.1.0-SNAPSHOT-sources.jar
~/.ivy2/cache/com.dwijnand/sbt-gh1750-bippy_2.11/docs/sbt-gh1750-bippy_2.11-0.1.0-SNAPSHOT-javadoc.jar

given the ivy/artifact pattern

(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[organisation]/[module](/[branch])/[type]s/[artifact]-[revision](-[classifier])(.[ext])

I then found this correspondence map in sbt, so decided to just define the types here as "src" and "doc" instead. Let me know if I should fix this some other way..

a really good question. I think the differences represent something we'll want to clean-up/unify. It may be a good idea to move that correspondence map onto this side and then use it in sbt, so we can correct those issues as needed.

Do you know who owns those magic strings? Who likes "source" and who prefers "src"?

AFAIK it's an sbt's understanding of ivy when code was first written vs. ivy thing. I believe it's trouble all of our brewing, however it is ALSO the case that inside of maven repositories "-src" vs. "-sources" is a thing and you need to support both, depending on which project is pushing the sources.

Ok, so not to be annoying, BUT...

1. This implies we have the performance overrides in this project, which we may actually want to do.
2. IIRC there's an open ticket and PR to disable downloading source/javadoc to the Ivy main REPO, so we're not out of line just putting all that functionality in here.

I'd prefer if we have ONE of the hackeries in this repo that we just keep them BOTH together so they can reference each other.

Also, option #2 would be to actually modify this behavior so it's a FLAG to the default cache manager, one which sbt can set when constructing Ivy, rather than having it ALWAYS be the case here.

(Do you mean apache/ant-ivy#6 ?)

Do you have a preference on which change to make? I'm not sure which I prefer so I'll go with what you prefer.

Are the options mutually exclusive? Can we merge apache/ant-ivy#6 and also use the same flag here?

That PR is the + or - the equivalent of https://github.com/sbt/sbt/blob/v0.13.9/ivy/src/main/scala/sbt/ivyint/SbtChainResolver.scala#L67 (or at least with regards to the use case I've been looking at).

So if we merged that we would then have to programmatically enable that setting in sbt.

Despite there being two sbt-driven changes here, which together interact, their primary nature is different:

1. Don't always look for srcs/docs from remote you maniac
2. If we have a new descriptor then, in an effort to have a clean shop, let's always delete srcs/docs locally.

Given I'm not 100% that that PR would allow sbt to drop it's fail-fast, I'm leaning towards a "alwaysDeleteSrcsDocs" flag on DefaultRepositoryCacheManager provided sbt has access to enabling it somehow.

Or we could follow the lead on of that PR and set it in ivySettings.

Yeah, let's put it into ivySettings, and I guess I'd be ok with it always on for sbt no matter what.

Thanks Josh, will do.