# git-commit-id-maven-plugin turns your build output into evidence of which commit it was

> This Maven plugin writes git revision data into the build as properties and as a git.properties file, so a running application can report the exact commit it came from. It is on Maven Central, requires Java 11 and Maven 3.9.0, and is licensed LGPL-3.0, which is a different conversation from the Apache-2.0 and MIT licences most of its users in the Java ecosystem are used to.

**git-commit-id/git-commit-id-maven-plugin** — 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... :-)

- Repository: https://github.com/git-commit-id/git-commit-id-maven-plugin
- Website: http://www.kto.so
- Stars: 1,717 · Forks: 303
- Language: Java
- License: LGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/git-commit-id-git-commit-id-maven-plugin

## The pom block that puts git.properties in your artifact

The plugin is on Maven Central under io.github.git-commit-id, and the README's quick start is a single plugin block. Five settings matter and they each do something specific.

```xml
<plugin>
    <groupId>io.github.git-commit-id</groupId>
    <artifactId>git-commit-id-maven-plugin</artifactId>
    <version>9.2.0</version>
    <executions>
        <execution>
            <id>get-the-git-infos</id>
            <goals>
                <goal>revision</goal>
            </goals>
            <phase>initialize</phase>
        </execution>
    </executions>
    <configuration>
        <generateGitPropertiesFile>true</generateGitPropertiesFile>
        <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
        <commitIdGenerationMode>full</commitIdGenerationMode>
    </configuration>
</plugin>
```

The execution id and the phase matter as a pair. Binding the revision goal to the initialize phase means the git data is resolved at the very start of the build, before anything else has a chance to depend on it, and naming the execution means you can override or disable that specific execution later rather than having to fight the lifecycle.

The output path uses the standard Maven property for the build output directory, so the file lands inside the artifact rather than next to it. That is the whole mechanism: file inside the jar, read at runtime.

The last setting is the one with a real trade-off. commitIdGenerationMode set to full produces the complete hash rather than an abbreviated form, which is what you want when the value is going into an incident ticket rather than a log line a human reads.

The result is that the plugin does two things. It exports the git version info as Maven properties available during the build, so other plugins and resource filtering can use them, and it writes a file into the build output, so code can read them at runtime. Code generation and resource loading are the two access paths.

## Java 11 and Maven 3.9.0 are the floors, and the docs live in the repository

The minimum requirements are stated as two numbers: Java 11 and Maven 3.9.0.

The Maven floor is the more consequential of the two, and it is not arbitrary. Maven 3.9.0 is the first release in the 3.9 line, and plugins that set it as a minimum are telling you they rely on behaviour introduced there rather than on Maven 2 compatibility shims. 

Documentation is organised as a set of documents in the repository rather than on a separate site, and the split tells you what people actually need. There is a use cases document, which the README points to when you are unsure whether the plugin addresses your problem, which is the right place to start if you are evaluating rather than configuring. There is a configuration and properties reference, and a document on accessing version info at runtime, which is the companion to the git.properties mechanism above.

The git describe document explains how the plugin handles tagged builds, which matters because git describe behaves differently on a tagged commit, an annotated tag and a lightweight tag, and a build that produces different output in those three cases is exactly the kind of thing you do not want to discover in production.

Two more documents handle the awkward lifecycle questions. A snapshots document covers building from snapshot versions, and an old versions document exists for people still on earlier lines. The configuration reference is also available as Javadoc, generated from the mojo source itself, which means the full option list is documented where it is implemented rather than being maintained separately.

## The version in the quick start is not the newest release

The release history and the documentation have drifted apart, and the gap is worth naming because it is the kind of thing that makes a quick start fail on a fresh project.

The listed releases are 9.2.0 and 10.0.0 on the same day in April 2026, and then 10.0.1 in September 2026. The quick start in the README pins version 9.2.0. So the example a new user copies is one major version behind the current release.

This is not a criticism of the project so much as a natural consequence of how examples age. A quick start that gets updated every major release churns; one that stays stable goes stale. The practical rule is to treat the README block as a shape reference and pin the version you actually want from Maven Central.

That said, a major version boundary in a build plugin deserves a look before you cross it. A plugin that runs at the initialize phase of every build is infrastructure, and infrastructure upgrades are the ones where a behavioural change reaches your whole build graph at once. The repository links a releases page and a CHANGELOG equivalent through its documentation list, and the .bumpversion.cfg file at the root indicates the project uses automated version bumping, which usually means patch releases are mechanical and major ones are not.

The repository root also carries a .buildscript/ directory, a .checkstyle directory and .gitmodules, so the project lints itself with Checkstyle and consumes something as a submodule, most likely for the build tooling rather than for runtime behaviour.

