I hope I'm explaining this as accurately as possible, and I want to know if I set up the maven dependencies correctly, or if there's a better way to do it.
Most of my development team's projects rely on a home-grown jar that is deployed at server class loader. The reason for this jar to reside at this level is to the ease of updating the jar at one place without repackaging each project that's using it, assuming changes made to it are backward-compatible.
I develop my web apps against Jetty in my local development. So, in order for the web apps to work locally, I set up the dependencies this way:-
<dependencies>
<!-- Configuring external jar dependency -->
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${env.EXTERNAL_JAR}</systemPath>
</dependency>
...
</dependencies>
<build>
<plugins>
<!-- Configuring Jetty -->
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<contextPath>/${project.parent.artifactId}</contextPath>
<jettyEnvXml>${env.JETTY_ENV_XML}</jettyEnvXml>
<scanIntervalSeconds>1</scanIntervalSeconds>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>7777</port>
</connector>
</connectors>
<webAppConfig>
<extraClasspath>${env.EXTERNAL_JAR}</extraClasspath>
</webAppConfig>
</configuration>
</plugin>
...
</plugins>
</build>
In this approach, I set up an environment variable that points to the external jar path, and reference it in my pom.xml as ${env.EXTERNAL_JAR}.
After doing some reading, it seems like using "system" scope is considered a bad practice. So, I installed this external jar in Nexus and change the scope to "provided":-
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
This allows me to compile my project properly, but I'm not sure if it is even possible for me to get rid of the "EXTERNAL_JAR" environment variable completely because it's still needed by Jetty for the runtime to work properly. My take is using "provided" scope is a little tedious and more work, because I now need to remember to update the jar in Nexus when it is modified AND I still need to update the jar located at the path pointed by the environment variable.
Is there a way for me to expose the external jar to Jetty through maven dependencies, yet not being packaged into the project when the war file is built?
What are you advice on this? Should I just stick with "system" scope so that I just need to update the jar at one place, or should I use "provided" scope? Or if there's even a better way to do this?
Thanks much.
You should be able to add dependencies to the jetty plugin. And then I have the provided scope for the project itself.
http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
as in
<project>
...
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<systemProperties>
<systemProperty>
<name>logback.configurationFile</name>
<value>./src/etc/logback.xml</value>
</systemProperty>
</systemProperties>
</configuration>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.15</version>
</dependency>
</dependencies>
</plugin>
...
<project>
The best thing to do is setup an external repository with your dependency, and add it to your pom.
<repositories>
<repository>
<id>my-repo</id>
<name>my-repo</name>
<url>http://your.repo.url</url>
</repository>
</repositories>
and then you can add your dependency as
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
</dependency>
I approve of provided. Provided means - download the dependency for compile-time, but I expect to see it on classpath on the application server.
I did not realize you care only for your local development, so the following would be useful if you were running Jetty on an external server:
Maven will let you deploy a file to a server using the Wagon plugin. So a part of your build process could be pushing the proper .jar into your Jetty server. That way you would not have to do it manually. I would prefer this solution to running a local Maven repository on the Jetty server as suggested by #Paul.
If you wanted to be super-clever (usually a bad idea), you might try to set up a repository directly on the machine with Jetty, that would serve the jar directly from your Jetty install. That way you would not have to modify Nexus, the jars would be only at one place. You can even set up Nexus to mirror another repository, so it could pick things up automatically.
It is a bad practice to modify .jar contents and keep the same Maven coordinates. So this "clever" approach would not work that great anyway.
Related
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.
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.
Need to be pointed in the right direction on this perhaps, but if I add a "provided" dependency that is not included in the tomcat set of provided dependencies, running tomcat7:run from within eclipse fails with a classnotfoundexception on the class from the provided scope jar.
It needs to "provided" because it's a custom jar from a separate project that I've run mvn install on and for production am copying the jar to the $CATALINA_BASE/shared directory so that it's available (as a singleton) across applications/webapps.
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
Only way I see (with my limited knowledge of Maven and the Tomcat7 plugin) is to change the scope to compile when running tomcat from the plugin in Eclipse and then change the scope back to provided when running the package goal.
Are there solutions to this? I tried adding the dependency to the the tomcat maven plugin (keeping the main maven dependency as provided but got the same class not found error:
<!-- For Maven Tomcat Plugin -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/CounterWebApp</path>
</configuration>
<dependencies>
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>
Again, it needs to be provided in the main Maven dependency because I don't want it included in the deployed WAR.
Resolved by using profiles, similar to https://stackoverflow.com/a/5951630
...
</dependencies>
<profiles>
<profile>
<id>runineclipse</id>
<dependencies>
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<build>
...
Then in my run/debug configuration just added runineclipse to the Profiles: box.
(On a side note, to do step through debugging I had to manually add the project to the Source tab.)
The build configuration was just the same package in the Goals: box; and I left the original dependency to have scope provided.
The tomcat7-maven-plugin and its run goal
Requires dependency resolution of artifacts in scope: test
Everythig that is on the compile classpath is also on the test classpath.
Thats why it is working with scope compile.
So the solution in your case would be to mark your dependency as test what even is (imo) semantically correct.
This will make the library available at local test-time, but not in the final artifact.
I am trying to exclude a single library .JAR file from my EAR that is being built via Maven, as this library is included as a JBoss EAP module. I've followed the instructions in the documentation, but I always see this library included anyway. Here's what the relevant pom.xml section looks like:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.9</version>
<configuration>
<!-- Tell Maven we are using Java EE 6 -->
<version>6</version>
<finalName>MenuProject</finalName>
<!-- Use Java EE ear libraries as needed. Java EE ear libraries are
in easy way to package any libraries needed in the ear, and automatically
have any modules (EJB-JARs and WARs) use them -->
<defaultLibBundleDir>lib</defaultLibBundleDir>
<packagingExcludes>**/postgresql*.jar</packagingExcludes>
<modules>
<!-- Register our War as a web module, and set the context root -->
<webModule>
...
As you see, I'm trying to exclude the postgresql*.jar file from being included in my EAR file. But, when I do a build I still see it.
Am I misunderstanding this functionality? Or am I doing it wrong? Any advice?
UPDATE: I should add, this library is added as a dependency for another library that my app depends on. That is why it is being introduced in the first place. I do not need it included in the EAR, as it is available as a JBoss EAP module.
Wrap your dependency type in a project object model pom as a type:
<dependency>
<groupId>${project.that.has.postgres.as.dependency.groupId}</groupId>
<artifactId>${project.that.has.postgres.as.dependency.artifactId}</artifactId>
<version>${project.that.has.postgres.as.dependency.version}</version>
<type>pom</type>
</dependency>
I've inherited a Maven project. I'm just using it as a build tool and I'd like to disturb things as little as possible. I have to make a slight addition to one of the Java files and that addition requires that I include a new jar on the build path. How do I say: here a jar, just use it. It doesn't have to be versioned or depended or downloaded or anything, just use it. Any help would be appreciated.
EDIT: I found this, which actually works (!). If someone who knows about such things could read this answer and if it seems reasonably correct, please close this question as a dup.
EDIT: Nope, I misinterpreted my results. It doesn't seem to work.
By far the best way to manage your dependencies with maven is to get them from a repository, but four total options spring to mind, in order from most desirable to least:
If the jar is a common third-party library, you'll almost certainly find it in some repository somewhere. You just have to add a <dependency> element and possibly a <repository> as well so it knows where to get the dependency from.
A home-grown jar not available in any repo should be deployed to a local repository, like Nexus, which is available to your whole team/company. Then add the dependency to your project just like in option 1. This way it only has to be dealt with once, and everyone else can get the jar via the normal Maven mechanism.
To only deal with the problem locally and not give any reusability of the artifact, you can install it into your local repo (meaning your local cache at ~/.m2/repository) using the install:install-file goal.
Finally, and least desirably, you can use a system-scoped dependency. This means you have the jar file available somewhere in your file system, set the <scope> element of your <dependency> to the value "system", and add a <systemPath> element that contains the full path to the jar in question.
Edit: Since option 4 seems right for you, just put the jar into your project and commit it to your version control. Then, assuming the jar is at lib/foo.jar in your project, add this to your POM's dependencies:
<dependency>
<groupId>some-group</groupId>
<artifactId>some-artifact</artifactId>
<version>1.2.3.4</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/foo.jar</systemPath>
</dependency>
That's all from memory, but it sounds right.
Here are some related answers:
Maven: keeping dependent jars in project version control
I would not recommend using install:install-file from a POM - if it's a once off requirement you're better using that from the command line and documenting it as a preparation step. However, making the build self-contained or providing a repository with the required artifacts are certainly better options.
Here is how to proceed. Create a separate maven project inspired from the following pom.xml.
<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>net.dwst</groupId>
<artifactId>MavenMissingJars</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>Maven Missing Jars</name>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<id>dProguard-4.6</id>
<phase>generate-sources</phase>
<goals>
<goal>install-file</goal>
</goals>
<inherited>false</inherited>
<configuration>
<file>toinstall/4.6/proguard.jar</file>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard</artifactId>
<version>4.6</version>
<packaging>jar</packaging>
<generatePom>true</generatePom>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Assuming there is a /toinstall/4.6/ directory relative to your pom.xml and that a jar called proguard.jar is in there, calling this plugin will copy the jar from your local directory to your maven local repository.
This has to be executed once, that's why it is preferable to have a separate small maven project for injecting missing jars.
Then, add a dependency in your project using the coordinates (artifactid, version and packaging) you have defined in the above pom.xml.