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.
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:
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...
Note: I only tested this with Maven 3.5.