Support Ivy 2.3.0-final.

[willb]

This entailed modifying ResolutionCache and the CustomPomParser
to reflect changes to the ResolutionCacheManager interface and
DefaultExtendsDescriptor class between Ivy 2.3.0-rc1 and
2.3.0-rc2. Specifically,

1. ResolutionCacheManager now includes two additional methods
   that needed implementations in ResolutionCache:
   getResolvedModuleDescriptor(mrid: ModuleRevisionId) and
   saveResolvedModuleDescriptor(md: ModuleDescriptor). I adapted
   the implementations for these (which are expressed primarily in
   terms of other interface methods) from Ivy 2.3.0's
   DefaultResolutionCacheManager.
2. Instead of taking a ModuleRevisionIdentifier and a resolved
   ModuleRevisionIdentifier as its first two arguments, the
   DefaultExtendsDescriptor constructor now takes a
   ModuleDescriptor.

Note that ResolutionCache.getResolvedModuleDescriptor does not
appear to be used by Ivy as sbt uses Ivy and there is thus no
test coverage for its implementation. Also note that the
DefaultResolutionCacheManager object created in
Update.configureResolutionCache now requires a reference to an
IvySettings object; DRCM expects this to be non-null.

[harrah]

LGTM, thank you!

I had previously thought this should go into 0.14 due to the risk of binary incompatible changes. It looks like the sbt side is ok, but I don't know about Ivy itself. Problems would occur if a) Ivy has some incompatibilities and b) a plugin uses Ivy directly and is affected by them.

@jsuereth @eed3si9n (and anyone watching #847) any thoughts?

As a follow up commit, perhaps do a similar doc refresh as was done in xuwei-k@d5d4d83 ?

[jsuereth]

Wow nice! I think we may need to push a milestone of 0.13.2 with this and get teh community/plugins to experiment and see what happens....

Still, Really looking forward to reviewing this.

[eed3si9n]

There's no signature changes to public classes or methods, right?
I can't speak for all the plugins, but I personally can't think of any situation I had to drive Ivy directly.

A minor point but the code seems to be using whitespace as opposed to tab. (I wish this was automated)

[jsuereth]

There's only one using internal Ivy I know of - sbt-license-report. IT's fine to break it though, I own that one.

[harrah]

@eed3si9n No signature changes to sbt side. I don't know about Ivy.

@jsuereth That means that sbt-license-report users have to know to bump the sbt-license-report version if they go to 0.13.2, though.

[eed3si9n]

There's like one project using sbt-license-report on github, and it's activator. Not saying it's not widely popular among the closed source community, but still.

[harrah]

@eed3si9n Compatibility changes need to take into account plugins that we may not know about. In this case it is indeed @jsuereth's plugin used at Typesafe, but that actually makes it less problematic as he indicates. I don't have a strong opinion either way, but if there are real plugins using Ivy directly that would be affected, we should consider them. From the diff, it looks like a rather central class in Ivy was changed. However, perhaps no one constructs it and they only consume it.

I agree we should publish a milestone and get people to try it out. Plugins may use Ivy, but it may be that they aren't generally affected.

[harrah]

So, I guess that means I'll merge to the 0.13 branch.

[harrah]

Sorry, I didn't realize this targeted 0.13.1, which has been released as final. Can you target the 0.13 branch instead?

[willb]

Sorry about that. I've rebased my patches atop 0.13 and force-updated my branch. I re-ran the test suite as a sanity check and everything still passes.

[harrah]

No problem, thanks for the quick response. Merged to 0.13 in 5df24e5.