Thanks again James. I really appreciate your help. This is not a simple series of questions, but your answers are really helpful.
But I agree with you 100% that that is the DSL I like conceptually.
I had not thought of extending the extension (I already have a main DSL extension object) to include these profiles and dynamically adding discovered ones. This would be a “named container” I assume?
So my existing DSL extension looks like, e.g.:
databases {
defaultProfile = 'derby'
profileDirectory 'custom-databases'
...
}
Like I said, I conceptually like the idea of adding the profiles to this DSL:
databases {
defaultProfile = 'derby'
profileDirectory 'custom-databases'
profiles {
...
}
...
}
I’m just not sure about the specifics of:
find fragments and add them to the
databaseProfiles
extension separately
I’m sure I am missing something.
So I assume you mean is something like:
public class DslExtension {
private final Project project;
private String defaultProfile = "h2";
private final List<File> profileDirectories = new ArrayList<>();
...
/**
* Think of Profile as GradleProfileFragment. ATM we allow 2 distinct ways to define a profile:
* 1) via a Gradle fragment
* 2) via a dir with properties file and jdbc jars
*
* But for making this easier... let's assume there is just one way - via a Gradle fragment and
* that Profile == GradleProfileFragment
*/
NamedDomainObjectContainer<Profile> profiles;
}
So when Gradle sees, e.g.
databases {
...
profiles {
h2 {...}
derby {...}
}
}
it will automatically create 2 profiles in the DslExtension#profiles
NamedDomainObjectContainer named h2
and derby
. But I am still unsure of how to process the Gradle fragment files I discover.
Is the idea that the Gradle fragment file would specify that full “path”? I.e.:
profile.gradle
---------------
databases {
profiles {
oracle {...}
}
}
That’s not ideal, but if it works I can live with that.
Am I understanding you correctly?