Publish a Java 11 main artifact and a jdk21 classifier

.github/workflows/gradle.yml

@@ -10,23 +10,34 @@ on:
 jobs:
   gradle:
     strategy:
+      fail-fast: false
       matrix:
         os: [ubuntu-latest, macos-latest, windows-latest]
+        # 11 is the baseline the published main artifact targets, 21 the runtime most
+        # consumers are on. Running the suite on both is the only way to catch a Java 11
+        # problem that compiling to 11 on a 21 JDK cannot see.
+        java-version: [11, 21]
     runs-on: ${{ matrix.os }}
     steps:
     - name: Checkout
       uses: actions/checkout@v4
 
-    - name: Set up JDK 21
+    # Both JDKs are installed. The last entry becomes JAVA_HOME, so Gradle's daemon
+    # always runs on 21 -- the bnd OSGi plugin is class file 61 and cannot load on an
+    # 11 JVM. The matrix JDK is picked up by the toolchain for compiling and running
+    # the tests, which is the part that needs to happen on Java 11.
+    - name: Set up JDK ${{ matrix.java-version }} and 21
       uses: actions/setup-java@v4
       with:
         distribution: temurin
-        java-version: 21
+        java-version: |
+          ${{ matrix.java-version }}
+          21
 
     - name: Setup Gradle
       uses: gradle/actions/setup-gradle@v3
       with:
         gradle-version: wrapper
 
     - name: Build with Gradle
-      run: ./gradlew build
+      run: ./gradlew build -PjavaTestVersion=${{ matrix.java-version }}

build.gradle

@@ -133,8 +133,22 @@ subprojects {
 		}
 	}
 
-	sourceCompatibility = 21
-	targetCompatibility = 21
+	// Bytecode stays at 11 to match the Maven main artifact, whatever JDK is running.
+	// The published jdk21 classifier is produced by Maven, which is what publishes.
+	sourceCompatibility = 11
+	targetCompatibility = 11
+
+	// -PjavaTestVersion selects the JDK that compiles and runs the tests, so CI can
+	// exercise the same Java 11 bytecode on an 11 and a 21 runtime. Gradle itself keeps
+	// running on the launcher JDK: the bnd OSGi plugin is class file 61 and throws
+	// UnsupportedClassVersionError if the daemon is on Java 11, so the toolchain has to
+	// move rather than the whole build.
+	java {
+		toolchain {
+			languageVersion = JavaLanguageVersion.of(
+				(project.findProperty('javaTestVersion') ?: '21') as Integer)
+		}
+	}
 	tasks.withType(JavaCompile) { options.encoding = 'UTF-8' }
 
 	task sourcesJar(type: Jar) {

pom.xml

@@ -57,7 +57,11 @@
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 
-		<maven.compiler.release>21</maven.compiler.release>
+		<!-- The main artifact is Java 11 so it loads on every supported runtime; the
+		     jdk21 classifier below is the same source compiled at 21. See the jdk21
+		     executions in build/plugins. -->
+		<maven.compiler.release>11</maven.compiler.release>
+		<jdk21.release>21</jdk21.release>
 
 		<jacoco.version>0.8.12</jacoco.version>
 		<!-- jacoco:prepare-agent overwrites this at build time with the -javaagent setting.
@@ -133,6 +137,85 @@
 					</execution>
 				</executions>
 			</plugin>
+			<!-- Two artifacts from one source tree. default-compile emits Java 11 into
+			     target/classes for the main jar; compile-jdk21 emits Java 21 into
+			     target/classes-jdk21 for the jdk21 classifier. The resource copy is
+			     needed because maven-jar-plugin takes a single classesDirectory, and
+			     that directory holds only .class files, so without it the classified
+			     jar would ship without cfml.dictionary's XML.
+
+			     The copy must stay at process-classes and not move later. Setting
+			     outputDirectory on a compiler execution leaks into what the reactor
+			     hands dependent modules, so cfml.parsing's tests resolve
+			     cfml.dictionary to classes-jdk21. Copy the resources after the tests
+			     run and all 326 fail with "Problem loading dictionaryconfig.xml",
+			     which reads like a missing resource rather than a phase ordering
+			     problem. -->
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-compiler-plugin</artifactId>
+				<version>3.13.0</version>
+				<executions>
+					<execution>
+						<id>compile-jdk21</id>
+						<phase>compile</phase>
+						<goals>
+							<goal>compile</goal>
+						</goals>
+						<configuration>
+							<release>${jdk21.release}</release>
+							<outputDirectory>${project.build.directory}/classes-jdk21</outputDirectory>
+						</configuration>
+					</execution>
+				</executions>
+			</plugin>
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-resources-plugin</artifactId>
+				<version>3.3.1</version>
+				<executions>
+					<execution>
+						<id>copy-resources-jdk21</id>
+						<phase>process-classes</phase>
+						<goals>
+							<goal>copy-resources</goal>
+						</goals>
+						<configuration>
+							<outputDirectory>${project.build.directory}/classes-jdk21</outputDirectory>
+							<resources>
+								<resource>
+									<directory>${project.build.outputDirectory}</directory>
+									<excludes>
+										<exclude>**/*.class</exclude>
+									</excludes>
+								</resource>
+							</resources>
+						</configuration>
+					</execution>
+				</executions>
+			</plugin>
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-jar-plugin</artifactId>
+				<version>3.4.1</version>
+				<executions>
+					<execution>
+						<id>jar-jdk21</id>
+						<phase>package</phase>
+						<goals>
+							<goal>jar</goal>
+						</goals>
+						<configuration>
+							<classifier>jdk21</classifier>
+							<classesDirectory>${project.build.directory}/classes-jdk21</classesDirectory>
+							<!-- The parent is pom-packaged and compiles nothing, so its
+							     classes-jdk21 is empty. Without this it still emits and
+							     deploys a spurious cfparser-VERSION-jdk21.jar. -->
+							<skipIfEmpty>true</skipIfEmpty>
+						</configuration>
+					</execution>
+				</executions>
+			</plugin>
 			<plugin>
 				<groupId>org.jacoco</groupId>
 				<artifactId>jacoco-maven-plugin</artifactId>