Application Build Process

Relevant source files

The following files were used as context for generating this wiki page:

• Part1/API/gradlew.bat
• README.md
• Part1/API/src/main/java/com/example/api/ApiApplication.java
• Part1/API/src/main/resources/api-spec.yaml
• Part1/API/src/test/java/com/example/api/ApiApplicationTests.java
• Part1/API/src/main/java/com/example/api/config/DataLoader.java

Introduction

The application build process for the SafeDispatch HQ Administration API is centered around the Gradle build tool, utilizing a wrapper-based execution model to ensure consistency across environments. This process encompasses environment validation, dependency management via the Gradle wrapper, and the execution of the Spring Boot application lifecycle.

The build and deployment pipeline is integrated with GitLab CI/CD, providing automated testing, Static Application Security Testing (SAST), and deployment capabilities to cloud platforms such as Kubernetes, Amazon EC2, or Amazon ECS.
Sources: README.md:28-36, Part1/API/gradlew.bat:1-30

Gradle Build Infrastructure

The project utilizes the Gradle Wrapper (gradlew.bat for Windows) to manage the build environment without requiring a pre-installed Gradle instance on the host machine.

Execution Logic

The build script performs several environment checks before executing the build:

1. Environment Setup: It sets a local scope for variables and resolves the application home directory.
2. Java Validation: It searches for java.exe via the JAVA_HOME environment variable or the system PATH. If no valid Java installation is found, the process fails with a descriptive error.
3. JVM Configuration: Default JVM options are set to -Xmx64m and -Xms64m to control memory allocation during the build.
4. Wrapper Execution: The script executes the gradle-wrapper.jar located in the gradle/wrapper/ directory, passing all command-line arguments to the build system.

Sources: Part1/API/gradlew.bat:30-85

Build Script Flow

The following diagram illustrates the initialization logic within the Windows build script:

Application Runtime Configuration

The build results in a Spring Boot application entry point defined in ApiApplication.java. The build process ensures that all components, including security configurations and data loaders, are compiled and ready for the Spring container.

Component Summary

Component	Type	Responsibility
ApiApplication	Main Class	Entry point for the Spring Boot application.
DataLoader	Configuration	Automatically populates the database with initial HR and Manager users on startup if empty.
api-spec.yaml	Documentation	Defines the OpenAPI 3.0.3 specification for the REST API.
ApiApplicationTests	Test	Basic context-loading test to verify build integrity.

Sources: Part1/API/src/main/java/com/example/api/ApiApplication.java:1-13, Part1/API/src/main/java/com/example/api/config/DataLoader.java:13-33, Part1/API/src/main/resources/api-spec.yaml:1-10

Initialization Sequence

Upon successful build and execution, the application follows a specific initialization sequence to prepare the environment.

Continuous Integration and Deployment

The project's build process is designed to work with GitLab CI/CD. The configuration supports:

• Static Analysis: Automated code analysis using SAST to identify vulnerabilities.
• Automated Testing: Execution of test suites such as ApiApplicationTests during the pipeline.
• Auto Deploy: Capabilities to deploy to containerized environments (Kubernetes) or cloud instances (EC2/ECS).

Sources: README.md:30-34, Part1/API/src/test/java/com/example/api/ApiApplicationTests.java:1-13

Conclusion

The build process for the SafeDispatch HQ Administration API leverages standard Gradle wrapper scripts to ensure a portable and consistent environment. By integrating environment checks, automated data initialization, and modern CI/CD practices, the system maintains high reliability from the local development stage through to cloud deployment.