Closed jjohannes closed 6 months ago
If patching for OS specific artifacts is a common use case, maybe we can come up with an even more compat way of declaring just that in addition.
addTargetPlatformVariant
is already that: TargetPlatformVariant
stands for OS+ARCH
Not sure what can be more specific, but happy to discuss. Although that would be a separate issue. This one is about the module(...)
part which is for any kind of patching rules. The addTargetPlatformVariant
is only used as example here.
Just realized that this signature is (of course) not possible in Java:
public void module(String... modules, Action<PatchModule> action)
Lets think about this a bit more.
You can already do something like this today with standard Kotlin/Groovy notations:
jvmDependencyConflicts {
patch {
listOf("org.openjfx:javafx-base", "org.openjfx:javafx-graphics").forEach {
module(it) {
addTargetPlatformVariant("", "none", "none")
addTargetPlatformVariant("mac", "macos", "x86-64")
addTargetPlatformVariant("mac-aarch64", "macos", "aarch64")
addTargetPlatformVariant("win", "windows", "x86-64")
addTargetPlatformVariant("linux-aarch64", "linux", "x86-64")
}
}
}
}
If you want to have varargs the only way I see to get this working would be a method chain like the following:
jvmDependencyConflicts {
patch {
modules("org.openjfx:javafx-base", "org.openjfx:javafx-graphics").each {
...
}
}
}
The modules
method would have the following signature:
public EachModuleConfigurer modules(String... modules);
interface EachModuleConfigurer {
public void each(Action<PatchModule> action)
}
But this would just wrap around a forEach call and would spare you from writing listOf
. Not sure if this is really better. The problem with these kind of chaining APIs is always when you forget to make the terminal call nothing happens. And that is sometimes hard to find.
Lets not do this now. I would prefer not to overload the DSL unless there is a really clean DSL concept (and not a technical API).
Should be able to write: