java - Having a 3rd party jar included in Maven shaded jar without adding it to local repository

Question

I already found an answer here on Stack Overflow how to include a 3rd party JAR in a project without installing it to a "local repository":

Can I add jars to maven 2 build classpath without installing them?

But, when I use the Maven Shade Plugin to create a JAR that includes all the dependencies of the project as well, the 3rd party JAR is not included automatically.

How can I make the Maven Shade Plugin add such a 3rd party JAR in to the shaded JAR?

---

As per the answer gotten, I made it work. What I did was, added this snippet to the beginning of my pom.xml:

<repositories>
  <repository>
    <id>repo</id>
    <url>file://${basedir}/repo</url>
  </repository>
</repositories>

Then added a dependency for my project, also to pom.xml:

<dependencies>
  <dependency>
    <groupId>dummy</groupId>
    <artifactId>dummy</artifactId>
    <version>0.0.0</version>
    <scope>compile</scope>
  </dependency>
</dependencies>

And then ran a command line to add a package to 'repo':

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
    -Dfile=<my-jar>.jar -DgroupId=dummy -DartifactId=dummy
    -Dversion=0.0.0 -Dpackaging=jar -DlocalRepositoryPath=`pwd`/repo/

(Not sure if the repo path needs to be a full path, but didn't want to take chances.)

The contents of the repo subdirectory is now:

repo/dummy/dummy/0.0.0/dummy-0.0.0.jar
repo/dummy/dummy/0.0.0/dummy-0.0.0.pom
repo/dummy/dummy/maven-metadata-local.xml

Now I can check this in to version control, and have no local or remote dependencies.

Answer 1

But, when I use the Maven Shade Plugin to create a JAR that includes all the dependencies of the project as well, the 3rd party JAR is not included automatically.

Yes, because the system scoped dependencies are assumed to be always present (this is exactly what the system scope is about) so they won't be included. People actually don't understand what system scope dependencies are, they just keep abusing them (yes, this is abuse), and then get side effects and wonder why (as Brian pointed out in his answer).

I already wrote many, many, really many times about this here on SO and in 99% of the cases, system scoped dependencies should be avoided. And I'll repeat what the Dependency Scopes mini guide says one more time:

• system: This dependency is required in some phase of your project's lifecycle, but is system-specific. Use of this scope is discouraged: This is considered an "advanced" kind of feature and should only be used when you truly understand all the ramifications of its use, which can be extremely hard if not actually impossible to quantify. This scope by definition renders your build non-portable. It may be necessary in certain edge cases. The system scope includes the <systemPath> element which points to the physical location of this dependency on the local machine. It is thus used to refer to some artifact expected to be present on the given local machine an not in a repository; and whose path may vary machine-to-machine. The systemPath element can refer to environment variables in its path: ${JAVA_HOME} for instance.

So, instead of using the system scope, either:

• Add your libraries to your local repository via install:install-file. This is a quick and dirty way to get things working, it might be an option if you're alone but it makes your build non portable.
• Install and run an "enterprise repository" like Nexus, Archiva, or Artifactory and add your libraries via deploy:deploy-file. This is the ideal scenario.
• Setup a file based repository as described in this previous answer and put your libraries in there. This is the best compromise if you don't have a corporate repository but need to work as a team and don't want to sacrifice portability.

Please, stop using the system scope.