Maven plugin which includes build-time git repository information into an POJO / *.properties). Make your apps tell you which version exactly they were built from! Priceless in large distributed deployments... :-)
1.7k
Stars
299
Forks
29
Open issues
30
Contributors
AI Analysis
This Maven plugin injects git repository metadata (commit hash, branch, timestamp, etc.) into the build process and runtime, enabling applications to report their exact build version in production environments. It's specialized for Java/Maven teams using distributed deployments who need version traceability; not useful for projects outside the Maven/Java ecosystem or those not requiring runtime version visibility.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Maven plugin that embeds git metadata into builds; mature, widely adopted in enterprise Java ecosystems
git-commit-id-maven-plugin solves a specific, well-defined problem: making git repository state (commit hash, branch, tags, build time) available at application runtime. This enables operators to identify exactly which code version is running in production—critical in large distributed systems. Named users include Spring Boot, Neo4j, and FoundationDB. The plugin is distributed via Maven Central, actively maintained, and has achieved stable product-market fit in the Java/Maven ecosystem.
Created in 2011 by @ktoso as a response to deployment visibility needs. Has been continuously maintained and refined over 15 years, accumulating 50+ contributors. Represents a solved problem with no significant architectural overhauls needed—the plugin does one thing well and has stayed focused.
Growth peaked earlier in the project lifecycle (pre-2020s) as Java microservices and containerization became standard practice. Current growth is flat (1 star in 7 days as of 2026-06-29), which is expected for a mature, feature-complete utility. The project has stabilized into low-velocity maintenance mode—bug fixes, dependency updates, and minor features rather than major innovation.
Production adoption is well-documented. README explicitly names Spring Boot (as upstream dependency), Neo4j, FoundationDB, Akamai, Sabre, EasyDITA as confirmed users. Maven Central distribution ensures discoverability. Spring Boot's inclusion of this plugin in official documentation is significant validation. However, no quantitative metrics (download counts, version distribution, deployment statistics) are publicly disclosed.
Appears to be a standard Maven Mojo that executes during the initialize phase, gathering git metadata via native git binaries or JGit library, then exporting as properties file and/or Java POJO. README indicates support for both code generation and resource loading paths. Likely uses JGit as fallback when native git unavailable, based on contributor notes mentioning 'native git support shipped'.
README does not document test coverage metrics. Build status badge present (passing on master). Contributor notes mention 'framework to do integration testing' was added by @mostr, but specific coverage percentages not disclosed.
Last push 2026-06-29 (8 days before analysis date), indicating active upkeep. Minimum requirements updated to Java 11 + Maven 3.9.0 (reasonably current). Version 9.2.0 in use indicates regular releases. README references 50 contributors and credits current maintainers (@ktoso founder, @TheSnoozer active). No stalled issues or deprecation notices visible. Project appears actively maintained, not stagnant—maintenance is low-frequency but consistent.
ADOPT IF: you use Maven, Java 11+, and need runtime visibility into which exact git commit is running in production; especially valuable in large distributed deployments where rollback decisions depend on version tracking. AVOID IF: you've migrated to Gradle (use gradle-git-properties instead), or if your deployment pipeline already provides version/commit metadata through image labels, container registries, or orchestration platforms (e.g., Kubernetes). MONITOR IF: you're considering a build system migration away from Maven—plugin remains maintained but ecosystem lock-in increases switching costs.
Independent dimensions
Mainstream potential
3/10
Technical importance
6/10
Adoption evidence
7/10
- Project has flat/minimal growth trajectory—may signal it is no longer attractive to new adopters, though this is consistent with a mature utility that 'just works'.
- Maven Central distribution dependency means any Maven mirror or tooling outage affects availability, though this is endemic to Maven ecosystem.
- Limited maintainer bandwidth (@ktoso + @TheSnoozer as primary maintainers)—severe issues may experience slower response times than larger projects.
- Git-heavy deployments (e.g., monorepos with thousands of commits) may experience build-time performance impact; README does not document performance characteristics at scale.
- Lock-in to JVM ecosystem—no native support for non-Maven build systems, limiting relevance as alternatives (Gradle, Bazel) grow.
Will remain stable, low-velocity maintenance project. Unlikely to gain significant new adoption outside Maven/Java communities. May gradually lose relative mindshare as container registries and orchestration platforms (Docker, Kubernetes) become the canonical source of deployment metadata. However, will likely continue solving the problem well for existing users indefinitely.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- http://www.kto.so
- Language
- Java
- License
- LGPL-3.0
- Last updated
- 2w ago
- Created
- 188mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Fails with deleted upstream
Is it possible to assign a git property to project.version?
Require Java 17 (LTS)
WARNING about unknown commit-graph chunk
GitHub pull-request workflow - use _expected_ commit hash
Open pull requests
Search parent directories for .git dir
expose properties for executing this plugin from command line without specify plugin configuration in pom.xml
build(deps-dev): bump org.apache.maven.plugins:maven-surefire-plugin from 3.5.5 to 3.5.6
Top contributors
Similar repos
ben-manes/gradle-versions-plugin
Gradle Versions Plugin discovers and reports available dependency updates and...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
git-commit-id/git-commit-id-maven-plugin
this
|
1.7k | +2 | Java | 7/10 | 2w ago |
 apache/maven
|
5.3k | — | Java | 9/10 | 12h ago |
|
ben-manes/gradle-versions-plugin
|
4.1k | — | Kotlin | 8/10 | 3mo ago |
 GitTools/GitVersion
|
3.1k | — | C# | 8/10 | 7h ago |
 gitbucket/gitbucket
|
9.4k | — | Scala | 7/10 | 15h ago |
 tj/git-extras
|
18.1k | — | Shell | 7/10 | 2d ago |
Those plugins handle packaging; git-commit-id complements them by injecting metadata before packaging. Not direct competitors, solve different problems.
Equivalent functionality for Gradle builds. Indicates the problem domain is language/tool-agnostic and likely solved independently in each build ecosystem.
git-commit-id automates what teams otherwise do by hand (git describe, echo to file). Reduces manual error and build-time coupling to version control state.
Modern container deployments also embed git info in image labels (Dockerfile ENV/LABEL). This plugin predates containerization becoming standard; still relevant but less critical in container-first workflows.
Spring Boot's actuator provides build info via /actuator/env. git-commit-id complements by populating the source data; often used together, not interchangeable.
