Coursier: Support resolving dependecies in private S3 buckets

[gmendonca]

👋 I know this has been discussed before: https://github.com/coursier/coursier/issues/164

But shouldn't coursier be the one handling different types of protocols when resolving dependencies? I bumped in the same issue when trying out bazel in a scala project using bazel-deps which have coursier support.

Or do you think this is is a specific thing that should be supported through plugins to each build tool?

[alexarchambault]

It could be a good idea to add support for some kind of plugins, that the CLI could load to add support for s3:// or gcs://.

The CLI could accept arguments like

$ coursier resolve --plugin io.get-coursier::coursier-s3:2.X.Y org:name:ver

These plugin dependencies would be fetched upfront, loaded in a ClassLoader, and we would have to make that ClassLoader available around here, so that the plugin URLStreamHandlerFactory are used.

We would have to write the corresponding plugins too. There's an example of such a plugin already. And @ilisc2 managed to have gcs:// work I think, see https://github.com/coursier/coursier/issues/1399.

I can provide some more guidance if you (or anyone else) are interested in taking a cut at that.

That would solve the problem for the CLI (and would only be supported by the JVM CLI, not the GraalVM native image - because of the class loading / reflection stuff).

[pdsorensen]

We are currently working on a CLI that would use Coursiers bootstrap feature (among other things), but are also limited by not having the possibility to add s3 as a resolver.

Our quickfix is to add a proxy that can resolve it for us, i.e: cs fetch -r "http://localhost/" com.audienceproject:awesome-cli:1.0.2 and then hope Coursier adds support for it in the near future.

If you have any suggestions or need help @alexarchambault please give a shout. Cheers,