This is a difference between a convention and an extension. The convention essentially merges the methods of one object directly into the other. In a typical Java project, things like source sets and source/target compatibility are part of the Java plugin convention, but are used directly in build.gradle
:
sourceCompatibility = '1.8'
targetCompatibility = '1.8'
sourceSets {
main {
java {
srcDir 'src/generated/java'
}
}
}
In contrast, extensions are nested under the extension name. If you wanted the same for a convention, you would have to do the nesting of another object yourself. It’s also been said that extensions are expected to fully replace conventions eventually, but this hasn’t been a very quick process.
I don’t think you should actually be trying to remove anything. I think the concept of the fragment should be implemented completely independently of the DSL using some of the concepts in Custom Gradle Types. Imagine a DSL like this:
databaseProfiles {
h2Profile {
beforeEachTestAction { testDescriptor ->
printf("Executing test `%s` against h2 profile", testDescriptor)
}
beforeTestTaskAction { task ->
printf("Executing Test task `%s` against h2 profile", task)
}
}
otherDatabaseProfile {
beforeEachTestAction { testDescriptor ->
printf("Executing test `%s` against other profile", testDescriptor)
}
beforeTestTaskAction { task ->
printf("Executing Test task `%s` against other profile", task)
}
}
}
Nothing needs to be removed here. The configuration is contained to the specific ProfileDefinition
that is being configured, so you don’t need to worry about even what’s in a particular file. Code can independently be written that would find fragments and add them to the databaseProfiles
extension separately, perhaps with the filename being the name in that case. If you don’t want them to be named, that’s fine too. It just changes the methods called slightly.