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.

There is also a useful option ```-DcreateChecksum=true```, which creates the md5 and sha1 files. It is displayed by the ```help``` goal, but not documented on https://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html — Karsten Spang, Jun 29 '22 at 13:27

score 44 · Accepted Answer · edited May 23 '17 at 11:33

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.

The problem isn't that people *like* to use the wrong method, or do it to spite people - the problem is that none of this stuff is documented clearly and no recipes are given on the internet to achieve these things. It's impossible to coarse people in to creating "enterprise repositories" or using maven as meant by not having documentation for the common cases people encounter - they will always find a way. — Nakedible, Sep 04 '10 at 19:11
@Nakedible Well, I guess that you must be right about the documentation of a practical solution. Regarding the `system` scope, maybe the Maven folks should make it clearer that it is not a solution to add "random" dependencies to a build. But the `system` scope itself is [documented](http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). — Pascal Thivent, Sep 04 '10 at 19:34
another problem ist that there is no easy way to use local jars: admit it, system scope may be wrong and make right-minded people flinch, but beginners need to get stuff to work. i a project due tomorrow, 10⁰⁰, and need a shaded jar ready by then. having to set up a repo makes my eyes roll backwards into my head. — flying sheep, Jan 23 '12 at 23:28
I like the answer but that does not answer the question. Its nice to teach people that this is a bad practice but there are situations where this is really required. After 13 years of my JDev practice I have finally came to this one moment I really need this and its not cool to read this instead of a real solution. If you are interested I have just came upon a library that is licensed to only one project, so this is not going to either central repo or even corporate repo and I am not telling other devs to install this to their local repository as a prerequisite to build a project — maslan, Jan 15 '19 at 10:17
Why would installing to the local repo be non-portable? I may be wrong, but if you bind an install-file to e.g. the `clean` phase, as described in [this answer](https://stackoverflow.com/a/31023523/6245827), then the jar would be installed. What portability issues may that cause? — oowekyala, Feb 28 '19 at 14:48

score 17 · Answer 2 · answered Dec 14 '12 at 01:30

17

The Maven addjars plugin solves this problem - see

http://code.google.com/p/addjars-maven-plugin/wiki/UsagePage

answered Dec 14 '12 at 01:30

Mark Butler

4,361
2
39
39

unfortanetelly needs Maven 3.0.3 – Daniel Hári Jul 09 '15 at 16:30
@Daniel do you mean you need at least Maven 3.0.3 or that it doesn't run with newer versions? Maven 3.0.3 was released in 2011-03-04 https://maven.apache.org/docs/history.html if you can't run that you have serious problems! Looking at addjars it hasn't been released since 2012 http://mvnrepository.com/artifact/com.googlecode.addjars-maven-plugin/addjars-maven-plugin – Mark Butler Jul 09 '15 at 17:07
I mean 3.0.3+. Yes I have serious problems that I should use eclipse indigo, that's m2e connector is lower versioned and unable to update. – Daniel Hári Jul 10 '15 at 12:26

score 2 · Answer 3 · answered Apr 11 '16 at 20:09

Used <resources> to include my lib with all jars. i.e:

<build>
    <resources>
        <resource>
            <directory>${project.basedir}</directory>
            <includes>
                <include>lib/*.jar</include>
            </includes>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <createDependencyReducedPom>false</createDependencyReducedPom>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

it "kinda" works, cause it indeed includes the jar file into the shaded jar, but I think the OP wanted this jar to be unpacked into the shaded jar, not be directly included, as java does not support fat jars out of the box — maslan, Jan 15 '19 at 10:13

score 1 · Answer 4 · answered May 28 '21 at 16:21

1

If you only need a quick and dirty solution, you can add the content of the extracted jar file to your src/main/resource directory.

answered May 28 '21 at 16:21

linczy

160
1
5

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

4 Answers4

Linked

Related