With what I was mentioning, you now have 3 ways to define a profile.
Inline:
databases {
...
profiles {
h2 {
beforeEachTestAction { testDescriptor ->
printf("Executing test `%s` against h2 profile", testDescriptor)
}
beforeTestTaskAction { task ->
printf("Executing Test task `%s` against h2 profile", task)
}
}
derby { ... }
}
}
Fragments:
// h2.gradle
h2 {
beforeEachTestAction { testDescriptor ->
printf("Executing test `%s` against h2 profile", testDescriptor)
}
beforeTestTaskAction { task ->
printf("Executing Test task `%s` against h2 profile", task)
}
}
// plugin code
project.files(profileDirectory).filter { include '*.gradle' }.each { fragment ->
project.apply(from: fragment, to: databases.profiles)
}
This is really rough and may not compile as is. Essentially you need code that can apply your fragment to what you have that can handle it. You can tweak this code though. Maybe a generic profile container in the fragment that corresponds to a method on databases different than the NamedDomainObjectContainer
, but that properly adds it.
Then you have the code that can look up the properties and manually add them to the NamedDomainObjectContainer
. That’s essentially read property file, map to ProfileDefinition
, add to NamedDomainObjectContainer
like you would any collection.