Very basic question about deploying/distributing and then running


(Mike Rodent) #1

Maybe someone can just point me to somewhere in the manual for this…

I have a very simple embryonic project. As it happens I’m using Groovy for the test and the app. I know how to test and build and to do a run from the location in my Eclipse projects directory. And how to create a .jar file.

But now I want to “deploy” (or should that be “distribute”) the executable .jar to another directory in my system… and then run from that location.

As this is not a “fat jar” (i.e. packaged with all its dependencies, using ShadowJar, for example) it is obviously going to need the gradle app to run it…

This business of putting something somewhere else is obviously a “task”… I presume I don’t have to copy the .jar file somewhere else manually. Also, is running it then a simple matter of going

gradle myapp.jar
or maybe
gradlew myapp.jar
?

PS this is a Windows system, but I’m using Cygwin…


(Adrian Baker) #2

I think https://docs.gradle.org/current/userguide/application_plugin.html is what you want ?


(Mike Rodent) #3

Thanks… I’m still floundering with that page (which I think I had found)…

My attempt to put “executableDir” resulted in “unknown property”.

Then I looked at “installDist”… which “Installs the application into a specified directory.” and is dependent on startScripts, “Creates OS specific scripts to run the project as a JVM application.” …

This is what I want to do:

“The application plugin can generate Unix (suitable for Linux, macOS etc.) and Windows start scripts out of the box. The start scripts launch a JVM with the specified settings defined as part of the original build and runtime environment (e.g. JAVA_OPTS env var). The default script templates are based on the same scripts used to launch Gradle itself, that ship as part of a Gradle distribution.”

Does that then mean I will be able to go

java myAppExecutableJar.jar
… ?

Also the .jar file which I find under /build/libs doesn’t run:

java myApp.jar

results in “could not find or load main class…”… I presume this is because the “manifest” has not been set up or something? NB as part of the application plugin configuration I had of course already set mainClassName… In my naivety I imagined this might then use that to automatically create the right manifest. But no.

Then I put the following:

jar {
	manifest {
		attributes 'Main-Class': 'core.ConsoleHandler'
	}
}

… the jar still doesn’t run…

Sorry, I really am floundering… I’m just looking for a few relevant lines from an example build.gradle … and also a clue about what you run at the command line when you’ve managed to create this executable jar … seems to me that this sort of thing might form part of a Gradle 101… if such a thing existed…


(Adrian Baker) #4

Does https://github.com/gradle/gradle/tree/master/subprojects/docs/src/samples/application help?

The application plugin doesn’t produce an executable jar, but a zipped/tarred folder of all of the required jars plus a start script (it’s not a Java specific plugin). installDist creates an exploded version of this application, by default in the build/install directory of your project.


(Mike Rodent) #5

I tried that… firstly in an existing project (==> “unknown property ‘executableDir’”)

Then, in Eclipse, I made a new Gradle project (with the standard directory structure) adding only the Main.java file at that link, and substituing the build.gradle there … exactly the same problem.

BTW my Eclipse (Oxygen) is using Gradle 4.4.1, Groovy 2.4.12 and Java 8
The OS is Windows 10, and the Ant version (as printed when you go “gradle -version”) is 1.9.9
Could any of these be factors involved in the problems I’m having?
NB I also ran at the command line using Groovy 2.6 - same problem.

In fact, if you look at the doc for Project (4.5.1) there doesn’t appear to be a property executableDir (or a getExecutableDir method). Is it possible that something else needs to be used now? Such as DEFAULT_BUILD_DIR_NAME, perhaps …? If so maybe that Github example should be updated…

HOWEVER… in my “real” project, I have succeeded in generating things under /build/install/, namely unzipped bin and lib directories … and yes, running one of the files under /bin/ there runs the project… seemingly using the .jar files under build/install/lib/.

And, using this very useful plug-in I was able to see the effect of including or excluding the ‘application’ plug-in: with it, the build task has 2 additional “dependency tasks” (if that’s the right term… ): ‘distTar’ and ‘distZip’. Is it possible I’m beginning to claw my way to enlightenment? To change the output dir this does the job:

zipDist{
	destinationDir = file( "$operativeDir/$version" )
}

I’m slightly puzzled, though. Clearly, when you say “all of the required jars” this means all the dependency jars. But it strikes me that if you have Gradle installed on your system it is clear that you have the dependency jars you need under GRADLE_HOME, and I would expect there to be a way of running gradle from the command line (anywhere) but making use of these existing .jars. Dependency .jars can be huge… to copy the ones that are already present from your local Gradle “single repository” to another place on your system seems a bit strange… I was assuming there would be a way of going (somewhere away from your development location)

gradle -somethingsomething myproject.jar

or

gradlew -somethingsomething myproject.jar

…?


(Adrian Baker) #6

I would expect there to be a way of running gradle from the command line (anywhere) but making use of these existing .jars

Try the run task of the application plugin.


(Mike Rodent) #7

Thanks… but I don’t seem to have made myself clear.

Your suggestion means putting a build.gradle file in the place where you have done your installDist to… there is no build.gradle file there… and, for a laugh, I just tried copying the gradle.build from the “development” location to the “production” location (i.e. the /lib dir or /bin - I tried both).

$ gradle run
$ gradle run
Starting a Gradle Daemon, 3 busy Daemons could not be reused, use --status for details
:compileJava NO-SOURCE
:compileGroovy NO-SOURCE
:processResources NO-SOURCE
:classes UP-TO-DATE
:runError: Could not find or load main class core.ConsoleHandler
 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':run'.
> Process 'command 'D:\apps\Java\jdk1.8.0_121\bin\java.exe'' finished with non-zero exit value 1

… you’d need a different type of build file … with a different type of Task… making this into another, specific question!


Is there/shouldn't there be a way of running Gradle from a production location?
(Adrian Baker) #8

No, you’d execute the run task from the source project. Without the source build, how would gradle know what dependencies to resolve, and where to resolve them from?

Trying to build a standalone distribution which references GRADLE_HOME doesn’t really make sense. Especially if it’s only to save some local file copies of jars - have you actually found this copy to be slow?