## LGPL-3.0 is the licensing decision, and it is not a formality

The plugin is released under the GNU Lesser General Public License 3.0, with the full text in the LICENSE file and a licence image at the repository root.

That is the one substantive difference from most of its neighbours in the Maven ecosystem. Plugins around it are commonly Apache-2.0, and the libraries a Java service links are frequently MIT. LGPL-3.0 is a weak copyleft licence, which means the freedoms it grants are real but conditional in a way that permissive licences are not.

The distinction that matters most in practice is dynamic versus static linking. A weak copyleft licence is generally more permissive toward a program that uses the library as a separate work, and more demanding toward one that incorporates it, and whether a Maven plugin counts as incorporated into your build output is exactly the sort of question that turns into a legal review rather than a reading exercise.

I am not going to tell you what the answer is for your deployment, because that is not a question to answer from a README, and the README is not offering legal advice either. What I would say is that this is the item to check first if your organisation has a licence allowlist, because LGPL-3.0 will fail a policy that only permits MIT, BSD and Apache, and it is better to find that out before you wire the plugin into a build that ships to customers.

The README's own framing is permissive in tone, saying you are free to use it as you wish with the full licence text attached. That framing describes the grant, not the conditions.

## Who maintains it and who runs it

Maintenance is attributed to two people, listed as @ktoso, who is also named as the founder, and @TheSnoozer, who appears again in the contributions list.

That combination of two named maintainers is worth reading alongside the commit activity. The repository is not archived and the last push was on 2026-09-21, so it is a live project with a small maintainer surface. Two people is a real bus factor consideration for a plugin that every build in your organisation depends on, and the honest way to weigh that is to know that the answer is small rather than to assume it is large.

The contributions section is unusually specific for a README, crediting individuals for particular fixes: @mostr for bugfixes and a framework to do integration testing, @fredcooke for consistent feedback, @MrOnion for a small yet fast bugfix, and @cardil together with @TheSnoozer for helping get the native git support shipped. The count of contributors at the time of writing is given as 50.

That last credit is the most substantive one technically. Native git support, as distinct from invoking the git command line, matters for builds where git is not on the PATH, which includes many CI container images. The fact that someone had to work on it suggests it was a real gap.

The user list names Neo4j, FoundationDB, Spring Boot, Akamai, Sabre and EasyDITA among others, with the note that Spring Boot, the upstream project, uses the plugin and documents it in its reference. A build plugin adopted by a widely used framework is a reasonable signal of production-readiness, though it is a signal about the 9.x and earlier lines rather than about whether a major version bump is safe for you.

The project also asks for feature requests through GitHub Issues rather than email, with the reason given plainly: the author will not lose one in a large inbox, and other people can add ideas or upvote.

## Conclusion

Adopt git-commit-id-maven-plugin if you run distributed systems and need a running service to identify the commit it was built from, since a properties file resolved at startup costs almost nothing and settles incident triage. Do not assume the licence is interchangeable with your stack: this is LGPL-3.0 rather than the permissive licences most Maven plugins carry, so check it against your distribution model before shipping a binary that embeds it. Verify first the version you pin, because the quick start in the README still shows 9.2.0 while the newest tagged release is 10.0.1, and a major version jump in a build plugin is worth reading the release notes for rather than discovering through a broken build.

## FAQ

### How do I add git commit information to my Maven build?

Add the io.github.git-commit-id:git-commit-id-maven-plugin plugin from Maven Central, bind its revision goal to the initialize phase, and set generateGitPropertiesFile to true with generateGitPropertiesFilename pointing at ${project.build.outputDirectory}/git.properties.

### What are the minimum requirements for git-commit-id-maven-plugin?

Java 11 and Maven 3.9.0. The README also recommends the newest version available on Maven Central, where the current artifact is published under io.github.git-commit-id.

### What licence is git-commit-id-maven-plugin released under?

The GNU Lesser General Public License 3.0, with the full licence text in the LICENSE file. That is a weak copyleft licence rather than the permissive licences common among Maven plugins.

## Sources

- [git-commit-id/git-commit-id-maven-plugin on GitHub](https://github.com/git-commit-id/git-commit-id-maven-plugin)
- [License: LGPL-3.0](https://github.com/git-commit-id/git-commit-id-maven-plugin/blob/master/LICENSE)
- [Project website](http://www.kto.so)
- [README](https://github.com/git-commit-id/git-commit-id-maven-plugin/blob/master/README.md)
- [Releases](https://github.com/git-commit-id/git-commit-id-maven-plugin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/git-commit-id-git-commit-id-maven-plugin