I have a war dependency:
<dependency>
<groupId>my.package</groupId>
<artifactId>myservices</artifactId>
<version>0.3</version>
<type>war</type>
</dependency>
Now, this exists in my local repository, and the class exists at WEB-INF/classes/my/package/myservices. When I go to use myservices, however, I get package my.package does not exist. Intelli-J knows to change myservices into my.package.myservices, but trying to import seems to not work at all.
Is there something special I need to do with this war dependency?
As pointed out in the other answers:
In Maven, you cannot just load classes from a WAR artifact the way you can from a JAR artifact.
Therefore, the recommendation is to split off a separate Maven JAR project with the classes you want to reuse, and depend on this project in both the original WAR and the new project.
However, if for some reason you cannot / do not want to split the WAR project, you can also tell Maven that you need a JAR artifact in addition to the WAR. Put this into the POM of your WAR project:
<build>
...
<plugins>
...
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
</plugins>
</build>
Then, when building the WAR project Maven will create a WAR and a JAR from it.
Source: Maven War plugin FAQ
Adapted from doc_180's comment, so it does not get overlooked.
It just doesn't work that way. war files are not supposed to be put on the classpath, but deployed to application servers (or servlet containers) that can deal with their special structure.
Of course you can probably find a custom classloader somewhere that can deal with java war files, but it's just not the way to do it.
Keep your code in a jar, include the jar in your war and in this application. But don't use a war as a dependency, unless you are building an EAR file.
WAR dependencies are handled VERY differently by Maven from JAR dependencies. They are treated as overlays.
http://maven.apache.org/plugins/maven-war-plugin/overlays.html
I think what you are looking for is something a bit different from a WAR overlay. WAR overlays merge the file structures with a "closest wins" model, but that means that things like web.xml are replaced by closest wins, not merged.
If you want merging (which is closer to what most people think of when they start talking about WAR dependencies) you should look at the Cargo uberwar plugin.
http://cargo.codehaus.org/Merging+WAR+files
If your goal is simply to share some classes between two WARs, you should probably just put those classes into a JAR project. Maven in particular is really designed to work on a pom.xml -> a single artifact model (JAR/WAR/etc). Trying to take a single pom.xml and have it emit, say, a JAR for some stuff and a WAR for other stuff is going to be very painful.
Incidentally, if you are working on a team larger than one person, you are going to want an artifact management server pretty fast (e.g. Artifactory, Nexus or Archiva) or you will go crazy dealing with this stuff. ;)
In a WAR, the classes must be located at WEB-INF/classes/... not at classes/....
Anyway I never have tried to reference other classes from a WAR (not JAR), and I do not know if this is possible.
Make sure the dependency is installed in your local repository.
The local repo should look like:
.m2/my/package/myservices/0.3/myservices-0.3.war
If this is not the case, then install the war into the local repository before using it in the dependency:
mvn install:install-file -Dfile="[path-to-war]" -DgroupId=my.package -DartifactId=myservices -Dversion=0.3 -Dpackaging=war -DcreateChecksum=true -DgeneratePom=true
Related
I have a Maven java web app (.WAR) project that includes several libraries, including the Wicket libraries (but I don't think the problem is wicket itself, but rather with maven).
Here's the problem: even tho I only include Wicket 6.20.0, the resulting .WAR contains two copies of the Wicket libraries: 6.20.0 and 6.18.0, as you can see in this screenshot:
Thinking of some conflicting imports I printed the dependency tree using the:
mvn dependency:tree
commnad... but there is no mention of Wicket 6.18.0 in the dependency tree! I also double-checked using Eclipse's "dependency hierarchy" view and I can confirm there's no trace of that import.
I even did a search for string "6.18.0" across the entire workspace with Eclipse, but it's nowhere to be found!
How can I find out what is causing the inclusion of that duplicate version of the library?
Maven doesn't work in this way.
The resolution of more than one dependency with the same artifactId and groupId but with a different version will result to a single dependency (the version used is no determinist).
The presence of two artifacts with the same artifactId and groupId but with two distinct versions in a same lib folder of the WAR is probably related to one of these :
you don't execute mvn clean package but only mvn package.
your use a bugged version of the Maven war plugin. Try to update it to check that.
you have a Maven plugin that copies Wicket jars 6.18.0 in the WEB-INF/lib folder of the target folder during the build of the component.
the maven WAR project you are building has as dependency an artifact of type WAR. In this case, the dependencies of the WAR dependency are so overlaid in the WAR project that you are building.
An interesting Maven issue about duplicated JAR because of WAR dependencies :
JARs with different versions can be in WEB-INF/lib with war as dependencies
Your answer and your comment indicate that actually you have a WAR dependency in your build.
Unfortunately, there is not really a good and long term effective solution to bypass this limitation.
As said in my comment, using the packagingExcludes property of the maven war plugin is a valid workaround for the actual issue :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<!-- ... -->
<packagingExcludes>WEB-INF/lib/wicket-*-6.18.0.jar</packagingExcludes>
</configuration>
</plugin>
But beware, using that will do your build less robust through the time.
The day where you update the version of the WAR dependency and that in its new version, it pulls again a different version of wicket, you have still a risk to have duplicate jars with two distinct versions in your built WAR.
Using the overlay feature by specifying the overlay element of the maven-war-plugin is generally better as it focuses on the overlay applied for the war dependency. It fixes the problem early.
As a result, you could define to exclude any wicket JARs from the WAR dependency :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<version>2.4</version>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<overlays>
<overlay>
<groupId>com.whatever.youlike</groupId>
<artifactId>myArtifact</artifactId>
<excludes>
<exclude>WEB-INF/lib/wicket-*.jar</exclude>
</excludes>
</overlay>
</overlays>
</configuration>
</plugin>
This way is better but this is still a workaround.
The day where the dependency WAR is updated and that it pulls new dependencies (other than Wicket) that are declared in your actual build but with different versions, you may finish with the same kind of issue.
I think that declaring a dependency on a WAR artifact should be done only as we don't have choice.
As poms and projects refactoring are possible, introducing a common JAR dependency which the two WARs depend on and that contains only common sources and resources for the two WARs makes really things simpler.
Well, I figured it out while poking around.
I had a dependency of type "war" in the project:
<dependency>
<groupId>com.whatever.youlike</groupId>
<artifactId>myArtifact</artifactId>
<version>1.0.7-SNAPSHOT</version>
<type>war</type>
</dependency>
Apparently (I wasn't aware of this, my fault here) these type of dependencies will include themselves in the classpath by copying all libs to the main WAR /libs folder, but these will NOT show app in the dependency tree / dependency hierarchy.
I solved by configuring an explicit exclusion in the WAR plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<!-- ... -->
<packagingExcludes>WEB-INF/lib/wicket-*-6.18.0.jar</packagingExcludes>
</configuration>
</plugin>
Use clean install and the double dependency will probably be gone.
Because other libs can use same libs but different version or you tried different version and didn't make mvn clean
The command mvn dependency:tree is telling you the correct information - what you are looking at here is an eclipse / build issue.
Clear out all the target and build areas in your project. If need be, check it out from source control to a new folder.
Alternatively you can build your project in IntelliJ IDEA, and see if you get the correct dependencies (most likely you will).
Is it possible to actually build a maven project containing java code to be built once and the binaries can be shared?
Problem: The project I am trying to build would take me about 3-4 hours and requires high internet bandwidth. I am trying to check the possibility of re using this built project among several other machines.
I have worked with c++ projects involving makefiles earlier and this was pretty simpler. I am new to Java / eclipse and would need help to figure out if this is something really possible.
PS:
I did try to find existing solutions; they were not straight forward or they say that this can't be done.
Build once and share it offline
In Maven, you can build your project only once and get a JAR file fully packed with all dependencies. So that, you can share this JAR to other machines off-line.
Below are the steps to make it.
First update your pom.xml with the below setting
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>com.thanga.MyTest[REPLACE WITH YOUR MAIN CLASS]</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
</plugins>
</build>
Package your project with the goal package assembly:single as shown below
In console,
mvn package assembly:single
In eclipse,
Run this and you can get the two JAR files. One of them MyFullPack-0.0.1-SNAPSHOT-jar-with-dependencies.jar has the full
dependencies loaded.
You can open the JAR to see the dependencies are packed as shown below.
You can share this JAR to other machines off-line without any more build
Is it possible to actually build a maven project containing java code to be built once and the binaries can be shared?
Yes, that's the whole point of Maven, you build the project once, thus generating an artifact (your jar/war ...) which is stored in your local maven repository.
The following command build the project and save it in the local repo :
mvn clean install
However, if you do this, you only have the artifact on your local repo.
A good practise is to create a repository and store your artifacts over there :
https://maven.apache.org/repository-management.html
The use of the following command would store the snapshot dependency on the repository :
mvn clean deploy
You can then reuse your components through multiples computer by specifying the dependencies in your new project's pom.xml file.
You might want to give a look at this guide :
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
You would obviously need to configure the repository and your maven project in order to use a setup of this kind.
First things first. Is your project a web application (war) or an enterprise application (ear) or just a stand alone Jar?
you can use the packaging tag in POM.xml to package your application to a JAR,WAR,EAR
Examples:
<packaging>war</packaging>
<packaging>ear</packaging>
<packaging>jar</packaging>
Then run mvn clean install
In project/src/target you should see the jar,war or ear generated which you can use to deploy on your machine or any other machine.
OR
you can also find that in .m2 folder once you have run install.
If you use maven, a mvn install will install your binary into your ${home}/.m2 folder. Those binary will be available for all other maven job that will run on the same machine.
If you need to share your binary between multiple machine, you can deploy your jars to a repository, like nexus or artifactory.
You can just take the jar file of your target folder and copy it to the other machines, otherwise you could use some share repository like nexus oder artifactory to share your built binary. Maven is capable of automatically deploying artifacts into those repositories
I have this dependency (and many others like this) :
<dependency>
<groupId>jShrink</groupId>
<artifactId>jShrink</artifactId>
<version>3.0.2</version>
<scope>system</scope>
<systemPath>${project.basedir}/../kladr-ear/lib/jShrink-3.0.2.jar</systemPath>
</dependency>
So how to add this JAR to EAR/LIB folder with MAVEN while package?
Looking at the available Maven scopes, I would expect you to mark this as
<scope>compile</scope>
and upload the jar file to your repository (local or remote). Maven should give you the appropriate command line to perform that upload.
EDIT: As noted below, this scope is the default, and as such you could omit it.
Dependencies going into the EAR should generally be based on he dependencies needed for EJB modules. If you have an EJB module with library X on compile scope then that will trigger Maven to want to package the library in the ear that the EJB is part of. No need to manage any scopes at all in the ear pom.
If you don't have any EJBs and only WARs, I would not package libraries in the EAR but simply deploy them as part of the WAR (so they end up in WEB-INF/lib). Keep the web dependencies nice and contained per module, even if that means you get duplicates.
Also compile is the default scope, so you don't ever need to manually declare it unless you're doing it to override another scope set for the dependency.
I have a dependency
<dependency>
<groupId>de.matthiasmann</groupId>
<artifactId>twl</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/TWL.jar</systemPath>
</dependency>
Then I execute mvn assembly:assembly. All natives files and remote maven libs are added, but there is no this jar.
UPDATE
When I am trying to run app by java -jar myjar.jar. It returns an error that there is no class from the above dependency (NoClassDefFoundError : de.matthiasmann.twl.ForExample).
I want to add classes from this jar to myjar.jar (the same what maven does with remote dependencies). How I can configure maven to do that?
See Maven 2 assembly with dependencies: jar under scope "system" not included for why system dependencies are not included and how you can work around it, specifically the mvn install:install-file code is what you want.
You cannot use systemPath, unless your Java EE server/container has that jar configured.
Remember that maven is development and compile time only. Once the war file is built, maven has no effect except for having placed all the desired jars into the WEB-INF/lib folder.
When you specify system scope, it means that it is your responsibility to ensure that the jar is present when the war is deployed. You already have a framework to do that and you do not wish to encumber your build dependency with that jar, but you have to make it available thro Maven only during development.
The other similar scope is "provided". e.g., JBoss or your corporate common deployment Tomcat framework already provides many of the jars like Spring and Hibernate that are loaded by the server startup and common to all apps in the server. Therefore, you would not want maven build to include those into the war file.
The right way, Maven gurus would tell you. is to have your own maven server and build whatever artefacts you need into that server. However, occasionally that is not possible.
Therefore, on such occasions, I create project level repository that is distributed with the project and checked into version control. I run the command mvn install to create a project level directory called, say, "project-repo".
http://maven.apache.org/plugins/maven-install-plugin/examples/specific-local-repo.html (Due to familiarity, most of the time, I build the repo by hand rather than run mvn install).
Then in the POM, I specify file://${project.basedir}/project-repo as one of the repositories. The caveat with this is that in Windows, the slashes other than the pair after "file://" has to be back-slashes when referring to Windows file system paths.
<repositories>
<repository>
<id>my-repo1</id>
<name>my custom repo</name>
<url>http://ho.ho.ho</url>
</repository>
<repository>
<id>project-repo</id>
<name>my project repo</name>
<url>file://${project.basedir}\project-repo</url>
</repository>
</repositories>
YOu can implement this in many ways refer the blog below
http://blog.valdaris.com/post/custom-jar/
If you have such an dependency the best solution is first to use a repository manager and simply put that dependency into the repository manager and afterwards use it as simple dependency.
I am trying to launch a maven project, that I always launched manually in Tomcat, in Jetty. For this I am using the maven-jetty-plugin.
When executing jetty:run It seems like everything goes fine, except for the fact that Jetty does not find the dependencies defined in the POM.
If I run jetty:war, the war is built properly, using the dependencies, so that works. Why is jetty:run not including my libraries in WEB-INF/lib (or anywhere else)?
If you need a dependency for Jetty which resides somewhere other than the main Maven repo, add the following:
<pluginRepositories>
<pluginRepository>
<id>repo-id</id>
<url>http://my_other_repo.edu</url>
</pluginRepository>
</pluginRepositories>
I don't believe Jetty will use the existing repositories in your POM.
It really depends on the dependencies you have defined. For example, if you have defined a JNDI resource in your jetty.xml file, you will need the jetty-plus dependency. However, you will need this dependency for the execution of the plugin only. Plugins can have <dependencies/> and that is where you need to define it.
If you have a list of Jetty-specific classes that the plugin can't find, the best way to look up the dependencies is to use a site like www.jarvana.com.
By 'dependencies', do you mean other projects?
If so, you will need to install (mvn:install) these into the local repository before jetty:run will see them.
It's possible that jetty:war is packaging them and placing them into the lib folder without installing into the local repo.
For me I had one .jar file in my repo that was not getting picked up by Eclipse. I didn't figure out how to fix it in Eclipse, so my work around was to ...
Add a duplicate of the .jar file to the repo under a different groupId (different path under ~/.m2) using this command:
mvn install:install-file -Dfile=dhcp4java-1.0.0.jar -DgroupId=a_abc.hack -DartifactId=dhcp4java -Dversion=1.0.0 -Dpackaging=jar
Reference the new groupId , which requires only to update this entry for the dependency in pom.xml :
<groupId>a_abc.hack </groupId>