Resources Blog Deploying 3rd-party JARs to Maven Repositories with ...

Deploying 3rd-party JARs to Maven Repositories with Sonatype Nexus

A common issue in Maven development is the incorporation of 3rd-party JARs into a repository. If you are working with a proprietary database like Oracle, or if you have a vendor that is supplying you with some proprietary 3rd-party JAR that needs to be incorporated into your build, what do you do? How do you get this JAR into a Maven repository that your build can access? This is a common question when people want to start publishing artifacts in a custom repository, and most Maven users might not be aware that repository managers like Sonatype Nexus provide an easy way to deploy these floating, one-off JAR files as well as a way to deploy artifacts from your own build. The following diagram illustrates the use-case which attracts most initial Sonatype Nexus users: proxying of remote repositories.

While proxying remote repositories and maintaining a local cache is certainly important, it isn't the most transformational feature of a good repository. You really start to realize the benefits of a repository manager once you start deploying artifacts to it. Once users start to use Sonatype Nexus hosted repositories they start to see Sonatype Nexus as a central collaboration point for sharing artifacts throughout an organization. No more hand-crafted POMs distributed in an email for developers to install in a local repository. If the organization uses a JDBC driver for Oracle, which is not available on a public repository like Central, that artifact can be deployed on your instance of Sonatype Nexus and made available in the hosted 3rd-party repository which comes preconfigured with every Sonatype Nexus instance.

Back to the original question: someone just handed you a JAR file that is essential to your project's build; how do you get this JAR into a Maven repository?

Old Answer: Handmade POMs and Repositories

Years ago, when the Maven repository was new, and before people had started to work on repository managers, you usually just created a filesystem somewhere in your organization with the appropriate directory structure and pointed everyone's build to it. Maybe you'd go as far as configuring a web server like Apache HTTPd to serve your ad hoc, handcrafted repository. All you needed was a simple POM file with basic elements: project, groupId, artifactId, version, packaging, name. Other than that, checksums were optional. (As long as the filesystem looked like the filesystem on or ${groupId}/${artifactId}/${version}/${artifactId}-${version}.${packaging}, Maven should be able to read it.)

If you were really unlucky, maybe the group of developers you worked with just kept on passing around a ZIP archive that people would download and uncompress in ~/.m2/repository. "Oh, you don't have the Oracle JDBC driver in your local Maven repository.... Here, read this Wiki page, it should only take you 10-15 minutes to copy the right files to your local repo..." I've seen this style of collaboration as recently as last year for things like the Oracle JDBC driver, and I'm sure a few of you reading this are still working at a large organization yet to be convinced of the need for a repository manager. While handcrafting POMs and passing around archives for local repositories might be working for some people, there is a much easier way to load the one-off artifact into a repository...

New Answer: Upload Artifacts to Sonatype Nexus Repository Manager

There's a much easier solution than handcrafting a POM for a 3rd-party JAR. Sonatype Nexus provides a very easy way to upload artifacts to a hosted 3rd-party repository. You can upload using the Maven Deploy Plugin or you can upload via the web interface. Because it is so straightforward, I'm going to include the steps for downloading, installing, starting Sonatype Nexus, and then uploading a 3rd-party JAR. Sonatype Nexus has very low resource requirements, and it is something you can run on an existing workgroup collaboration machine or locally. When you upload a 3rd-party JAR to your own Sonatype Nexus instance, it will immediately be integrated with Sonatype Nexus search capabilities and be available to your organization's builds. In terms of the time required to upload and configure a POM for a 3rd-party JAR, nothing beats the two minutes, start to finish, it will take you to download and configure a basic instance of Sonatype Nexus.

If you want to download Sonatype Nexus and deploy a 3rd-party JAR to a Sonatype Nexus hosted repository, here are the steps required:

  1. Download Sonatype Nexus: (It is open source, free)
  2. Unpack it in a directory (anywhere, it doesn't matter where)
  3. Start Nexus with ./bin/jsw/macosx-universal-32/nexus start (different OS directory depending on platform)
  4. Go to "http://localhost:8081/nexus"
  5. Login as user: "admin" password: "admin123"
  6. Click on "Browse Repositories," and you'll see a list of repositories. You will want to right click on the "3rd Party" repository and choose "Upload Artifact."
  7. You will then see an "Upload Artifact" form. Choose the JAR to upload, then populate the group id, artifact id, version, and other fields.

It will end up in a Maven Repository with the appropriate structure + a checksum. Sonatype Nexus will update the Sonatype Nexus Index which will make it available in the search results. You can then use the filesystem that Sonatype Nexus created, or you can just configure your local Sonatype Nexus instance as a repository in Maven. To configure your newly installed instance of Sonatype Nexus as a mirror for Maven, put the following in your ~/.m2/settings.xml file:

<strong><span style="color: blue">?xml version="1.0"?</span></strong>
<strong><span style="color: blue">settings</span></strong>
  <strong><span style="color: blue">mirrors</span></strong>
    <strong><span style="color: blue">mirror</span></strong>
      <strong><span style="color: blue">id</span></strong><Nexus><strong><span style="color: blue">/id</span></strong>
      <strong><span style="color: blue">name</span></strong>Nexus Public Mirror<strong><span style="color: blue">/name</span></strong>
      <strong><span style="color: blue">url</span></strong>http://localhost:8081/nexus/content/groups/public<strong><span style="color: blue">/url</span></strong>
      <strong><span style="color: blue">mirrorOf</span></strong>central<strong><span style="color: blue">/mirrorOf</span></strong>
    <strong><span style="color: blue">/mirror</span></strong>
  <strong><span style="color: blue">/mirrors</span></strong>
<strong><span style="color: blue">/settings</span></strong>
Picture of Tim OBrien

Written by Tim OBrien

Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.