Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

The general consensus is when you are having to fight Maven, you're doing something wrong. However, sometimes you get backed into a corner and do have to put up a fight to move forward. I've come across a situation where in order to connect to and use an API hosted as EJBs in WebLogic I needed to have a number of client jar files, 16 in total. I didn't particularly want to have 16 separate dependencies in my own Maven projects and I also wanted to make it as easy as possible for others on the project to access this API. My solution was to look into the creation of an UBER JAR file to hold all the required classes.

This is exactly what the Maven Shade Plugin is designed for. Unfortunately this plugin expects that all of your separate jar files are already present in the Maven repository as individual artefacts. Doh!

I didn't want to have all of the 16 separate jar files in the project Maven repository. I just wanted one artefact, the client that I needed to access the API. So I needed a way around Shade's dependency requirement.

My solution was to use a shell script to do some of the work, then to leverage my local Maven repository before deploying to the hosted project Maven repository. So lets see what I did exactly -

First I put all of the separate jar files that made up the 'API client' into a directory.
 Directory structure
\-- my_work_directory/
\-- client_jars/
\-- clientjar1.jar
|-- clientjar2.jar
|-- clientjar3.jar

Then I wrote a simple shell script that did two things - 1) install all of the jar files from the client_jars directory into my local Maven repository, and 2) created a pom.xml file with Maven Shade configuration to generate the uber jar file and its dependency reduced pom.

Here's what the script looked like:
 Bash Script
function minstall {
classifier=$(basename "$1" .jar|tr -cd '[[:alnum:]]')
mvn -q install:install-file -DartifactId=$artifactId -Dclassifier=$classifier -Dfile="$1" -DgroupId=$groupId -Dversion=$version -Dpackaging=jar
for i in $(ls $1); do
minstall "$1/$i"
cat > pom.xml << EOF
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
mvn deploy

There's not too much to this script really, but a few things do need to be pointed out. When the local jar files are installed into my local Maven repository, they are done so with the classifier set. This means that none of them are the main artefact. The artifactSet element for the generated pom.xml makes use of this by using a wildcard operator * for the artefact filter.

The last part of the script runs mvn deploy, which executes the Maven Shade plugin first, then uploads the generated uber jar into the hosted project Maven repository. The uber jar is built using all the locally installed jars and then the main artefact is replaced by this uber jar. Since there was no main artefact in the first place, the uber jar is the only artefact that makes it into the hosted project Maven repository!

All I have to do next is include a single dependency in my other Maven projects like this...
<artifactId> MyUberJar </artifactId>

Note: I only tested this with Maven 3.5.


A quick disclaimer...

Although I put in a great effort into researching all the topics I cover, mistakes can happen. Use of any information from my blog posts should be at own risk and I do not hold any liability towards any information misuse or damages caused by following any of my posts.

All content and opinions expressed on this Blog are my own and do not represent the opinions of my employer (Oracle). Use of any information contained in this blog post/article is subject to this disclaimer.
Hi! You can search my blog here ⤵
NOTE: (2022) This Blog is no longer maintained and I will not be answering any emails or comments.

I am now focusing on Atari Gamer.