Move jlink related parameters into a complex object

[abhinayagarwal]

Currently, the plugin uses a number of parameters which are mostly related to jlink command. These can be passed into a complex object, making the configuration more user friendly.

For example:

<plugin>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-maven-plugin</artifactId>
    <version>0.0.4</version>
    <configuration>
        <stripDebug>true</stripDebug>
        <compress>2</compress>
        <noHeaderFiles>true</noHeaderFiles>
        <noManPages>true</noManPages>
        <launcher>hellofx</launcher>
        <jlinkImageName>hello</jlinkImageName>
        <jlinkZipName>hellozip</jlinkZipName>
        <mainClass>hellofx/org.openjfx.MainApp</mainClass>
    </configuration>
</plugin>

should be used as:

<plugin>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-maven-plugin</artifactId>
    <version>0.0.4</version>
    <configuration>
        <jlink>
            <stripDebug>true</stripDebug>
            <compress>2</compress>
            <noHeaderFiles>true</noHeaderFiles>
            <noManPages>true</noManPages>
            <launcher>hellofx</launcher>
            <imageName>hello</imageName>
            <zipName>hellozip</zipName>
        </jlink>
        <mainClass>hellofx/org.openjfx.MainApp</mainClass>
    </configuration>
</plugin>

[abhinayagarwal]

The disadvantage of implementing this would be to loose some ability on customising these parameters. This includes the ability to define these parameters via command line as Maven doesn't support complex parameters as system property.

We have to decide if this bargain is worth it.

[nithyasharabheshwara]

I feel no need. The parameters, at least some of them are universal. Today some of them seem to be relevant exclusively for jlink, but in the future, a given parameter might seem relevant elsewhere also. So they can be seen as simple parameters alone, they just happen to be exclusively used by jlink.

[abhinayagarwal]

All the universal parameters like options, mainClass etc. will continue to exists. Only the parameters that are specific to jlink will move into the <jlink>.

but in the future, a given (jlink) parameter might seem relevant elsewhere also

I would say there is a negligible chance of this.

[bgmf]

I'd prefer the second, nested, variant unless you decide to name all parameters in a way that makes it clear, they belong to jlink.

But still, using a nested <jlink> looks much cleaner, in my opinion.

[joerg-wille]

I prefer the first, simple notation. The javafx-maven-plugin wraps functionality of different plugins like compile, assemble and bundling. So, all the config parameters belong to java fox-maven-plugin. IMHO, no need to know that some of these belong to jlink.

[tiainen]

I don't think the switch is worth it, given the fact that we loose a lot of functionality. At best, we can rename the jlink specific parameters to better reflect that they are only used for jlink.

Another option that is currently available, is to move the jlink configuration to a different execution section that is only executed during a certain phase. This can only be used if always running the jlink goal during that phase is desirable.

<plugin>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx-maven-plugin</artifactId>
    <version>0.0.4</version>
    <configuration>
        <mainClass>${mainClassName}</mainClass>
    </configuration>
    <executions>
        <execution>
            <id>javafx-jlink</id>
            <phase>package</phase>
            <configuration>
                <jlinkVerbose>true</jlinkVerbose>
                <jlinkZipName>abcd.zip</jlinkZipName>
            </configuration>
            <goals>
                <goal>jlink</goal>
            </goals>
        </execution>
    </executions>
</plugin>

[abhinayagarwal]

Hi @tiainen !

Thank you for the feedback. Don't you think that the parameters list will keep increasing and go out of proportion in the future. For example, if the jlink parameters increase in the future, as it has been in the past. Or, if we wish to include jpackage functionality in the plugin.

[tiainen]

In the end it might be better to completely separate the jlink/jpackage functionality into a new plugin.