install-local-jar-with-maven

Posted on: 2019-10-08 2019-10-08
Tags: Maven

Install local jar with Maven

Maven

1. The Problem and the options

Maven is a very versatile tool and its available public repositories are
second to none. However there will always be an artifact that is either
not hosted anywhere, or the repository where it is hosted is risky to
depend on, as it may not be up when you need it.

When that happens, there are a few choices:

bite the bullet and install a full fledged repository management
solution such as Nexus
try to get the artifact uploaded into one of more reputable public
repositories
install the artifact locally using a maven plugin

Nexus is of course the more mature solution, but it’s also the more
complex. Provisioning an instance to run Nexus, setting up Nexus
itself, configuring and maintaining it may be overkill for such a simple
problem as using a single jar. If this scenario – hosting custom
artifacts – is a common one however, a repository manager makes a lot of
sense.

Getting the artifact uploaded into a public repository or in Maven
central directly is also a good solution, but usually
a
lengthy one. In addition, the library may not be Maven enabled at all,
which makes the process that much more difficult, so it’s not a
realistic solution to being able to use the artifact NOW.

That leaves the third option – adding the artifact in source control and
using a maven plugin – in this case,
the
maven-install-plugin to install it locally before the build process
needs it. This is by far the easiest and most reliable option
available.

2. Install local jar with the maven-install-plugin

Let’s start with the full configuration necessary to install the
artifact into our local repository:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-install-plugin</artifactId>
   <version>2.5.1</version>
   <configuration>
      <groupId>org.somegroup</groupId>
      <artifactId>someartifact</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <file>${basedir}/dependencies/someartifact-1.0.jar</file>
      <generatePom>true</generatePom>
   </configuration>
   <executions>
      <execution>
         <id>install-jar-lib</id>
         <goals>
            <goal>install-file</goal>
         </goals>
         <phase>validate</phase>
      </execution>
   </executions>
</plugin>

Now, let’s break down and analyze the details of this configuration.

2.1. The artifact information

The artifact information is defined as part of the <configuration>
element. The actual syntax is very similar to declaring the dependency –
a groupId, artifactId and version elements.

Next part of the configuration requires defining the packaging of the
artifact – this is specified as jar.

Next, we need to provide the location of the actual jar file to be
installed – this can be an absolute file path or it can be relative,
using the
properties
available in Maven. In this case, the ${basedir} property represents
the root of the project, namely the location where the pom.xml file
exists. This means that the someartifact-1.0.jar file needs to be
placed in a /dependencies/ directory under the root.

Finally, there are several other
optional
details that can be configured as well.

2.2. The Execution

The execution of the install-file goal is bound to the validate
phase from the standard Maven
build
lifecycle. As such, before attempting to compile – you will need to run
the validation phase explicitly:

mvn validate

After this step, the standard compilation will work:

mvn clean install

Once the compile phase does execute, our someartifact-1.0.jar is
correctly installed in our local repository, just as any other artifact
that may have been retrieved from Maven central itself.

2.3. Generating a pom vs supplying the pom

The question of whether we need to supply a pom.xml file for the
artifact or not depends on mainly on the runtime dependencies of the
artifact itself. Simply put, if the artifact has runtime dependencies on
other jars, these jars will need to be present on the classpath at
runtime as well. With a simple artifact that should not be a problem, as
it will likely have no dependencies at runtime (a leaf in the dependency
graph).

The generatePom option in the install-file goal should suffice for
these kinds of artifacts:

<generatePom>true</generatePom>

However, if the artifact is more complex and does have non-trivial
dependencies, then, if these dependencies are not already in the
classpath, they must be added. One way to do that is by defining these
new dependencies manually in the pom file of the project. A better
solution is to provide a custom pom.xml file along with the installed
artifact:

<generatePom>false</generatePom>
<pomFile>${basedir}/dependencies/someartifact-1.0.pom</pomFile>

This will allow Maven to resolve all dependencies of the artifact
defined in this custom pom.xml, without having to define them manually
in the main pom file of the project.

3. Conclusion

This article goes over how to use a jar which is not hosted anywhere
within a Maven project by installing it locally with the
maven-install-plugin.

getdocs

3043