You are free to use any of the standard Spring Framework     
techniques to define your beans and their injected dependencies.     
For simplicity, we often find that using @ComponentScan     
(to find your beans) and using @Autowired (to do constructor     
injection) works well.

If you structure your code as suggested above (locating your     
application class in a root package), you can add @ComponentScan     
without any arguments. All of your application components     
(@Component, @Service, @Repository, @Controller etc.) are     
automatically registered as Spring Beans.

The following example shows a @Service Bean that uses     
constructor injection to obtain a required RiskAssessor bean:

If a bean has one constructor, you can omit the @Autowired,     
as shown in the following example:

Notice how using constructor injection lets the riskAssessor     
field be marked as final, indicating that it cannot be     
subsequently changed.

Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added. For example, if HSQLDB is on your classpath, and you have not manually configured any database connection beans, then Spring Boot auto-configures an in-memory database.

You need to opt-in to auto-configuration by adding     
the @EnableAutoConfiguration or @SpringBootApplication     
annotations to one of your @Configuration classes.

You should only ever add one @SpringBootApplication or     
@EnableAutoConfiguration annotation. We generally     
recommend that you add one or the other to your primary     
@Configuration class only.

Auto-configuration is non-invasive. At any point, you can start     
to define your own configuration to replace specific parts of the     
auto-configuration. For example, if you add your own DataSource bean,     
the default embedded database support backs away.

If you need to find out what auto-configuration is currently      
being applied, and why, start your application with the --debug switch.     
Doing so enables debug logs for a selection of core loggers and logs     
a conditions report to the console.

If you find that specific auto-configuration classes that you     
do not want are being applied, you can use the exclude attribute    
 of @EnableAutoConfiguration to disable them, as shown in the     
 following example:

If the class is not on the classpath, you can use the excludeName     
attribute of the annotation and specify the fully qualified name     
instead. Finally, you can also control the list of auto-configuration     
classes to exclude by using the spring.autoconfigure.exclude property.

You can define exclusions both at the annotation level and by     
using the property.

Spring Boot favors Java-based configuration. Although it is     
possible to use SpringApplication with XML sources, we generally     
recommend that your primary source be a single @Configuration class.     
Usually the class that defines the main method is a good candidate     
as the primary @Configuration.

You need not put all your @Configuration into     
a single class. The @Import annotation can be     
used to import additional configuration classes.     
Alternatively, you can use @ComponentScan to automatically     
pick up all Spring components, including @Configuration classes.

We recommend that you follow Java’s recommended package naming     
conventions and use a reversed domain name (for example,     
com.example.project).

If you absolutely must use XML based configuration, we recommend     
that you still start with a @Configuration class. You can then     
use an @ImportResourceannotation to load XML configuration files.

Spring Boot does not require any specific code layout to work.     
However, there are some best practices that help.

When a class does not include a package declaration, it is     
considered to be in the “default package”. The use of the     
“default package” is generally discouraged and should be     
avoided. It can cause particular problems for Spring Boot     
applications that use the @ComponentScan, @EntityScan, or @SpringBootApplicationannotations, since every class     
from every jar is read.

We recommend that you follow Java’s recommended package naming     
conventions and use a reversed domain name (for example,     
com.example.project).

We generally recommend that you locate your main application     
class in a root package above other  classes .The @SpringBootApplication annotation is often placed     
on your main class, and it implicitly defines a base “search     
package” for certain items. For example, if you are writing a     
JPA application, the package of the @SpringBootApplication annotated     
class is used to search for @Entity items. Using a root package also     
allows component scan to apply only on your project.

If you don’t want to use @SpringBootApplication,     
the @EnableAutoConfiguration and @ComponentScan     
annotations that it imports defines that behaviour     
so you can also use that instead.

The following listing shows a typical layout:

com
 +- example
     +- myapplication
         +- Application.java
         |
         +- customer
         |   +- Customer.java
         |   +- CustomerController.java
         |   +- CustomerService.java
         |   +- CustomerRepository.java
         |
         +- order
             +- Order.java
             +- OrderController.java
             +- OrderService.java
             +- OrderRepository.java

The Application.java file would declare the main method,     
along with the basic @SpringBootApplication, as follows:

Starters are a set of convenient dependency descriptors that     
you can include in your application. You get a one-stop shop     
for all the Spring and related technologies that you need     
without having to hunt through sample code and copy-paste     
loads of dependency descriptors. For example, if you want     
to get started using Spring and JPA for database access,     
include the spring-boot-starter-data-jpa dependency in your project.

The starters contain a lot of the dependencies that you need     
to get a project up and running quickly and with a consistent,     
supported set of managed transitive dependencies.

