Home/ Questions/Q 6371427
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T01:04:05+00:00

My project depends on some 3rd-party JARs which are not available in Maven Central.

  • 0

My project depends on some 3rd-party JARs which are not available in Maven Central.

Most information I see regarding this situation, including the official Maven Guide to installing 3rd party JARs, advises installing the artifact into the local repository using mvn install:install-file .... This works well when developing locally, but when the build needs to be performed on many different systems in an automated fashion, requiring this manual step is undesirable and impractical.

Another solution often presented is to install the dependency into an organization-wide repository, however there are circumstances in which that isn’t possible.

With neither of those options being acceptable, I can think of two options:

  1. Store the JAR in a lib directory within the project and declare the dependency with a system scope (as suggested in several answers). This would seem to work on any system since the dependency is bundled with the project, but I’ve seen the use of system discouraged as a bad practice (typically with no more explanation than that).
  2. Bind the maven-install-plugin to the initialize lifecycle phase to install the artifact to the local repository. However, as pointed out here, this would cause unnecessary overhead as it runs for each and every build. If there were a way to execute this lazily only when the artifact is not installed, that might be ideal.

I would like a standard Maven project that can be built using the regular Maven lifecycle, without any out-of-band “run scripts/init-dependencies first” steps required.

What is the best way forward?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here is a recent answer to that question: Maven: keeping dependent jars in project version control

    I do not recommend using install-file in the lifecycle. As you’ve mentioned, it will run every time – the above solution will skip through the project quite quickly. While the above creates a new module, it does reduce the verbosity needed for many JARs, allows you to use a repository format that can easily be copied into a repository manager, and keeps this out of your main build.

    I also do not recommend using system scope for the reasons mentioned some answers to the questions you linked to list.

    • 0