eugenp/tutorials: a Maven profile map for a very large Java sample repository

What eugenp/tutorials actually is, and who it is for

The README describes the project as a collection of small and focused tutorials, each covering a single and well-defined area of development in the Java ecosystem, with a strong focus on Spring, Spring Boot and Spring Security. It is not a framework, a library you add to a classpath, or an application you deploy. It is a monorepo of independent sample modules, and the top-level directory listing bears that out: apache-kafka, apache-poi, core-java-modules, data-structures, deeplearning4j, docker-modules, drools, geotools and many more sit side by side.

The audience is therefore narrow and specific. You are a Java developer who wants to see one topic wired up in working code: a Kafka producer, a POI spreadsheet writer, a specific Spring Security configuration. You are not looking for a maintained product to depend on. The repository is not archived, but the README gives no last push date, so no claim about how frequently it changes can be made from what is documented. Treat each module as a snapshot of an approach rather than a dependency with a release cadence.

Why profile-based segregation exists in this repository

A repository holding hundreds of unrelated modules cannot be built as one Maven reactor without pain. Modules target different JDK versions, some are long running, and running every integration test on every change would be impractical. The README states that Maven build profiles are used to segregate the huge list of individual projects.

The segregation works on two axes. First, projects are divided into eight broad lists: default, default-jdk17, default-jdk22, default-jdk23, default-jdk24, default-jdk25, default-jdk8 and default-heavy. Second, each list is split by test type, so a profile ending in integration enables integration tests while the plain profile enables unit tests. The README's table totals 17 profiles, including a parents profile that builds only parent modules and enables no tests at all. Note that the profile table lists default-jdk26 while the prose list of eight broad lists stops at default-jdk25; that inconsistency is in the README itself, and it is a good reason to read the actual pom files rather than trusting the table alone.

The practical consequence is that the profile name encodes both the JDK the module expects and the test scope you want. Getting the profile wrong means either a compile failure on an unsupported JDK or a build that silently skips the tests you care about.

Building the whole repository or one module

The README is explicit that building everything at once should rarely be necessary, since you are usually concerned with a specific module. When you do want a full build with unit tests only, the documented command is run from the repository root:

mvn clean install -Pdefault,default-heavy

For integration tests across the repository the README gives the parallel form:

mvn clean install -Pintegration,integration-heavy

The JDK8 lists have their own pair, `mvn clean install -Pdefault-jdk8` and `mvn clean install -Pintegration-jdk8`.

For everyday work the documented approach is to change into the module directory and run `mvn clean install` there, which runs that module's unit tests. Spring modules also run the SpringContextTest if one is present. There is a trap the README names directly: if your module belongs to a parent module such as `parent-boot-1` or `parent-spring-5`, you must build the parent first. The `parents` profile exists for exactly that, via `mvn clean install -Pparents`.

Building selected modules from the root, and running a Spring Boot module

When you want to stay at the repository root but build only a few modules, the README shows Maven's project list flag combined with a profile:

mvn clean install --pl akka-modules,algorithms-modules -Pdefault

Here `akka-modules` and `algorithms-modules` are the modules to build and `default` is the profile they belong to. The two must agree: naming a module that is not in the profile you pass will not produce the build you expect.

To start a Spring Boot module, the documented command is run inside the module directory:

mvn spring-boot:run

The README says nothing about which port any module listens on, what environment variables it reads, or how to configure it. Those details live in each module's own resources, so check the module before assuming a default port.

On the IDE side the guidance is to import the single module you are working on into Eclipse or IntelliJ rather than importing the whole repository. That matches the structure: the modules are independent, and importing all of them would pull in unrelated JDK targets.

Clone failures and the git buffer setting

The README opens with a clone problem rather than with the tutorials themselves, which tells you something about the repository's size. If cloning fails, the documented workaround is to raise Git's HTTP post buffer:

git config --global http.postBuffer 5000000

The README states this increases the buffer from the default 1MiB to 5MiB, and gives the revert command as `git config --global http.postBuffer 1000000`. Two things are worth noting. The setting is global, so it affects every repository on your machine until you revert it. And the README does not explain which error message indicates a buffer problem, so you are expected to recognise it yourself. A shallow clone is not mentioned as an alternative, which is a gap for anyone who only wants one module.

Where this repository is the wrong tool

The limitations follow from the design. There is no versioned artifact to depend on, no release history in the README, and no compatibility promise between modules. If you need a Kafka client wrapper or a spreadsheet library, you take the upstream library and read the module as an example of wiring it up; you do not vendor the module.

The build model is also a real cost. A full repository build with integration tests enabled is described by the README as covering heavy and long running projects, and the profile names default-heavy and integration-heavy exist precisely because those modules are slow. CI for the whole repository is not something you should expect to run on a laptop in a coffee break. The Jenkinsfile at the top level confirms an automated build exists, but the README does not document what it runs or how long it takes.

Finally, the JDK split is a maintenance burden on the reader. Modules are spread across JDK8 through JDK26 profiles, so a snippet that compiles on your JDK21 toolchain may sit in a JDK8 list and use APIs you have moved past. The README gives no guidance on porting a module between profiles.

How this differs from a single Spring sample project

The obvious alternative is a dedicated Spring sample repository, such as the official spring-projects/spring-boot samples or a single-purpose starter repository. The difference is scope and coupling. A dedicated sample repository tracks one Spring Boot version, builds as one project, and its examples are consistent with each other. eugenp/tutorials tracks many versions at once, and the profile scheme is the mechanism that lets JDK8 code and JDK26 code live in the same clone.

That trade-off cuts both ways. You get breadth: Kafka, POI, Spark, Drools, GeoTools, deeplearning4j and dozens more in one place, each isolated. You lose coherence: there is no single Spring Boot version to reason about, and a module's dependencies are frozen at whatever version it was written against. If you want one clean, current example of a Spring feature, a single-version sample repository is easier to read. If you want to compare how the same concern is handled across library generations, the module-per-topic layout here is the reason the repository exists.

Licence and the cost of staying current

The repository is MIT licensed. For a collection of sample code that is permissive: you can copy a snippet into your own project without a copyleft obligation, subject to the usual requirement to keep the licence notice for substantial portions. This is not legal advice, and if you plan to redistribute a module wholesale, read the LICENSE file at the root yourself.

Upgrade cost is the harder question, and the README does not answer it. No releases are listed, and the README documents no migration path between JDK profiles. The profile table already disagrees with the prose list about whether default-jdk26 exists, which suggests the build configuration is edited in place rather than versioned. If you fork a module, you own its dependency upgrades; nothing in the README suggests upstream will do that for you.

Editorial conclusion

Use eugenp/tutorials if you want a reference implementation for one narrow Java or Spring topic and are willing to build only the module you need. Do not clone it expecting a single application, a supported library, or a fast full build. Before adopting a module, check its JDK target against the profile table in the README and confirm whether it sits under a parent module such as parent-boot-1 or parent-spring-5, because the README states the parent must be built first.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository