Spring PetClinic ships no Dockerfile, and Gradle cannot rebuild its CSS

Java 17, a wrapper script, and port 8080

PetClinic is a Spring Boot application built with Maven or Gradle. Java 17 or later is required for the build, and the application runs on Java 17 or newer. For the IDE route the prerequisite is a full JDK rather than a JRE, as the README lists a full JDK, not a JRE.

Cloning and starting it takes two commands, and you use the wrapper scripts in the repository root rather than a system Maven:

git clone https://github.com/spring-projects/spring-petclinic.git
cd spring-petclinic

On Maven:

./mvnw spring-boot:run

On Gradle:

./gradlew bootRun

Either way the application answers at http://localhost:8080/, and the same run works from an IDE. Eclipse and STS users import it as an existing Maven project, IntelliJ users open pom.xml and run the PetClinicApplication main class, and VS Code is on the supported list too.

The default H2 database dies with the process

In its default configuration PetClinic uses an in-memory H2 database which gets populated at startup. The connection string carries a UUID, `jdbc:h2:mem:<uuid>`, and that UUID is printed to the console at startup so you can paste it into the H2 console exposed at http://localhost:8080/h2-console.

Two consequences follow. Owners and visits you add while the app runs are gone when the process restarts, because nothing was ever written to disk. And the H2 console is reachable on the default profile, which is fine on a laptop and a hole if you deploy that profile unchanged. This database is a fixture for demos and tests, not a store.

Changing database means setting spring.profiles.active

Persistent storage comes from MySQL or PostgreSQL, and picking one is not a matter of editing a connection string. Whenever the database type changes the app has to run with a different profile, `spring.profiles.active=mysql` or `spring.profiles.active=postgres`. Miss the flag and you are still on H2, which is a confusing way to lose an afternoon of data entry.

The repository ships a docker-compose.yml with one service named after each profile:

docker compose up mysql

docker compose up postgres

Or start the engine yourself against the image tag the project pins:

docker run -e MYSQL_USER=petclinic -e MYSQL_PASSWORD=petclinic -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=petclinic -p 3306:3306 mysql:9.7

Further setup documentation for each engine is a text file under src/main/resources/db, one directory per engine (db/mysql and db/postgres). The compose file takes a shortcut with the root password that the last section covers.

No Dockerfile in the tree, so the build plugin makes the image

There is no Dockerfile in this project. The image comes out of the Spring Boot build plugin instead, so the image is produced by the plugin rather than from a Dockerfile in the repository.

./mvnw spring-boot:build-image

Then confirm the image landed and start it:

docker images | grep petclinic
docker run -p 8080:8080 docker.io/library/spring-petclinic:latest

The `docker.io/library` prefix in that run command tells you the artifact name the plugin chose, and that is the naming you inherit as long as you keep using it. Port 8080 is mapped explicitly, so it collides with anything else already holding that port. The repository has no Dockerfile to start from.

Only Maven can recompile petclinic.css

The stylesheet is generated, not hand written. `petclinic.css` lives in src/main/resources/static/resources/css and was produced from `petclinic.scss` combined with the Bootstrap library. Edit the scss or upgrade Bootstrap and the served CSS stays stale until you recompile it.

Maven has a profile for the job:

./mvnw package -P css

Inside Eclipse or IntelliJ the same work happens by generating resources first:

./mvnw generate-resources

There is no build profile for Gradle to compile the CSS. A Gradle contributor who edits petclinic.scss, runs ./gradlew bootRun and refreshes the browser sees the old stylesheet with no error anywhere, because the Gradle build never had that step to fail. The workaround is to use the Maven wrapper (./mvnw) for CSS work.

The linked slide deck shows the pre-Spring Boot version

The most prominent link at the top of the repository is a slide deck about understanding the PetClinic application with a few diagrams. The note directly beneath it says those slides refer to a legacy, pre-Spring Boot version and may not reflect the current Spring Boot based implementation, and it sends you back to the repository and its documentation for anything up to date.

That warning is easy to skim past, because the deck looks authoritative. A reader who starts there may get an architecture that does not match the current code. The project's own answer to that gap is that you learn the current version by reading the repository.

The compose file starts MySQL with an empty root password

docker-compose.yml is worth reading before you copy it. The mysql service sets MYSQL_ROOT_PASSWORD to an empty value and turns on MYSQL_ALLOW_EMPTY_PASSWORD, while the application user is petclinic with the password petclinic. The postgres service sets POSTGRES_PASSWORD to petclinic with the same user and database name, and both services publish their port straight to the host.

That is a reasonable trade on a laptop, where the data is disposable and the port is yours alone. It stops being reasonable the moment the file becomes a template: a CI job that reuses docker-compose.yml gets a database whose root account has no password, on whatever runner executes it. Change the credentials in your own copy before that file reaches a shared repository or a build server.

Editorial conclusion

PetClinic is worth cloning as a reference for how a Spring Boot application is laid out, wired to a database and packaged, and it is a poor foundation for anything you intend to ship, because the H2 default, the empty MySQL root password in docker-compose.yml and the missing Dockerfile are demo conveniences you would have to undo. Before you build on it, check the two gaps that cost the most time: whether your IDE needs ./mvnw generate-resources before the stylesheet appears, and whether you have settled on a real database profile, since spring.profiles.active=mysql is what turns off the in-memory H2 fixture.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases