I have a what feels like a straightforward problem, but wondering the best approach.
I am using a library which requires a specific properties file (dsp-client.properties) to be in the classpath. The properties file has a single value. i.e. serverURL={address}. There are three versions of this file in a folder structure- conf/prod, conf/stg, conf/tst. Each file has different serverURL value.
What would be a better approach- create 3 source sets for each configuration or simply jar each file once and define 3 configurations?
I don’t “own” the library that reads the properties file, so I don’t have the flexibility to alter how the property is read. It it hard-coded to look for “dsp-client.properties” on the classpath.
Assuming you want to publish an artifact for each environment, you could do something like
apply plugin: 'java'
['tst', 'prod', 'stg'].each {
tasks.create("jar$it", type: Jar) {
dependsOn jar
from zipTree(jar)
from "conf/$it"
archiveClassifier it
}
assemble.dependsOn "jar$it"
artifacts {
archives tasks["jar$it"]
}
}
This will create an artifact for each environment which adds an additional directory to the default jar. Each has a unique classifier that can be used in downstream processes
First off, thanks for responding. Yes, I had something like this initially. I missed the assemble.dependsOn line, which is probably why the jars where not in place for the run task.
I was leaning towards the more explicit approaches (sourceSets or configuration) because I wanted to have 3 different JavaExec configurations to test each instance. Can you think of a way to use the jars outputted dynamically here to include them in the JavaExec tasks?
I’d probably want a similar appending of the classpath in the Test tasks. For the final distribution, I’ll need to ensure these configuration files are included.