Deploying 3rd-party JARs to Maven repositories with Sonatype Nexus Repository
By Tim OBrien
5 minute read time
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 Repository 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 Repository 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 Repository hosted repositories they start to see Sonatype Nexus Repository 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 Repository and made available in the hosted 3rd-party repository which comes preconfigured with every Sonatype Nexus Repository 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 http://repo1.maven.org/maven2 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
There's a much easier solution than handcrafting a POM for a 3rd-party JAR. Sonatype Nexus Repository 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 Repository, and then uploading a 3rd-party JAR. Sonatype Nexus Repository 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 Repository instance, it will immediately be integrated with Sonatype Nexus Repository 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 Repository.
If you want to download Sonatype Nexus Repository and deploy a 3rd-party JAR to a Sonatype Nexus Repository hosted repository, here are the steps required:
- Download Sonatype Nexus Repository. Currently, we also offer an open source, free version.
- Unpack it in a directory (anywhere, it doesn't matter where).
- Start Sonatype Nexus Repository with ./bin/jsw/macosx-universal-32/nexus start (different OS directory depending on platform)
- Go to "http://localhost:8081/nexus"
- Login as user: "admin" password: "admin123"
- 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."
- 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 Repository will update the Sonatype Nexus Index which will make it available in the search results. You can then use the filesystem that Sonatype Nexus Repository created, or you can just configure your local Sonatype Nexus Repository instance as a repository in Maven. To configure your newly installed instance of Sonatype Nexus Repository 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>
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.
Explore All Posts by Tim OBrien