Gradle initializr: start Java application project from webpage

Gradle Initializr is a good way to start a project with a Gradle build.

Open this web page.

Select the type of project. We'll do a Java application.

Select the build language - in this case we'll choose Groovy.

Select the Gradle version - choose the most recent.

Leave the archive format at zip

Put in a project name and package name.

and Generate.

This downloads a project configured with Gradle the way you selected and some sample Java code.

Unzip the download.

I got this "Confirm File Replace" with 7-zip. You can say yes to all.

settings.gradle
by default, the project name is the directory name.
line 10 makes that explicit
line 11 - this is a Gradle multi-project build and app is a project

.gitignore
.gradle is a directory Gradle uses for internal management. it should never be added to the git repo.
build is a directory for the build outputs such as JAR files and zip files. it should never be added to the git repo.

.gitattributes
bat files should have carriage return/line feed as their new line separator upon commit or fetch


It's worth noting here that git is not initialized in this directory.
.gitignore and .gitattributes are typical files you would check into git for development across different machines and users.

in the wrapper directory
gradle-wrapper.jar is a small jar that knows how to download a whole gradle distribution (much bigger).
This should be checked into git when you commit.

wrapper/gradle.properties
This build will use Gradle 6.7. This string can be updated later to change the Gradle version.
The other values can be changed, but not typically - only for advanced situations like when you are hosting your own Gradle dists

build.gradle
line 11 adds configuration allowing for a Java main method. It also adds tasks to bundle the build and all dependencies in formats like zip.

line 16 says we will get dependencies from jcenter. this can also be changed to mavenCentral

lines 19-28 are probably the ones you will edit the most because all external dependencies are listed here

line 32 says what class has the public static void main method.

lines 35-38 specify we will use JUnit 5 for unit tests

lets take another look at the structure of the unzipped folder

all of the application's source code (main and test) exist under the project folder (app) then src

the main code is what the end user executes at runtime

test is for the unit tests. the packages here mirror what is in src/main. this is for validation of the code at development time through unit tests
the test code is not delivered to the end user or used to generate class files or jar files

the sample code is basically a Hello World, so we'll build, test, and run now.

Open a terminal in the unzipped directory.
I like to run testClasses first. This ensures that all the code -- both src/main and src/test compiles.

oops.... I don't have a JAVA_HOME environment variable setup.

so I downloaded OpenJDK 15 and then will set the environment variable.

I have chocolatey installed which comes with refreshenv so this process can see the new environment variables. If you don't have this, you have to start a new terminal to see new environment variables.

Now testClasses is working.

This is the first time gradlew was invoked on this project and I don't yet have Gradle 6.7 so the gradle-wrapper.jar downloads it for me.

src/main and src/test compile.

gradlew test runs the unit tests and they pass

gradlew tasks shows the available tasks we can run

of note is the run task that will run our main method

and the distribution tasks compile and package our deployment into a single directory or file.

gradlew run
prints the Hello World message
I don't know why the first time it was a little off in the Hello World message. subsequent runs after that did not do the same thing. This could be a terminal issue. Comment if you know why.

Here is the src/main main code.

Here it is running a couple more times.

The application plugin configured in build.gradle gives us the installDist task so you can give you user a single directory with everything they need (except Java)

installDist

Now the directory you give them is build/install
it has platform-specific scripts for starting your program on Windows and Linux.
all your Java dependencies are in the lib directory

The application plugin also provides the distZip task
distZip is more convienient than installDist because the result is a single zip file which is easier to transfer.
its basically the exact same as installDist except the output directory is zip archived
you can find the resulting zip in build/distributions


The Gradle initializr is a web interface for what you could do from the command line if you already had Gradle installed.
It doesn't have all the options that the command line does, but it does have the typical options in an arguably better interface.
Beyond the interface, the main advantage is that you don't have to have gradle installed prior to making the project.