Introduction

The clean way to use a local JAR in Maven is to make Maven treat it like a normal artifact. In practice, that usually means installing the JAR into your local Maven repository with install:install-file, then declaring it as a standard dependency in pom.xml. It is technically possible to reference a file path directly, but that approach is usually less portable and harder to maintain.

Preferred Approach: Install the JAR into the Local Repository

If you have a vendor JAR that is not available in Maven Central or another repository, install it locally first.

1mvn install:install-file \
2  -Dfile=libs/example-lib.jar \
3  -DgroupId=com.example \
4  -DartifactId=example-lib \
5  -Dversion=1.0.0 \
6  -Dpackaging=jar

This places the JAR in your local Maven repository, typically under ~/.m2/repository, using Maven coordinates you control.

Declare It in pom.xml

Once installed, add it as a normal dependency.

1<dependencies>
2  <dependency>
3    <groupId>com.example</groupId>
4    <artifactId>example-lib</artifactId>
5    <version>1.0.0</version>
6  </dependency>
7</dependencies>

From Maven's point of view, that dependency now looks like any other artifact.

That is the main reason this approach is preferable: the rest of the build stays idiomatic.

Why Not Use system Scope?

You may find old examples using system scope with a hardcoded local path. That works mechanically, but it is usually discouraged because it makes the build less portable.

Problems with direct file-path dependencies include:

• machine-specific paths
• poor reproducibility in CI
• harder dependency management for teammates
• awkward upgrades and versioning

A local install is still local, but it fits Maven's artifact model much better.

Team and CI Considerations

Installing a JAR only in your personal local repository solves the problem on your machine, not for the team. If multiple developers or CI servers need the dependency, the stronger solution is to publish the JAR to a shared repository manager such as Nexus or Artifactory.

Then everyone can declare the same coordinates and resolve the artifact in the same way.

So the practical hierarchy is:

• one developer machine: local install is acceptable
• team or CI usage: publish to a shared repository

Example Project Layout

A common local setup is to keep vendor JARs under a project folder such as libs/, then install them during project bootstrap.

1project/
2  pom.xml
3  libs/
4    example-lib.jar

The install:install-file command can be documented in the project README or wrapped in an onboarding script if needed.

Keep the Coordinates Stable

When you choose groupId, artifactId, and version, make them meaningful and stable. Do not invent a new version string every time unless the JAR content actually changes.

If a new vendor JAR arrives, bump the version and update the dependency normally. Treat it like a real artifact, because that is the behavior you want Maven to have.

Common Pitfalls

The biggest mistake is hardcoding a file path in pom.xml instead of using Maven coordinates.

Another mistake is installing the JAR locally and then forgetting that teammates and CI still cannot resolve it.

A third issue is using inconsistent coordinates, which makes later upgrades or troubleshooting harder than necessary.

Summary

• The preferred way to add a local JAR to Maven is to install it into the local repository with install:install-file
• After installation, declare it in pom.xml like any normal dependency
• Avoid direct file-path or system scope solutions unless you have a very specific reason
• For team and CI use, publish the JAR to a shared repository manager instead of relying on one developer's local cache
• Stable Maven coordinates make vendor JAR management much easier over time