Switch to Java 11

[jmesnil]

Hi,

I am working on integrating a library to the plugin and the JDK8 jobs are failing because the lib targets Java 11.

While looking at this, I wonder if and when the plugin could switch to Java 11.
WildFly made the switch for its upcoming 27 release. This will also have an impact on the plugin as it incorporates artifacts from the org.wildfly.core groupId that will require Java 11.

Right now, the plugin is still using a previous release of WildFly Core:

wildfly-maven-plugin/pom.xml

Line 97 in aacffac

<version.org.wildfly.core>17.0.1.Final</version.org.wildfly.core>

When the plugin will use artifacts from upcoming WildFLy Core 19, it will have to make the switch to Java 11.

I wonder how we will make that switch. I see different alternatives:

• Do the switch now for the 3.x releases
  • (-) it should have been in 3.0.0.Final but that's too late for that. WildFly 26/JDK 8 users will be confused about that if they switch to 3.0.0.Final and have a minor/micro release breaks their app.
  • (-) this keeps the 2.x releases usable for WildFly 26/JDK 8
• Bump the minor to 3.1.x and make the switch
  • Do we maintain 3.0.x for JDK8 backwards compatibility or 2.x?
• Bump the major to 4.x and make the switch
  • That seems the most logical approach but makes the 3.x releases very short-lived :)
  • We would maintain 3.x for for JDK8 backwards compatibility

My preference would be to bump to 4.x before making the JDK 11 switch. This seems the most logical approach and matches semantic versioning.

@jamezp Do you have any input on this?

[jamezp]

@jmesnil The 4.x option is fine with me. I don't usually create a maintenance branch until it's needed, but I've got no strong opinion there either.

[jfdenise]

We should bump the dependency on Galleon to 5.0.0.Final.

[jamezp]

FYI I've filed https://issues.redhat.com/browse/WFMP-155 and I'm working on a PR now that will move to 4.0.0.Alpha1-SNAPSHOT and require Java 11.

[jamezp]

#230