In this post, let’s discuss about how to create a new Spring project. It’s aimed for absolute beginners.
Common ways to create a new project
There are multiple ways to create a new Spring project. Let’s have a look at the common ones.
Creating from scratch
Because Spring projects are standard Java projects, you can create those just manually. In fact, the Spring guides like this one show how to do it that way. I won’t recommend it though, because there are easier ways.
Using SPRING INITIALIZR
For easily creating new Spring projects, Spring provides a Spring Initializr wizard at start.spring.io. The wizard creates a zip file that you can download, unzip and import in your IDE.
Using an IDE
IDEs go one step further. For example, Spring Tool Suite provides a Spring Starter Project wizard (available at File -> New -> Spring Starter Project), and Intellij IDEA provides a similar wizard (available at File -> New -> Project -> Spring Initializr), which actually use under the hood the same Spring Initializr service mentioned above.
Whichever wizard you use, you’ll need to fill there some data, as discussed below.
The name of the project. I’d recommend here using small alphanumeric characters and dashes only, e.g. np-spring5-tutorial.
It’s the build tool to use.
You’ll find here a couple of major options: Maven and Gradle. Maven is much more popular than Gradle, whereas Gradle is a newer one, which was introduced to address some of the things which Maven couldn’t do.
Unless there is a specific need for Gradle, I prefer to go with Maven, because it’s widely adopted and so has better tooling supports, more plugins etc.
You’ll find two options for packaging: JAR and WAR.
The executable of the generated application would be a fat JAR or WAR, with tomcat and all the dependent JARs embedded in it. That JAR or WAR can run standalone, with the standard java -jar xyz.jar command. This seems to be the preferable way of packaging web applications nowadays, because that eases deploying the applications, e.g. at cloud services like Pivotal Cloud Foundry.
JAR should be the preferred packaging, unless you plan to use JSP. You can always change the packaging later (in the generated pom.xml or build.gradle file), though.
Of course choose Java 1.8, although Spring 4.x still supports 6 and 7.
Group and Artifact
Group and Artifact uniquely identify a project. Group uniquely identifies a group to which the project belongs, whereas Artifact uniquely identifies the project inside the group.
A common practice to name a group is to begin it with a domain name owned by you, in reverse order. For example, as we own naturalprogrammer.com, we use a group name com.naturalprogrammer for all our spring projects. No problem if you don’t own a domain – just use some name that you feel will be unique. Unless the project is going to be used along with some other clashing projects, it will not be a problem.
For the artifact, I prefer to use a few small alphanumeric words separated by dashes, typically same as the name of the project – e.g. np-spring5-tutorial.
This will be the version of the project. It you are unsure what’s this, just leave it untouched.
A one line description of the project.
This will be the name of the root package of your application. The common practice for naming it is to join the group and the artifact in some way, e.g. com.naturalprogrammer.spring.tutorial. Remember that dashes (“-”) aren’t allowed here. You should either omit those, replace those with underscores, or do something about those.
This is the version of Spring Boot to use. Normally I’d choose the latest stable release when I’m developing a production app.
This section asks us to choose the dependencies, i.e. the Spring projects and other projects that will be used in our project. Whatever we pick here will go into the configuration file of the build tool. The build tool will then automatically fetch the needed JARs and put those in the classpath.
For example, here you can just pick Web for a simple web application, and more dependencies can always be added later (into the generated pom.xml or build.gradle file).
With the above data filled, you can then generate the project.
Generated source code
Browsing the generated source code of the project will tell you that it’s just a java project, with a standard maven directory layout.
At the root of the project, you’ll find a file named pom.xml (or build.gradle if you chose Gradle), which is the configuration file that Maven (or Gradle) uses to know about the project. It will have the data that was fed when creating the project.
Notice the dependencies section in pom.xml. This section tells Maven what all other projects this project depends on, so that Maven will pull the required JARs and put those in the classpath. Maven does this recursively, i.e., the JARs on which the dependencies depend on will also be pulled and put onto the classpath, and so on. If you had missed picking any dependency when filling the wizard, this is the place to add it.
Below the dependencies is a build section with the spring-boot-maven-plugin. That’s the plugin that’ll package the application as a fat JAR or WAR, which will have tomcat and all the dependent JARs embedded. That fat JAR can then be run just by using java -jar command.
The wizard will also have created a couple of Java classes. In one of those, there’ll be a main method in which you’ll see a call to SpringApplication.run. That statement would start your application.
Running the application
There will be multiple ways to run the application. If you’re using STS, using the Boot Dashboard seems to be the best one. There, you can select the project that you want to run, and then click on the debug (or run) button. Other ways to run the application in STS will be to select either the project or the main class, click on the Debug or Run button on the toolbar, and then to select either Java Application or Spring Boot App. You’ll get the same options if you right click on the project or the main class.
Share your comments!