Jlink support for Java plugin

[vpa1977]

What needs to get done

Java plugin should set JAVA_HOME #891 and provide a way to generate runtime for the Java application.

This can be done by running jlink and passing a list of jar files. Java plugin by default copies files to $CRAFT_PART_INSTALL/jars and java plugin will pick up jars from this location in post build commands and generate the runtime for those jars. User should be able to specify the version of the Java to use and list of jar files and directories if the default value is not acceptable. User should be able to specify if he wants to run a jlink step.
Java should be available as a plugin so that build without applying derivative plugins is supported.

• register Java as a plugin.

parts:
   foo:
     plugin: java
     jlink: true
     jlink_java_version: 21
     jlink_jars:
        - $CRAFT_PART_INSTALL/jar/jar1.jar
        - $CRAFT_PART_BUILD/jar/jar2.jar

• The plugin should install chisel slices into a build root (otherwise it affects build JDK)
• The plugin should use chiselled runtime to generate jlink runtime.

Why it needs to get done

To have a lean runtime for java applications

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-3627.

This message was autogenerated

[tigarmo]

The jlink part of this is fine, but I'm not sure about this java plugin. What would its default build commands do?

[vpa1977]

The jlink part of this is fine, but I'm not sure about this java plugin. What would its default build commands do?

I think we should use the plugin to run the wrappers. There is a use-case for gradle wrapper (as we have discussed) and for a maven wrapper (to a lesser extent). So by default we should use java plugin to execute ./gradlew or ./mvnw (and add other build system with wrappers).

The gradle plugin should use gradle provided by the dependency, rather than call the wrapper.

[tigarmo]

Today we (myself, @vpa1977 and @mr-cal) met and talked about this topic. We ended up agreeing that a general "jlink" plugin, which would generate a Java runtime for multiple Java parts (leveraging the existing after behavior), is the best solution for this issue. The plugin will have its own set of jlink-related properties, and its outcome is a smaller Java runtime even though it, by itself, doesn't produce any jars.

From the other options, using an Extension wouldn't be possible because the jlink call needs parameters, and a build-attribute is also not possible not only because of the parameters (which build-attributes currently do not support), but also because the intention is to process the jars from multiple parts at the same time, to generate a single runtime.