What’s in a name
All official starters follow a similar naming pattern;     
spring-boot-starter-*, where * is a particular type of     
application. This naming structure is intended to help     
when you need to find a starter. The Maven integration     
in many IDEs lets you search dependencies by name. For     
example, with the appropriate Eclipse or STS plugin installed,     
you can press ctrl-space in the POM editor and type     
“spring-boot-starter” for a complete list.
As explained in the “Creating Your Own Starter” section,     
third party starters should not start with spring-boot,     
as it is reserved for official Spring Boot artifacts. Rather,     
a third-party starter typically starts with the name of the project.     
For example, a third-party starter project called thirdpartyproject     
would typically be named thirdpartyproject-spring-boot-starter.

The following application starters are provided by Spring Boot    
under the org.springframework.boot group:

In addition to the application starters, the following     
starters can be used to add production ready features:

Table 13.2. Spring Boot production starters

Finally, Spring Boot also includes the following starters that can be used if you want to exclude or swap specific technical facets:

Table 13.3. Spring Boot technical starters

For a list of additional community contributed starters, see the     
README file in the spring-boot-starters module on GitHub.

To learn about using Spring Boot with Gradle, please refer     
to the documentation for Spring Boot’s Gradle plugin:

It is possible to build a Spring Boot project using Apache Ant+Ivy.     
The spring-boot-antlib “AntLib” module is also available to help     
Ant create executable jars.
To declare dependencies, a typical ivy.xml file looks something     
like the following example:

A typical build.xml looks like the following example:

If you do not want to use the spring-boot-antlib module,     
see the Section 86.9, “Build an Executable Archive from     
Ant without Using spring-boot-antlib” “How-to” .

This section goes into more detail about how you should use     
Spring Boot. It covers topics such as build systems, auto-configuration,     
and how to run your applications. We also cover some Spring Boot     
best practices. Although there is nothing particularly special about     
Spring Boot (it is just another library that you can consume),     
there are a few recommendations that, when followed, make your     
development process a little easier.

It is strongly recommended that you choose a build system that     
supports dependency management and that can consume artifacts     
published to the “Maven Central” repository. We would recommend     
that you choose Maven or Gradle. It is possible to get Spring Boot     
to work with other build systems (Ant, for example), but they are     
not particularly well supported.

Each release of Spring Boot provides a curated list of     
dependencies that it supports. In practice, you do not     
need to provide a version for any of these dependencies     
in your build configuration, as Spring Boot manages that     
for you. When you upgrade Spring Boot itself, these     
dependencies are upgraded as well in a consistent way.

You can still specify a version and override Spring Boot’s     
recommendations if you need to do so.

The curated list contains all the spring modules that you can use     
with Spring Boot as well as a refined list of third party libraries.     
The list is available as a standard Bills of Materials (spring-boot-    
dependencies) that can be used with both Maven and Gradle.

Each release of Spring Boot is associated with a base version of the     
Spring Framework. We highly recommend that you not specify its version

Maven users can inherit from the spring-boot-starter-parent     
project to obtain sensible defaults. The parent project     
provides the following features:

•	Java 1.8 as the default compiler level.
•	UTF-8 source encoding.
•	A Dependency Management section, inherited from the spring-boot-dependencies    
 pom, that manages the versions of common dependencies. This dependency management     
 lets you omit <version> tags for those dependencies when used in your own pom.
•	Sensible resource filtering.
•	Sensible plugin configuration (exec plugin, Git commit ID, and shade).
•	Sensible resource filtering for application.properties and application.yml including profile-specific files    
(for example, application-dev.properties and application-dev.yml)

Note that, since the application.properties and application.yml     
files accept Spring style placeholders (${… }), the Maven filtering     
is changed to use @..@placeholders. (You can override that by setting     
a Maven property called resource.delimiter.)

To configure your project to inherit from the     
spring-boot-starter-parent, set the parent as follows:

You should need to specify only the Spring Boot version number     
on this dependency. If you import additional starters, you can     
safely omit the version number.

With that setup, you can also override individual dependencies     
by overriding a property in your own project. For instance, to     
upgrade to another Spring Data release train, you would add the     
following to your pom.xml:

Check the spring-boot-dependencies pom for a list of supported properties.

Not everyone likes inheriting from the spring-boot-starter-parent     
POM. You may have your own corporate standard parent that you need     
to use or you may prefer to explicitly declare all your Maven configuration.

If you do not want to use the spring-boot-starter-parent, you can     
still keep the benefit of the dependency management (but not the     
plugin management) by using a scope=import dependency, as follows:

The preceding sample setup does not let you override individual     
dependencies by using a property, as explained above. To achieve     
the same result, you need to add an entry in the dependencyManagement     
of your project before the spring-boot-dependencies entry.     
For instance, to upgrade to another Spring Data release train,     
you could add the following element to your pom.xml:

