We Keep Coding

Excluding certain .jars from a Maven dependency from build by classifier

My project includes the nd4j-native-platform dependency, which includes .jars for windows, linux, and mac. The app is developed on windows/mac machines then deployed to Linux, so I'd like to save space on deployment by excluding these other platform jars that take up > 400 MB when the .war is built. Tl;dr, I want to exclude all the .jars that don't end with linux-x86_64.
Dependency in pom:
<dependency>
<groupId>org.nd4j</groupId>
<artifactId>nd4j-native-platform</artifactId>
<version>1.0.0-beta7</version>
<classifier>linux-x86_64</classifier>
</dependency>
I don't see any way to exclude them by classifier in the dependency tag, it seems you can only exclude by groupId and artifactId. I also tried using packagingExcludes and warSourceExcludes in the .war plugin, but that didn't do anything:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.3</version>
<configuration>
<packagingExcludes>
WEB-INF/lib/nd4j-native-1.0.0-beta7-windows-x86_64.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-android-x86.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-macosx-x86_64.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-android-x86_64.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-linux-ppc64le.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-android-arm64.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-android-arm.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-windows-x86_64.jar,
WEB-INF/lib/nd4j-native-1.0.0-beta7-linux-armhf.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-windows-x86.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-windows-x86.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-linux-armhf.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-linux-ppc64le.jar,
WEB-INF/lib/openblas-0.3.9-1-1.5.3-linux-arm64.jar
</packagingExcludes>
</configuration>
</plugin>
Using Maven 3.6.3.

The correct way to deal with this for most things that use JavaCPP is to set the javacpp.platform property.
When building with mvn -Djavacpp.platform=linux-x86_64 you will get only that specific platform and nothing else. This will also apply to all other transitive dependencies, e.g. opencv.
You can try running mvn -Djavacpp.platform=linux-x86_64 dependency:tree to see that it works.

Maven : How to package external jars(folder) in Maven project

I am having a group of external jars(in hundreds) which I have added in the build path of my project to make it work.
But while packaging it is failing as these jar's are not available to maven.
I have gone though many articles and all the solutions(like adding the jar at system path) are for a single jar only.
<dependency>
<groupId>com.sample</groupId>
<artifactId>sample</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/src/main/resources/Name_Your_JAR.jar</systemPath>
</dependency>
Is there any way we can add the group of jars(folder) to the packaging on the project? or any other solution by which my project can build successfully?
can we create a single jar containing all my jars inside and then use the system scope of maven
I have tried creating jar by jar -cvf my_jar.jar * and placed this jar in the system scope. But it does not worked for me.

My solution : Maven pluggin addjar let us add all jar at a place(projectdirectory/lib in this case).
this enables you to add these jar's in the final package(jar in my case) when you maven build, but to run locally you have to add those jar files directly in the classpath.
<plugin>
<groupId>com.googlecode.addjars-maven-plugin</groupId>
<artifactId>addjars-maven-plugin</artifactId>
<version>1.0.5</version>
<executions>
<execution>
<goals>
<goal>add-jars</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>${basedir}/lib</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
Now create a shade jar using mvn clean install shade:shade

The bad news: For a proper Maven project, you need to add each and every artifact you use as <dependency> in your POM.
The good news: I very much doubt that these 100 jars are all
- directly used in your source code
- not available in a public Maven repository like MavenCentral
So the better strategy would be to figure out what you really need and find that in MavenCentral. Then Maven finds all the transitive dependencies for you. So if you really need 10 of the jars and all other jars are just dependencies of your dependencies, just add these 10 ones (from MavenCentral) and you are done.

Can't resolve the error: java.lang.NoClassDefFoundError: org/json/simple/parser/ParseException

Trying to use Maven to organize my project and I keep running into the following error. I know that this error means the file is present at compile time but for some reason it can't be found at runtime.
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: org/json/simple/parser/ParseException
So I'm working on a project in Java that will take a user query, search Google Images and then download some of the results onto my computer. To that end I've had to use some third party libraries like JSoup, Json-Simple, and Gson.
I initially added Jsoup to my classpath manually and it worked, but then I heard about Maven and started using it instead. My issue is that when I try to run my code I get the error above.
I'm just not sure how to resolve this. I've seen a bunch of other posts about similar errors and I've tried to modify my pom.xml accordingly but
I just can't get it to work. I've tried removing the ~/.m2 file, ran mvn clean, mvn install, mvn package, mvn compile, and it all works fine. But when it comes time to run, I keep getting that error.
Here's most of my pom.xml file.
<repositories>
<repository>
<id>central</id>
<name>Maven repository</name>
<url>http://repo1.maven.org/maven2</url>
</repository>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<!-- jsoup HTML parser library # https://jsoup.org/ -->
<groupId>org.jsoup</groupId>
<artifactId>jsoup</artifactId>
<version>1.11.3</version>
<scope>provided</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/com.googlecode.json-simple/json-simple -->
<dependency>
<groupId>com.googlecode.json-simple</groupId>
<artifactId>json-simple</artifactId>
<version>1.1.1</version>
</dependency>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>fully.qualified.MainClass</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
</plugins>
</build>
FOUND SOLUTION: So I left out some parts of the pom.xml file to make it easier to read, and because all the other parts were generated by Maven itself so I figured there couldn't be an issue with anything there. But it adds a tag called "pluginManagement" that encloses all other plugins and apparently this does not allow the Shade plugin to run.
Between ngueno's guidance and this post Maven shade plugin is not called automatically for goal "package"
I was able to figure out my issue, though I'm still not entirely sure why it is an issue. Anyways, I figured I'd update this post in case someone else with a similar problem stumbles across it. This was on Mac OS btw, in case it makes a difference. Thanks for your help everyone.

