[GRADLE-1274] JavaExec task should support equivalent of "java -jar" Created: 26/Dec/10  Updated: 07/Feb/17  Resolved: 07/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: None

Type: Improvement
Reporter: Peter Niederwieser Assignee: Unassigned
Resolution: Duplicate Votes: 9


Unless I've overlooked something, the JavaExec task doesn't support the equivalent of java -jar MyApp.jar. Instead, I have to put MyApp.jar on the class path and specify a main class. Supporting "java -jar" would be useful.

Comment by Brandt A. Abbott [ 14/Mar/11 ]

I've used main = '-jar' as a workaround to this issue with success.

Comment by Blaine Simpson [ 24/Apr/11 ]

To help others until such time as executable jars are directly supported, here are two tactics which work, from a working gradle file:

task run (dependsOn: assemble) << {
String jarPath = relativePath(new File(libsDir, archivesBaseName + ".jar"))


{ main = '-jar'; args jarPath }

// No params

// Same w/ params:

{ main = '-jar'; args = [jarPath, 'par1', 'par2'] }

// Since ant.java doesn't return a Groovy process, you can't get
// stderr/stdout. Therefore if your program produces output that you need,
// you must save it off.
ant.java(fork: true, jar: jarPath, outputproperty: 'op',

{ arg(value: 'par1'); arg(value: 'par2') }

println ant.properties.op

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Blaine Simpson [ 15/Nov/16 ]

Still want. I build jar-run apps all the time and shouldn't need a hack to accommodate a basic JRE feature.

Comment by Benjamin Muschko [ 15/Nov/16 ]

@Blaine Simpson Did you try out the application plugin? That's exactly what it provides (among other things).

Comment by Blaine Simpson [ 15/Nov/16 ]

Ben: I use the application plugin regularly. What is the application-plugin-provided task or operator the provides exactly this ability? This issue has nothing to do with building a jar, but with executing a jar (honoring the Jar's manifest). The application plugin reference lists no task that can do it, nor does the Gradle task listing ("gradlew tasks"). Executing the "run" task in an application project doesn't touch the project-generated jar file.

Comment by Benjamin Muschko [ 15/Nov/16 ]

@Blaine Simpson Correct, I was thinking of the run task which sets the classpath via -cp. Can you describe why it matters how you run your application? Can you describe your use case? Is that for testing purposes?

Comment by Blaine Simpson [ 15/Nov/16 ]

That's how I distribute my app, as a jar file. In some cases with dependent jar files referenced in the manifest. Without shell scripts, etc. So that is how I want it exercised and tested, on multiple platforms. I also have other apps installed to run this way, and I'd like to be able to just execute them from Gradle. For example I have a Creole wikitext engine that I use to build documentation, and it's designed to be run by executing the jar without need to know the main class, etc. My build for the Creole engine itself, for example, runs many unit tests in this way. I know that I can execute a JRE manually to run with "-jar" and that's what I'm doing. Just seems that a powerful build tool should support a standard Java invocation mechanism.

Comment by Benjamin Muschko [ 07/Feb/17 ]

The work is now tracked via https://github.com/gradle/gradle/issues/1346.

Generated at Wed Jun 30 11:51:23 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.