Support maven.compiler.release parameter in Xtext/Xtend Maven plugins

[HannesWell]

Add support for reading the maven.compiler.release parameter and grant it precedence over a maven.compiler.source or maven.compiler.target configuration (similar to the Java compiler).

As suggested in

• Use maven.compiler.release instead of source plus target #3603 (comment)

[HannesWell]

I only adapted the test-cases in this directory because I expect them to be the only ones to 'use' the changed code immediately.

[github-actions]

Test Results

  6 461 files  + 1 609    6 461 suites  +1 609   3h 21m 16s ⏱️ + 1h 4m 50s
 43 236 tests ±     0   42 646 ✅  -      6    584 💤 ±  0  6 ❌ +6 
170 059 runs  +42 540  167 716 ✅ +41 950  2 337 💤 +584  6 ❌ +6 

For more details on these failures, see this check.

Results for commit d871f11. ± Comparison against base commit 99a5c22.

♻️ This comment has been updated with latest results.

[HannesWell]

@cdietrich, @LorenzoBettini, @szarnekow any chance this will land in the upcoming release?

[LorenzoBettini]

As for me, the PR is fine!

I think there's an important aspect to clear: the Xtend compiler and also the Xtext maven plugin infrastructure do not really honor the semantics of "release". That is, they don't check that in the Xtend code or in an Xbase DSL code you only use Java API up to the specified release. Am I right, @szarnekow ?

If that's the case, it should be clearly documented in the Javadoc and possibly in the release notes and documentation.

[HannesWell]

I think there's an important aspect to clear: the Xtend compiler and also the Xtext maven plugin infrastructure do not really honor the semantics of "release". That is, they don't check that in the Xtend code or in an Xbase DSL code you only use Java API up to the specified release.

That's my understanding too. At least at the moment it's implemented as basically just an alias for the source respectively source+target option in the xtend-compiler and xtext-generator mojos.
However as that property also configures the java compiler such issues should be catched when the Java-compiler is invoked.

On the other hand, since the Xtext/Xbase compiler receives type information from JDT and if the JDT configuration of the project is set accordingly, Xtext should just inherit that capability. So I naively assume that it's just a matter of configuring JDT accordingly.

[LorenzoBettini]

For me it's fine.
@szarnekow what do you think?

[cdietrich]

what about /org.eclipse.xtext.xtext.wizard/src/org/eclipse/xtext/xtext/wizard/ParentProjectDescriptor.xtend

[cdietrich]

should we switch to new style there?

[LorenzoBettini]

release has been available since Java 9, so it might be the case to use the new style

[HannesWell]

That's also part of #3603.
And since, as far as I understand, the Xtext build requires some bootstrapping and is not built with the Xtext Maven plugins of the same state, I suggest to keep it separated and implement that enhancement in #3603 as follow-up on this one.

[HannesWell]

@cdietrich and @LorenzoBettini (and maybe @szarnekow),
is there anything missing or can this be submitted in time for the release?

[cdietrich]

i dont have time to think how we could verify this with

• xtext-reference-projects using the maven repo by this build
• figure out (maybe with logs)
  that java 11 fallback is not used
  https://ci.eclipse.org/xtext/view/PRs/job/xtext/job/PR-3607/3/artifact/build/maven-repository/

[HannesWell]

• figure out (maybe with logs)
  that java 11 fallback is not used

That's a very good point. Probably it does indeed use the Java-11 default as the parameter should actually never be null.
I see three options here:

1. Not set a default for the release parameter
2. Consider the release parameter not set if the value is equal to the default
   It then will use the source/target parameter as before.
3. Apply the default in code to be able to detect if the value was actually set or not

The first and last option basically have the same out-come: If not set the target/source attributes are used and since their default is 11 too, that default is used again.
So having no default for this alias (what it effectively is), seems the right choice to me.
Will update this PR accordingly.