Does anyone have an example of building a subproject against two versions of JDK or Groovy or Kotlin? And by this I meant building using variants, not having two subprojects with code symlinked.

If it is the same code, why do you need feature variants? If it also compiles with the new version, just having the variant for the old version should be enough as they are backwards compatible, aren't they? Or is it to verify it is still compiling with the new version? Then you probably do not want a feature variant, but simply a second source set that points to the same source directories but uses newer version. Or in that case maybe even just an additional compile task that compiles the main source set using the newer version. Or what is the actual use-case?

It is for releasing libraries. Consider Spock Framework for exmaple. Ther are Groovy 2, Grrovy 3 and Groovy 4 variants.

Yeah, unfortunately as separate artifacts, not feature variants though. :'''-( When using feature variants for something like Groovy or Kotlin, you just have to define feature variants as documented and the consumer has to manually pick them. For Java versions you additionally set the capability of the feature variant to the main capability, so that Gradle can automatically pick the right variant by the Java version attribute.

For context, I'll step back no native builds. I don't know if you've ever worked with them. (I haven't for at least 4yrs). There it is possible to build more than one variant from the same source set. I was wondering this is possible with Gradle for JVM projects, but clearly it is not achievable in s a straight forward way., because as you say we just have feature variants - it does not really create different artifacts.

I would expect having multiple feature variants on the same source set should be possible. As far as I remember one of the use-cases is to have the same artifact but just different dependencies, for example additional dependencies when used with Java 9+ for something that was available in Java 8 stdlib but was moved to a standalone library thereafter.

Yeah if you want to do something like this, you will likely need to roll your own solution. That would involve creating SourceSets for each of your targets. Gradle will then create the necessary JavaCompile and Jar tasks for you, but you will need to configure the compile tasks manually to set their target java versions. For dependencies like groovy, you will have to add those to the corresponding source sets. If you are manually creating these source sets, you will need to create the consumable configurations to allow other projects to select them. You will also need to take care of publishing which could be difficult to impossible. Especially if you want one of these multi-target projects to depend on another multi-target project. That sort of functionality is blocked by this issue: https://github.com/gradle/gradle/issues/12324 You could also sort of abuse

registerFeature

to do most of the work for you, but I’m not sure how far you’ll get. Here is some example code that attempts to do something like you want for Java, but it will likely fall apart if you try to do anything more than really basic stuff: https://github.com/gradle/declarative-gradle/blob/main/unified-prototype/unified-p[…]/org/gradle/api/experimental/jvm/internal/JvmPluginSupport.java In general, you will probably hit dead ends pretty quickly. We are definitely looking into solving these sorts of problems, but no roadmap on when we can provide any official support