Cannot build GlassFish 7.0.13-SNAPSHOT (6611a36875a4fe8be16a9e5eddaa433af7c6c465) with JDK 11

[tomjenkinson]

Building GlassFish 7.0.13-SNAPSHOT (6611a36) with JDK11 does not seem to work. When I am building with JDK 11, I get a problem that I don't seem to get with JDK 17 (I will redact certain path aspects with the sequence REDACT - hopefully the general issue isn't masked by that):

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run (do stuff) on project glassfish: An Ant BuildException has occured: The following error occurred while executing this line:
[ERROR] _REDACT_/glassfish/appserver/distributions/glassfish/target/antrun/build-main.xml:9: The archive microprofile-jwt-auth-api.jar doesn't exist
[ERROR] around Ant part ...<jarupdate basedir="_REDACT_/glassfish/appserver/distributions/glassfish/src/main/patches/microprofile-jwt-auth-api" destfile="_REDACT_/glassfish/appserver/distributions/glassfish/target/stage/glassfish7/glassfish/modules/microprofile-jwt-auth-api.jar" includes="META-INF/MANIFEST.MF" />... @ 16:318 in _REDACT_/glassfish/appserver/distributions/glassfish/target/antrun/build-main.xml

I think it should be able to work, and the README indicates it to be expected to work:

glassfish/README.md

Line 10 in 6611a36

* Eclipse GlassFish 7.0.0 is Jakarta EE 10 compatible, requires Java 11, supports Java 17 and Java 21

[arjantijms]

Yes, this should work indeed. It's a relatively simple and silly problem when I take a glance at the error. The build system doesn't build/include the MP jars on JDK 11.

However, there's also a blunt/brute force patching system in place, which doesn't check for JDK 11/JDK 17. You can quickly resolve it locally by removing the .<jarupdate basedir="_REDACT_/glassfish/appserver/distributions/glassfish/src/main/patches/microprofile-jwt-auth-api" tag from said ant build file. I'll take a look at how to solve this more gracefully.

[tomjenkinson]

Thank you! By removing the two MicroProfile jar updates (microprofile-jwt-auth-api and microprofile-rest-client-api) in

glassfish/appserver/distributions/glassfish/pom.xml

Lines 105 to 112 in 6611a36

	<jarupdate
	basedir="${patches}/microprofile-jwt-auth-api" includes="META-INF/MANIFEST.MF"
	destfile="${glassfish.modules}/microprofile-jwt-auth-api.jar"
	/>
	<jarupdate
	basedir="${patches}/microprofile-rest-client-api" includes="META-INF/MANIFEST.MF"
	destfile="${glassfish.modules}/microprofile-rest-client-api.jar"
	/>

I have managed to get it to build locally.

[dmatej]

Just a side note - I don't know what is your target, but you will get a bit different jar/zip than with JDK17. And even GlassFish built with JDK17 should be usable with JDK11, however we always recommend to switch to JDK17 everywhere.
See

glassfish/README.md

Line 26 in 6611a36

* JDK11+, we strongly recommend using JDK17 to build GlassFish with all features.

[tomjenkinson]

The purpose I would like it for is to verify that Jakarta Transactions API changes would be compatible with EE 10 and part of the verification process for that needs an EE10 server and is using Glassfish for that

[dmatej]

Then you can build it with 17, it is alright to use it with 11 then. We do that this way too. (And that is the reason why we missed that GF build breaks with 11 now).

[tomjenkinson]

I think you are right that it is OK to compile with JDK17 so long as the API jar is binary compatible with JDK 11 (jakartaee/platform#331) but the build system for the Jakarta Transactions is using JDK 11 at the moment and so given GlassFish is expected to build with JDK 11 (as in, it's the expectation of the GlassFish project) I think trying to stay on JDK 11 (except for this bug) should be OK shouldn't it? Now, if GlassFish did drop support for building with JDK 11 in a maintenance release of GlassFish 7 then I expect updating the Jakarta Transactions build system to use JDK 17 where necessary is an option we should definitely consider. It would seem a bit complicated though because either we would need to make a decision to not try to run with JDK 11 at all (if that is even allowed: "Java SE 11 will become the minimum runtime supported by Jakarta EE compatible implementations." [1]), or have the necessary build systems compile whatever we needed with JDK17 but still run the TCK tests with JDK 11.

[1] https://jakartaee.github.io/platform/jakartaee10/JakartaEE10ReleasePlan

[dmatej]

Mea culpa, I missed the reference to jakartaee/transactions#212, now I see what you need to do. I would say this is the only reason why GF build still supports (or should support) JDK11, that some JEE10 specs still require to build GF on their own with JDK11. We have fix it.

[tomjenkinson]

Thank you!