META-INF/services generation

Old Forum
1

It’s clear: eclipse / jar should support service - provider definitions, like Ant does.

2

I have no clue what you are proposing. Can you elaborate?

3

Of course. If you want to use http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html and you deploy your app in a JAR, you have two options. 1) you use ant, you don’t have to create src/main/resources/META-INF/services by hand, because you can just:

http://pastebin.com/UMtfZZ4A

So ant will generate this file into your JAR in the proper place, and thus this service provider can be invoked. 2) you use gradle, you have to create src/main/resources/META-INF/services by hand, and maintin it in the repository source tree. I hope I clarified myself. It would be nice to extend the jar task with this functionality, so this config file can be deleted and its generation can be managed with gradle.

4

This would be a nice community contribution.

5

I’ve barely used Ant so correct me if i’m wrong but in the code you linked to it seems you have to hardcode which services you have in the buildscript? It would be nice if we could make it a bit more dynamic?

We could have some annotation that specifies them like ‘@ServiceProvider(‘a.service.here’)’ and then use annotation processing during the compilation to build the service file?

6

Using annotation provided by gradle in production code sounds weird to me. Hardcoding in the build script is fine for my case.

By the way, I created src/main/resources/META-INF/services/javax.annotation.processing.Processor and its implementation for the project’s own use, but it does not seem to work. My guess is because compileJava does not take care of resource sourceSet. addStringOption does not work either.

What is the best way to define and use service from same project?

7

I think binding the build script to the application (defining the service in build.gradle) is far better than binding the production code to the build script (using gradle annotations in the production code).

8

If I have a little time, can’t promise it, but I’ll send a patch that will do the job in the Ant style.

9

Hmm…not sure I see the difference with maintaining the services file or the ant build file for hand. You still have to remember to put a new service provider into either file.

10

This should really be an apt plugin that has nothing to do with gradle. Just include it in the classpath and for each compile the file would be updated with @ServiceProvider(…) classes.

11

Can be hard to get the Processor to run on its own project. Make another module with the Processor instead.

12

Yeah, I thought a bit more about it and you’re right. I just don’t like having it in the build script but I wound up putting a static file in src/main/resources/META-INF/services (as previously mentioned) which works equally well for me.

13

Hello,

Please see here:

http://fgaliegue.blogspot.fr/2013/06/gradle-serviceloader-support.html

This is code I have written with not even a week in gradle/groovy experience but which works nicely.

And sorry for digging up such an old thread…