I want to register a custom url scheme with a plugin

basically this is like adding “s3” protocol to gradle via plugin. it is protocol which exposes rubygems.org repository as maven repository. the protocol works and I can set it up inside the plugin.

I added https://github.com/mkristian/jruby-gradle-plugin/blob/mavengem/jruby-gradle-base-plugin/src/main/resources/META-INF/services/org.gradle.internal.service.scopes.PluginServiceRegistry to the plugin and I am not sure if such a services can be registered on the fly like this via a plugin.

is this route possible ?

What’s the use case exactly? As I currently understand it, the jruby plugin works by serving up rubygems.org as a maven repo using a local HTTP server as a proxy. Are you trying to get away from this?

there are about three remote servers out there which maps rubygems.org to maven repo. currently it is possible to also let the plugin start its own server and cache things some metadata locally. the server is actually rather thin wrapper around the rubygems-servlet artifact but there are problems on how to share the local server between gradle subprojects, on travis we needed to stop the parallel builds since they produced errors with this servers. not sure about using the gradle daemon . . .

so the idea was to use custom protocol the protocol stream handler bascially consists of two files https://github.com/jruby-gradle/jruby-gradle-plugin/pull/241/files#diff-6def2d6863bc88b2e4dfccafa48e213aR1 since the rubygems-servlets is just a similar “wrapper” around the same library doing the work.

if this works then there is no need for starting jetty, etc and most problems we are seeing are probably gone as well.

There are a number of use cases for this. Besides the JRuby-gradle case, there is also an argument of registering additional protocols, wihtout shipping them by default with Gradle. SMB is one that springs to mind. There are organisations that springs to my mind, where that could be useful. Also besides S3, there are other blob storage providers that might become useful in future. Yet putting support for all of those in core Gradle would be silly, as most people would not need them.

The ability to registers custom protocols is definitely useful IMO.

Looking at the current Gradle code, this brings up a key question for me. An implementation of PluginServiceRegistry must be invoked by Gradle at some point during initialisation. If I would for example, have a MyNewProtocolRegistryPlugin, then it should be on some classpath for Gradle to recognise. Which classpath is the key question.

Is it good enough to have it on buildscript { dependencies { classpath '' } } } or is that too late?

What about adding it to a initscript {} block, or is that too late as well?

Or … Is there a way to tell Gradle to search the classpath again for new protocols?