How to add jvm options in a gradle project?

Answered

In run.json

when type is jps-run, "options": ["vmoption"] is work

but when I use gradle, "options" is not exist and I dont know how to add jvm options to a gradle task.

My configuration:

        {            "name": "Application",
            "mainClass": "Start",
            "type": "jps-run",
            "module": "Application",
            "dependsOn": ["build"],
            "options": [
                "-Dfile.encoding=UTF-8",
            ],
        },

        {
            "name": "Application [:Start.main()]",
            "type": "gradle",
            "environment": {
                "org.gradle.jvmargs": "-Dfile.encoding=UTF-8" // this is not working
            },
            "tasks": [":Start.main()"],
            "initScripts": {"flmapper":"ext.mapPath = { path -> null }","Start.main()":"\n    def gradlePath = ':'\n    def runAppTaskName = 'Start.main()'\n    def mainClass = 'Start'\n    def javaExePath = mapPath('C:/Program Files/Java/jdk1.8.0_202/bin/java.exe')\n    def _workingDir = mapPath('D:/Code/projects/Java/Application')\n\n    def sourceSetName = 'main'\n    def javaModuleName = null\n\n    \n    \n    \n\n    import org.gradle.util.GradleVersion\n\n    allprojects {\n      afterEvaluate { project ->\n        if(project.path == gradlePath && project?.convention?.findPlugin(JavaPluginConvention)) {\n          def overwrite = project.tasks.findByName(runAppTaskName) != null\n          project.tasks.create(name: runAppTaskName, overwrite: overwrite, type: JavaExec) {\n            if (javaExePath) executable = javaExePath\n            main = mainClass\n            \n            if (_workingDir) workingDir = _workingDir\n            standardInput = System.in\n            if (javaModuleName) {\n              classpath = tasks[sourceSets[sourceSetName].jarTaskName].outputs.files + project.sourceSets[sourceSetName].runtimeClasspath;\n              if (GradleVersion.current().baseVersion < GradleVersion.version(\"6.4\")) {\n                doFirst {\n                  jvmArgs += [\n                    '--module-path', classpath.asPath,\n                    '--module', javaModuleName + '/' + mainClass\n                  ]\n                  classpath = files()\n                }\n              } else {\n                mainModule = javaModuleName\n              }\n            } else {\n              classpath = project.sourceSets[sourceSetName].runtimeClasspath\n            }\n          }\n        }\n      }\n    }\n    "},
        },

 

0
3 comments

and I used   implementation(fileTree(dir: 'lib', include: ['*.jar']))  in build.gradle

It works well in IntelliJidea

but I tried to run a jps-run task, other implementation (such as implementation 'org.projectlombok:lombok:1.18.22') is imported correctly

only my local libs went wrong

 

0

To pass JVM arguments to a Gradle task please use the same means as you would use from the command line for Gradle. It means you have options to pass jvm options via either:

- Gradle build scripts e.g. gradle.properties, see Build Environment in Gradle documentation

- Use the configuration, which provides the corresponding Gradle plusin. E.g. for `application` Gradle plugin there is applicationDefaultJvmArgs option, see The Application Plugin in Gradle documentation

0

I think this is not a sufficiently strong solution. 

It is quite common to have to override arguments, including JVM arguments. 

It is important to be able to do that in run configurations - IntelliJ RCs are very good for this. 

The name of the `applicationDefaultJvmArgs` option is a good hint; these are the defaults in the Gradle script, and they are often overridden, by a CI/CD server in pipeline definitions and by the IDE in run configurations. 

It is of course possible to simply rely on the command line - but at that point we're not using the run configurations at all. 

Should we not expect that all the richness of the IntelliJ run configurations will eventually be available in Fleet, too? Otherwise it is hard to see how it would be possible to switch to Fleet in an enterprise setting, which is sort of aggravating because the collaborative functionality looks really tasty... 

0

Please sign in to leave a comment.