I need to add a module packaging some resources, but no code


(Dimitar Dimitrov) #1

We are having a few modules which consist only of resources (i.e. shared configurations). Right now we are treating them as Java projects, so we can get the resource packaging and publishing, but ideally we would like not to get all the compile and testing tasks, as our build is currently structured to add bells and whistles based on the applied plugins and tasks in a module.

Given that the configurations and source sets concepts are defined in the base language plugin, is there a way we can use them directly, without applying the Java plugin? Also, these seem pretty fundamental and many plugins depend on them - is there any thought of adding them to the core?


(Luke Daley) #2

What exactly do you need from that infrastructure?

You could just use Copy tasks.


(Dimitar Dimitrov) #3

I need the resources to end up on the classpath. As I said, I am currently using the Java plugin, but it just feels wrong, as there are no a java sources to speak of…


(Luke Daley) #4

the classpath of what exactly?


(Dimitar Dimitrov) #5

The classpath of testRuntime configuration of another module. I guess I should explain in more detail:

Our source tree contains a bunch of configuration files with ${placeholders} which we use as templates to generate fully resolved prod configs for multiple environments. We also use the same set of files in our integration testing.

Our integration testing harness loads the files through the classloader, so we do not have to manage filesystem layout, etc. (hence “resources”). We use the same set of resources to test multiple components.

Right now the configuration files/resources reside under the /src/main/resources directory of a module named “configs”, to which we apply the “java” plugin. The “configs” module does not contain Java sources, so all Java-specific tasks are empty.

After the projects are configured, we have a hook that based on the plugins applied to a project would “enhance”, it with extra reports, include it in distributions, etc. This is where we have to manually exclude the “configs” module, as it is not a proper Java module. In particular, its output is not an executable Jar, its test task will not produce reports, etc.

I hope it makes sense.