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
groupId=my.group
artifactId=MyUberJar
version=1.0
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
deps+="<dependency><groupId>$groupId</groupId><classifier>$classifier</classifier><artifactId>$artifactId</artifactId><version>$version</version><scope>runtime</scope></dependency>"
}
deps=""
for i in $(ls $1); do
minstall "$1/$i"
done
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">
<modelVersion>4.0.0</modelVersion>
<groupId>$groupId</groupId>
<artifactId>$artifactId</artifactId>
<version>$version</version>
<packaging>jar</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>$groupId:$artifactId:jar:*</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
$deps
</dependencies>
</project>
EOF
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...
 POM
<dependency>
<groupId>my.group</groupId>
<artifactId> MyUberJar </artifactId>
<version>1.0</version>
</dependency>


Note: I only tested this with Maven 3.5.

-i

Hope you found this post useful...

...so please read on! I love writing articles that provide beneficial information, tips and examples to my readers. All information on my blog is provided free of charge and I encourage you to share it as you wish. There is a small favour I ask in return however - engage in comments below, provide feedback, and if you see mistakes let me know.

If you want to show additional support and help me pay for web hosting and domain name registration, donations, no matter how small, are always welcome!

Use of any information contained in this blog post/article is subject to this disclaimer.
comments powered by Disqus
Other posts you may like...