In the preceding example, we specify a BOM, but any     
dependency type can be overridden in the same way.

Spring Boot includes a Maven plugin that can package the project     
as an executable jar. Add the plugin to your <plugins> section if     
you want to use it, as shown in the following example:

If you use the Spring Boot starter parent pom, you need     
to add only the plugin. There is no need to configure it     
unless you want to change the settings defined in the parent.

We finish our example by creating a completely self-contained     
executable jar file that we could run in production. Executable     
jars (sometimes called “fat jars”) are archives containing your     
compiled classes along with all of the jar dependencies that your     
code needs to run.

Java does not provide a standard way to load nested jar files (jar     
files that are themselves contained within a jar). This can be     
problematic if you are looking to distribute a self-contained application.    
To solve this problem, many developers use “uber” jars. An uber     
jar packages all the classes from all the application’s dependencies     
into a single archive. The problem with this approach is that it     
becomes hard to see which libraries are in your application.     
It can also be problematic if the same filename is used (but     
with different content) in multiple jars.
Spring Boot takes a different approach and lets you actually     
nest jars directly.

To create an executable jar, we need to add the     
spring-boot-maven-plugin to our pom.xml. To do so,     
insert the following lines just below the dependenciessection:

The spring-boot-starter-parent POM includes <executions>     
configuration to bind the repackage goal. If you do not     
use the parent POM, you need to declare this configuration     
yourself. See the plugin documentation for details.

Save your pom.xml and run mvn package from the command line, as follows:

If you look in the target directory, you should see     
myproject-0.0.1-SNAPSHOT.jar. The file should be around     
10 MB in size. If you want to peek inside, you can use     
jar tvf, as follows:

You should also see a much smaller file named myproject-0.0.1-    
SNAPSHOT.jar.original in the target directory. This is the original     
jar file that Maven created before it was repackaged by Spring Boot.    
To run that application, use the java -jar command, as follows:

As before, to exit the application, press ctrl-c.

Hopefully, this section provided some of the Spring Boot basics     
and got you on your way to writing your own applications. If you     
are a task-oriented type of developer, you might want to jump over to spring.io and check out some of the getting started guides that     
solve specific “How do I do that with Spring?” problems. We also     
have Spring Boot-specific “How-to” reference documentation.

The Spring Boot repository also has a bunch of samples you can run.     
The samples are independent of the rest of the code (that is, you     
do not need to build the rest to run or use the samples).

Otherwise, the next logical step is to read Part III, “Using Spring     
Boot”. If you are really impatient, you could also jump ahead and     
read about Spring Boot features.

At this point, your application should work. Since you used the     
spring-boot-starter-parent POM, you have a useful run goal that you     
can use to start the application. Type mvn spring-boot:run from the     
root project directory to start the application. You should see output     
similar to the following:

If you open a web browser to localhost:8080, you should see     
the following output:

To gracefully exit the application, press ctrl-c.

To finish our application, we need to create a single Java file.     
By default, Maven compiles sources from src/main/java, so you need     
to create that folder structure and then add a file named     
src/main/java/Example.java to contain the following code:

Although there is not much code here, quite a lot is going on.     
We step through the important parts in the next few sections.

The first annotation on our Example class is @RestController.     
This is known as a stereotype annotation. It provides hints     
for people reading the code and for Spring that the class plays     
a specific role. In this case, our class is a web @Controller,     
so Spring considers it when handling incoming web requests.

The @RequestMapping annotation provides “routing” information.     
It tells Spring that any HTTP request with the / path should be     
mapped to the home method. The@RestController annotation tells     
Spring to render the resulting string directly back to the caller.

The @RestController and @RequestMapping annotations are Spring     
MVC annotations. (They are not specific to Spring Boot.) See     
the MVC sectionin the Spring Reference Documentation for more details.

The second class-level annotation is @EnableAutoConfiguration.     
This annotation tells Spring Boot to “guess” how you want to     
configure Spring, based on the jar dependencies that you have added.     
Since spring-boot-starter-web added Tomcat and Spring MVC,     
the auto-configuration assumes that you are developing a web     
application and sets up Spring accordingly.

Starters and Auto-Configuration
Auto-configuration is designed to work well with “Starters”, but     
the two concepts are not directly tied. You are free to pick and     
choose jar dependencies outside of the starters. Spring Boot still     
does its best to auto-configure your application.

The final part of our application is the main method. This is     
just a standard method that follows the Java convention for an     
application entry point. Our main method delegates to Spring    
Boot’s SpringApplication class by calling run. SpringApplication     
bootstraps our application, starting Spring, which, in turn,     
starts the auto-configured Tomcat web server. We need to pass     
Example.class as an argument to the run method to tell     
SpringApplication which is the primary Spring component. The     
args array is also passed through to expose any command-line arguments.