.dockerignore1 dist ← root-level dist directories 2 doc ← documentation files 3 misc ← miscellaneous scripts/tools 4 tools ← build tooling 5 target ← root-level Maven target 6 */target ← target/ in any subdirectory 7 */*/target ← target/ 2 levels deep 8 build ← root-level Gradle build output 9 */build ← build/ in any subdirectory 10 */*/build ← build/ 2 levels deep 11 dist ← DUPLICATE: already excluded at line 1 12 */dist 13 */*/dist 14 projectforge-webapp/node_modules ← 300MB+ of npm dependencies 15 projectforge-webapp/package-lock.json
| Pattern | What it excludes | Why | Typical size |
|---|---|---|---|
target |
Maven build outputs | No Maven here (Gradle project) — but safety net | 0 (not applicable) |
build |
Gradle build outputs (classes/, libs/, tmp/) |
Regenerated every build; the JAR is already specified via COPY ${JAR_FILE} |
500MB+ |
dist |
Distribution-ready bundles | Not needed for Docker — the JAR is the distributable | Varies |
doc |
AsciiDoc documentation | No runtime purpose inside container | ~100KB |
misc, tools |
Helper scripts and tooling | Build-time only, not runtime | Small |
projectforge-webapp/node_modules |
All npm dependencies | The webapp is bundled into the JAR during Gradle build — raw node_modules/ not needed |
300MB+ |
projectforge-webapp/package-lock.json |
npm lock file | Build-time metadata, irrelevant at runtime | ~500KB |
dist entrydist. This is harmless (Docker ignores duplicates) but suggests the file was assembled incrementally — someone added the */dist and */*/dist deep-exclusion patterns later without removing the original top-level entry.Docker .dockerignore uses the same pattern syntax as .gitignore. The three-level approach is needed because build artifacts exist at multiple depths:
| Pattern | Matches | Does NOT match |
|---|---|---|
build | ./build/ | ./projectforge-webapp/build/ |
*/build | ./projectforge-webapp/build/ | ./tools/foo/build/ |
*/*/build | ./projectforge-webapp/sub/build/ | — |
Without the */*/build pattern, deeply nested build directories in multi-module Gradle projects could still leak into the context. With 20+ Gradle modules in ProjectForge, these deep patterns prevent the "one module sneaks through" problem.
docker build.dist appears twice — harmless but indicates incremental file assembly.
Excludes build artifacts, documentation, and tools from the Docker build context. Without this file, the entire project directory (~2GB+ of Gradle caches, build outputs, node_modules) would be sent to the Docker daemon before building starts — slowing down
docker buildand bloating the layer cache. With.dockerignore, only the files actually needed by the Dockerfile (JAR file, entrypoint.sh, environment.sh) are transferred.