So this PR is the result of me going down a giant rabbit hole. The original improvement I was trying to do is replacing the usage of IvySbt#Module because I was experiencing https://github.com/sbt/sbt/issues/3618 and the workaround at https://github.com/sbt/sbt/issues/3618#issuecomment-424924293 for some reason didn't work (I guess sys.props was not being passed to sbt plugins due to classloader isolation???).
So after wasting a stupid amount of time figuring out if I could somehow pass the packaging.type manually into Ivy, I just figured why not just entirely replace IvySbt#Module with sbt's update task, that way we can also benefit from Coursier's faster dependency resolution (little tidbit, but sbt-license-report can end up taking ages in some cases due to Ivy)? Then this is where the rabbit hole began, I ended up hitting https://github.com/coursier/coursier/issues/1790 (tl;dr version, Coursier doesn't properly grab the license information when using IvySbt#Module as a module). IvySbt#Module also needs to be used because certain dependencies don't hold the license info in pom.xml (see https://discord.com/channels/632150470000902164/922600050989875282/1151492070373085306).
So rather than using update I instead opted for IvyDependencyResolver. While it doesn't go the full way of just using update to get all of the dependencies and their respective licenses, the data structures returned by both DependencyResolution.update and sbt's update task are the same (i.e. UpdateReport) so once that coursier issue is solved a future PR to use update will be trivial.
The PR also drops support for SBT 0.13.x because its ancient and DependencyResolution doesn't exist there.
So this PR is the result of me going down a giant rabbit hole. The original improvement I was trying to do is replacing the usage of
IvySbt#Modulebecause I was experiencing https://github.com/sbt/sbt/issues/3618 and the workaround at https://github.com/sbt/sbt/issues/3618#issuecomment-424924293 for some reason didn't work (I guesssys.propswas not being passed to sbt plugins due to classloader isolation???).So after wasting a stupid amount of time figuring out if I could somehow pass the
packaging.typemanually into Ivy, I just figured why not just entirely replaceIvySbt#Modulewith sbt'supdatetask, that way we can also benefit from Coursier's faster dependency resolution (little tidbit, but sbt-license-report can end up taking ages in some cases due to Ivy)? Then this is where the rabbit hole began, I ended up hitting https://github.com/coursier/coursier/issues/1790 (tl;dr version, Coursier doesn't properly grab the license information when usingIvySbt#Moduleas a module).IvySbt#Modulealso needs to be used because certain dependencies don't hold the license info inpom.xml(see https://discord.com/channels/632150470000902164/922600050989875282/1151492070373085306).So rather than using
updateI instead opted forIvyDependencyResolver. While it doesn't go the full way of just usingupdateto get all of the dependencies and their respective licenses, the data structures returned by bothDependencyResolution.updateand sbt'supdatetask are the same (i.e.UpdateReport) so once that coursier issue is solved a future PR to useupdatewill be trivial.The PR also drops support for SBT 0.13.x because its ancient and
DependencyResolutiondoesn't exist there.