beryx / badass-runtime-plugin

Create a custom runtime image of your non-modular application
https://badass-runtime-plugin.beryx.org
Apache License 2.0
161 stars 21 forks source link

Including the org.beryx.runtime plugin overrides the defaultJvmOpts in every CreateStartScripts-based task #128

Open pspeed42 opened 2 years ago

pspeed42 commented 2 years ago

In my application build, I have a CreateStartScripts task for creating a separate start script (for running my app on older JVMs) and I include this in my distZip version of the application. This CreateStartScripts task has customized defaultJvmOpts for running on the older version of Java. Normally that all works fine.

However, as soon as I simply include the beryx.runtime plugin:

plugins {
    id 'org.beryx.runtime' version '1.12.7'
}

...without even configuring anything... The defaultJvmOpts get overridden with whatever is in applicationDefaultJvmArgs.

This is suboptimal.

My goal is to build platform specific JVM+app bundles with your plugin but also to still build a distZip for "other" platforms. At this point, the only way I can make that work is to use two different build files, one with your plugin included and the other without.

Thanks for your consideration.

Version information in case it matters:

------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------

Build time:   2022-03-31 15:25:29 UTC
Revision:     540473b8118064efcc264694cbcaa4b677f61041

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          18 (Oracle Corporation 18+36-2087)
OS:           Windows 7 6.1 amd64
hakanai commented 1 year ago

This issue is at around this point: https://github.com/beryx/badass-runtime-plugin/blob/3b04fc7e9b142133836679d3468c04962fc582c7/src/main/groovy/org/beryx/runtime/RuntimeTask.groovy#L88

The configuration gets applied to all CreateStartScripts tasks, I'm guessing under the assumption that all such tasks will be for launching the application, an assumption which turns out to be false if you use that task for other things.

I haven't figured out what the fix would be, but we'd need some way to distinguish the tasks we do want to apply it to, from the ones we don't. Maybe even looking at the name of the task?