Build the smallest useful Spring Boot application.

Project shape

Three files are enough for the first run.

orders/
├── pom.xml
└── src/main/
    ├── java/com/example/orders/
    │   └── OrdersApplication.java
    └── resources/
        └── application.properties

The application class sits in the root package com.example.orders. Later components should live in that package or one of its subpackages so the default scan can find them.

Maven's standard layout separates Java source from runtime resources. Package names belong to Java; folders mirror those packages. Properties are resources placed on the classpath, so they live below src/main/resources rather than inside a Java package.

Maven responsibilities

The parent supplies build defaults; the starter supplies libraries.

These three entries solve different build problems. The parent controls Maven defaults, the starter contributes dependencies to the application classpath, and the plugin changes how the application is run and packaged. Removing one does not mean the other two take over its job.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <!-- No version here -->
</dependency>

The starter version is omitted because the Boot parent manages a tested set of versions. If every Spring library were versioned independently, Maven could resolve a combination that compiles poorly or fails at runtime.

The application annotation

@SpringBootApplication combines three roles.

Conceptually, the composed annotation gives the application class the same three roles as the explicit form below:

@Configuration
@EnableAutoConfiguration
@ComponentScan
public class OrdersApplication {
    // ...
}

Use @SpringBootApplication for the normal entry point. The expanded form is useful for understanding, not a recommendation to replace the composed annotation in every project.

package com.example.orders;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class OrdersApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrdersApplication.class, args);
    }
}

SpringApplication.run(...) creates and refreshes an ApplicationContext. The method returns the context, but normal business code receives beans through injection instead of retrieving them manually.

Startup, step by step

SpringApplication.run builds and refreshes the container.

1. 01

   Inspect the classpath

   Boot determines whether this looks like a servlet web application, reactive web application or non-web application.

2. 02

   Prepare the environment

   Command-line arguments, system values and application properties become available as configuration.

3. 03

   Create the appropriate ApplicationContext

   This project gets a non-web context because no servlet or reactive web application stack is present.

4. 04

   Load bean definitions

   The application configuration, component scan results and matching auto-configurations contribute recipes for objects.

5. 05

   Refresh the context

   Spring creates non-lazy singleton beans, resolves constructor dependencies and runs lifecycle callbacks.

6. 06

   Run startup callbacks

   Boot invokes CommandLineRunner and ApplicationRunner beans after successful startup.

This is why a missing dependency usually prevents startup: the context must build a complete valid graph before the application begins normal work.

The scan boundary

The application class location is an architectural decision.

com.example.orders
├── OrdersApplication              // scan starts here
├── notification
│   └── EmailNotificationSender    // included
├── service
│   └── OrderService               // included
└── runner
    └── DemoRunner                 // included

com.example.payments
└── PaymentService                 // not included

@ComponentScan begins with the package containing OrdersApplication. It walks downward through subpackages; it does not walk upward to com.example and then down into sibling packages.

Predict startup behaviour

No servlet classes means no embedded web server.

Auto-configuration reacts to what is available. With only spring-boot-starter, Boot creates a non-web application context, logs that the application started and then exits when no non-daemon work remains. Adding web libraries later changes the conditions that match.

@SpringBootApplication is present in all three cases. The annotation does not mean “start Tomcat.” It enables conditional configuration; the classpath supplies evidence about which kind of application is being built.

The first property

application.properties changes configuration, not Java structure.

spring.application.name=orders

The application name can appear in logging, metrics and other infrastructure. It does not rename the Java class, Maven artifact or package. Those are separate identities that happen to use a consistent name in this example.

Maven artifact:     orders
Java class:        OrdersApplication
Java package:      com.example.orders
Spring property:   spring.application.name=orders