Plugin Service Registration

Help/Discuss
1

Hi,

I am building a plugin and I would like to register some services for it but so far I have been unable to achieve this. From what I’ve see in Gradle’s source code (e.g. PublishServices, to register services we need to:

  1. Create a class that extends a org.gradle.internal.service.scopes.AbstractPluginServiceRegistry (or implements PluginServiceRegistry?)
  2. Override any of the service registry methods adding our defined providers
  3. Add a file in src/main/resources/META-INF/services/ with the name of the interface
    org.gradle.internal.service.scopes.PluginServiceRegistry and add the name of the our class (e.g. my.company.MyClassPluginServiceRegistry)

Am I missing any steps? Do I have to activate it or register it when the plugin is activated? How do I know if it has indeed been activated? I have added some logs in the registry methods’ body but I haven’t seen them appear anywhere…

2

Only Gradle core plugins can register services.

What kind of services would you like to register for your use case?

3

Well I want to manage a model* registry accessible to any gradle plugins that wish to extend or build up on the one I am working on.

In addition I was planning to extend the gradle Input types to include an InputModel type (for my domain). I was planning to implement the PropertyAnnotationHandler and the PropertyMetadataStore interfaces which are registered in the GlobalScopeServices. I figured that registering services was the way to go.

4

None of the above are user-extensible.

If you tell me a bit more about what you had in mind for your plugin (e.g. some example DSL and use cases), I’m sure I can point you in the right direction.

5

Hi Stefan, sorry for the late reply. I still need more thinking to give you a proper answer but for the time being you could help me with the following:

  • In the context of the java-gradle plugin I am developing, how can compute values before a the @TaskAction method is executed which alter the tasks inputs. For example, I have a task that generates code from a code generator script declared as input to the task. The code generator script might have dependencies to other files and I need to parse the script to figure out this and add the dependencies as task inputs at runtime. How do I deal with this?

  • What if instead of declaring a file is outdated based on a checksum I want to say is outdated based on a timestamp. How do I declare different checks for the up-to-dateness of an input source?

6

You would have a getter annotated with @InputFiles and compute the actual set of files in there.

I’d strongly discourage that, as it defeats any kind of correctness guarantee and may leave your users frustrated with wrong results. If you really wanted this then instead of using @InputFiles, you’d have a getter returning a List<Long> (the timestamps of the files), annotated with @Input

7

Thanks! Makes sense. I have tried this and works perfectly.

This is a good idea as well. Thanks!

I understand this would be problematic for the user if it was hardcoded in the plugin though I guess for some scenarios it might be useful. To deal with the this I was thinking on providing some sort of up-to-date validation task/extension that the code generation task needs to call and determine its validity based on the user-selected up-to-date criteria selected by the user.

I am thinking of a case where instead of changes in a file we need to poll for changes on a database based on a specific query or a global property that determines the database has been updated. It is not straight forward how to determine that it has been updated therefore we need more flexibility at the user’s discretion to define out-dated checks/stamps relevant for their workflow.