Implies major versioning, dependency management, plugin configuration, build lifecycle and finally release management. If available and feasible external tools, i.e. plugins, like the OpenAPI Generator are integrated into the lifecycle to generate code for subsequent modules.

Apache Camel has a very powerful bean injection framework to allow developers to focus on solving business problems. At its core, Apache Camel is an integration engine, which can be used to facilitate interactions between a wide and varied array of technologies. These bridges between service- and technology Endpoints, the Routes are implemented on an engine - the CamelContext, and they communicate with Exchange Messages.

In this repository Camel is used to glue independantly developed Units together.

Camel allows you to define your data flow as a declarative route for complex integration and routing work, and then handing off the final business logic to standard Spring components like Controllers or Services. While Spring Boot handles the lifecycle and dependency injection in the Spring context, dependency injection, and application startup.

check out camel-spring-boot

Spring Boot component provides auto-configuration for Apache Camel. Our opinionated auto-configuration of the Camel context auto-detects Camel routes available in the Spring context and registers the key Camel utilities (like producer and consumer templates, type converters etc.) as @Bean.

The Maven Bill of Materials (BOM) is collected the root pom.xml file, i.e. aggregator POM that defines common dependencies, versions, properties and other dependent Maven Projects. It is considered good development practice to run mvn clean install in the repository root directory in order to create all artifacts in the local .m2/repository. This substitutes a Nexus Server usually providing released artifacts. After that the developer can exclusively focus on the project s/he is assigned to.

see structuring Maven projects and modules

For team development you should work with the -SNAPSHOT tag and a central (Nexus) Server over your personal .m2 repo. This way all team members are accessing the same (continuously changeing) artifact and the complete build process can be reduced to the module and artifact in focus.

The parent project is the first module called in the build process.
It starts by running the os-maven-plugin (actually a Maven <extension>)

which provides Maven parameters, like ${os.detected.name},
to direct the build lifecycle as required for your targeted system.

And it helps to detect and identify problems in different environments.
For exmple the build on github actions is running on ubuntu-latest and
the build on the local machine (above) is running on ubuntu 22.04.
If you look at the build on github actions you can locate differences in the build-and-release workflow

Dotfiles are text-based configuration files (e.g. .gitignore) for Unix-like systems,
named after the "." prefix that hides them.

Dotfiles are also part of this repository to serve various purposes.

The complete project is documented in AsciiDoc or .adoc files. This is the broader approach to technical documents than markdown and you can find everything in the AsciiDoc Language Documentation:

It is important to understand that .adoc files are source files that should be processed to some target format. This processor is called the Asciidoctor and described in the AsciiDoctor Documentation:

Goto projects AsciiDoctor implementation and usage

that’s about all there is to say about this software.

Find more at github

The idea is to describe charts with the mermaid syntax

and our Maven Plugin combination of AsciiDoc and Mermaid will generate html pages with SVG graphics on the fly:

There is also a live editor for interactive chart creation.

The Maven Installation is part of the Maven AsciiDoc installation and details can be found in its description AsciiDoctor implementation and usage.

The complete Traccar REST API is defined in a single openapi.yaml file This file is used with the OpenAPI Generator to generate a plain Java Client. The generation is controlled and configured via openapi-generator-maven-plugin and produces a traccar-api-generated-x.y.z.jar (in two steps).

details …​

There are many code formatters and formats out there. Just like in the jeets project we chose the fmt-maven-plugin

The choice is based on simplicity and the most common code style with Google Java Style.
The plugin is strict about styling, cannot be configured by design and automatically formats the code before compilation.

The Traccar Clients are basically an interface between REST and Java passing Entities. Therefor there is no need for cumbersom JUnit test setups or mocking to test the technology we rely on. The functionality is achieved by wiring diffent technology components together, configure and run them.

The Traccar Client is not a software with complex implementations of Java Units. Actually it is merely an interface between REST and Java passing Entities. The functionality is achieved by wiring diffent technology components together, configure and run them.

For example the Camel RestOpenApiComponent is already being tested with each Camel build. These tests should not be repeated. see RestOpenApiComponent JUnit tests

The following steps cover the vital coordinates.

If you want to delve into a multi module project you should initially build the complete repo on your machine. Then you will have all artifacts in your .m2 repo and can focus on coding inside a single project domain. The Reactor will pull the required jars for this project.

During development you don’t want to bother building the repo from scratch for every code change.
For example you might create a test-jar which can be used with classifier 'tests' in anthor project. Then this test-jar must be published to local repo to be used elsewhere in the repo.

For example we can produce a test-jar in the gps-osmand-tracker build to provide a TrackerRegistration in higher level tests. Then you can add the test-jar to the test section with with classifier 'tests' to pick up the package.

From the repository root /bm, either:

To make sure that the complete project is build with a specified Maven Version it is possible to add a Maven Wrapper with a determined version.

Simply run this from the root directory

to get

Now we can build the complete multimodule project from the root with

And you can build any subproject from the root with

Or, better, if you are working inside a subproject like the gps-osmand-tracker

Note that you reference the mvnw in the root by going up two folders with ../../
depending on where you are working from the command line.

Since this setup is generally idempotent the wrapper can be upgraded anytime with

Then the next build will pick up the required files.