Usually NoClassDefFound errors are related to missing libraries at runtime.
Since you are running using the terminal I supose you are building your project using Maven, and running the generated JAR,
I would recommend to you to use the maven-shade-plugin and generate an uber-jar as I explained on this question.
The purpose generating a uber-jar is to carry all the needed dependencies inside of it (available on the application classpath).
Implement the plugin and try to run using the new JAR.
PS: Remember to check this section related to Executable Jars
UPDATE: Remove the <scope>provided</scope> of your jsoup dependency, to enforce Maven to package it along your app, with the provided scope you are saying that this dependency will be provided by the JDK at runtime.

The jars that you identify in your dependencies must be present in the Runtime classpath.
This is not the classpath that is available when you compile the code;
it is the classpath on the host where you run the application.
You must install these jars on the target host.
Edit: More details
You must do the following:
Identify the runtime host.
Create a directory on the runtime host into which you will install the dependent jar files.
Include every jar in the classpath.
Consider abandoning the "roll-your-own" path.
If you use Spring Boot
(I like it,
I don't work for them).
One feature of spring boot is a reinvented "Fat Jar" that will include the dependencies inside one deliverable artifact (the fat jar) and will add them to the classpath at startup.
Edit:
The Spring boot executable jar file is not a "Fat Jar",
instead it includes the dependencies in a directory in the
executable jar and adds said jars to the classpath on startup.

Maven project doesn't recognize any classes from included sibling dependency [duplicate]

I am writing a project for acceptance testing and for various reasons this is dependent on another project which is packaged as a WAR. I have managed to unpack the WAR using the maven-dependency-plugin, but I cannot get my project to include the unpacked WEB-INF/lib/*.jar and WEB-INF/classes/* to be included on the classpath so the build fails. Is there a way to include these files into the classpath, or is there a better way of depending on a WAR?
Many thanks.

There's another option since maven-war-plugin 2.1-alpha-2. In your WAR project:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
This creates a classes artifact which you can use in the acceptance tests project with:
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
</dependency>

Indeed, by design, Maven doesn't resolve transitive dependencies of a war declared as dependency of a project. There is actually an issue about that, MNG-1991, but it won't be solved in Maven 2.x and I'm not sure that I don't know if overlays allow to workaround this issue. My understanding of the suggested solution is to duplicate the dependencies, for example in a project of type pom.
(EDIT: After some more digging, I found something interesting in this thread that I'm quoting below:
I have been helping out with the development of the AppFuse project over
the last month where we make heavy use of the war overlay feature in the
Maven war plugin. It is a really nifty feature!
To get max power with war overlays I have developed the Warpath plugin
that allows projects to use war artifacts as fully fledged dependencies.
In brief:
1) The contents of the /WEB-INF/classes directory in the war dependency
artifacts can be included in the project's classpath for normal compile,
etc tasks.
2) Transitive dependencies from the war dependency artifacts become
available for use by other plugins, e.g. compile and ear - so no more
having to include all the dependencies when creating skinny wars!
The plugin has now been actively used in the AppFuse project for the
last few months, and I feel it is at a point where it is both usable and
stable.
Would the war plugin team be interested in including the warpath
functionality inside the war plugin? It would seem to be the most
natural place to host it.
So, I don't have any experience with it, but the maven warpath plugin actually looks nice and simple and is available in the central repo. To use it,include the following plugin configuration element in your pom.xml file:
[...]
<build>
<plugins>
<plugin>
<groupId>org.appfuse</groupId>
<artifactId>maven-warpath-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>add-classes</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
And add the war dependencies you want included in the classpath as warpath type dependencies:
[...]
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>warpath</type>
</dependency>
</dependencies>
[...]
Both the war and warpath dependency types are needed: the war type is used by the Maven war plugin to do the war overlay, the warpath type is used by the Warpath plugin to determine the correct list of artifacts for inclusion in the project classpath.
I'd give it a try.)

Use overlays. First, your test project need to have also packaging war.
Declare dependency of war project you want to test:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>your-project-arftifactId</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>test</scope>
</dependency>
then configure maven-war-plugin overlay:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webresources</directory>
<filtering>true</filtering>
</resource>
</webResources>
<overlays>
<overlay/>
<overlay>
<groupId>your.group</groupId>
<artifactId>your-project-artifactId</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
In the above example in test project I overwrite webresources configuration files (like conxtext etc.).
EDIT: This solution wasn't tested with Maven 3.

Good point, Justin. That got me actually solving my problem, namely: including a war into an assembly AND including all its transitive dependencies.
I could not duplicate the war-dependency as 'jar' as you suggested since the assembly plugin would not find a jar referenced by that groupId/artefactId, but
duplicating the war-dependency as type pom
works!
The war and its transitive dependencies are not included in the assembly.
To exclude the (now also appearing) pom file I had to add an exclude element like this:
<excludes>
<exclude>*:pom</exclude>
</excludes>
into my assembly.xml file.
I think this could also be a workaround for the original question of this thread.

If you list the dependency on the war project as a jar dependency it seems to pickup the required jars/resources. I'm using Maven 2.2 + m2eclipse.

Can't get the maven-war-plugin to exclude jaxb jars

I'm trying to use the <packagingExcludes> of the Maven war-plugin.
This is my configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<archive>
<manifestEntries>
<Implementation-Version>${project.artifactId}-${project.version}-r${buildNumber}</Implementation-Version>
<Implementation-Buildtime>${timestamp}</Implementation-Buildtime>
</manifestEntries>
</archive>
<packagingExcludes>WEB-INF/lib/jaxb*.jar</packagingExcludes>
</configuration>
</plugin>
In my understanding this line:
<packagingExcludes>WEB-INF/lib/jaxb*.jar</packagingExcludes>
Should exclude all jars starting with 'jaxb' from the built .war file.
However after I run clean install I get both:
jaxb-api-2.1.jar
jaxb-impl-2.1.3.jar
Packaged in my .war WEB-INF/lib dir.
I'm using Maven 3.
Any help greatly appreciated.
Thanks in advance,
To answer gkamal's comment.
When I run mvn war:war -X I can see:
[DEBUG] Processing: jaxb-api-2.1.jar
[DEBUG] + WEB-INF/lib/jaxb-api-2.1.jar has been copied.
[DEBUG] Processing: jaxb-impl-2.1.3.jar
[DEBUG] + WEB-INF/lib/jaxb-impl-2.1.3.jar has been copied.
Also
[DEBUG] Excluding [WEB-INF/lib/jaxb*.jar] from the generated webapp archive.
No, exceptions, warning or errors or nothing that looks suspicious, anything specific I should look for ?

For a transitive dependency, you can use the exclusions element to exclude it.
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<exclusions>
<exclusion>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api-2.1</artifactId>
</exclusion>
</exclusions>
</dependency>
As gkamal commented, you could also add an explicit dependency on jaxb and set its scope to provided, this will override the scope of the transitive dependency so it is no longer packaged.
Another alternative, the war plugin also allows to exclude based on regular expressions, but the syntax is a bit more involved, the following snippet should exclude everything under lib whose filename starts with "jaxb":
<packagingExcludes>%regex[WEB-INF/lib/jaxb.*]</packagingExcludes>

This means you have them as dependency in your project so they will be packaged into the war. Just remove the dependencies so they wont be packaged anymore.
Based on the documentation of the option you used you have to use regex which means you should write:
<packagingExcludes>WEB-INF/lib/jaxb.*</packagingExcludes>
instead of
<packagingExcludes>WEB-INF/lib/jaxb*.jar</packagingExcludes>

Further to #gkamal's comment to your question (08/05/12#11:52), check your maven-war-plugin's version. I've just spent 2hrs looking at this issue myself to exclude an unknown transient to javaee-api*.jar.
With maven 3.0.4, I was defaulted to maven-war-plugin version 2.1 (you can tell if you run your build in debug - e.g. mvn clean package -X). One of your other comments is correct in saying package-excludes came in after this. See the war plugin page for details (although the actual page describing the entry doesn't indicate version info which is pretty poor as that's what you first search for).
If you update to maven-war-plugin to 2.3 (add <version>2.3</version>, your packaging-excludes should be used. Note though you will only see this in the built war's WEB-INF/lib, not in the transient war directory (which includes the excluded jars even if debug says they're to be excluded, which is very confusing when looking at this issue).
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
...
<packagingExcludes>
WEB-INF/lib/whatever-*.jar,
WEB-INF/lib/javaee-api-*.jar
</packagingExcludes>
...
</plugin>
...
However, in terms of best practice, this is probably a last gasp effort to exclude jars fromo the war and the dependency-level exclusions for transient jars is probably the most precise and correct way. That said, what if a transient jar is being brought in by multiple dependencies?
So, with the version upgrade, I think #khmarbaise's solution is fine (and the comment indicating it won't work is wrong). However, I think best practice is to use dependency-level exclusions as per your accepted answer.

You can do this by specifying inside <packagingExcludes></packagingExcludes> inside </configuration><configuration>.
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<packagingExcludes>
WEB-INF/lib/ex1-*.jar,
WEB-INF/lib/ex2-logging-*.jar
</packagingExcludes>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
You can specify path by wild cards and regular expressions too. See this link for more info.