We Keep Coding

JAR under EAR(src/main/application/lib) are not part of ClassPath in Maven - [Resolved]

I am working on converting a J2EE application to Maven where the EAR project will contain a WAR module. I have followed the below URL to convert the project and it does work with some minor changes:
https://www.ibm.com/docs/en/wasdtfe?topic=projects-converting-existing-maven
In the current project, there are some libraries under the EAR folder which I cannot move to the local maven repository. The reason is old legacy code which expects these library names to be intact (myCommon.jar and no version to be added like myCommon-1.0.jar).
As a workaround, I placed these libs under EAR->src->main->application->lib folder. There is no build failure observed but the major problem is with the ClassPath for these EAR lib files as shown below:
[err] java.lang.ClassNotFoundException: com.myClass.classFromWAR
[err] at java.lang.Class.forNameImpl(Native Method)
[err] at java.lang.Class.forName(Class.java:332)
E.g. myCommon.jar contains code like the below:
public void EARLibFunc( string classNameFromWAR){
.........
//E.g. classNameFromWAR = "com.myClass.classFromWAR";
final Class warClass = Class.forName( classNameFromWAR );
.........
}
Calling above function from the java files inside WAR module reports ClassNotFoundException: EARLibFunc("com.myClass.classFromWAR");
The directory structure looks like the below:
WARProject
-src
----com
--------myClass
------------classFromWAR.java
EARProject
-src
----main
--------application
------------lib
----------------myCommon.jar
The jar files from EAR/src/main/application don't seem to be part of the ClassPath.
Can you please suggest the best practice to handle such an issue? What should be the correct layout of the EAR libraries to make it part of the ClassPath? Please be informed that the code from the EAR libraries cannot be changed (legacy code dependency issue).
For reference here are my pom settings:
WARProject pom.xml:
.......
.......
<groupId>MyApp</groupId>
<artifactId>MyApp</artifactId>
<version>3.5</version>
<packaging>war</packaging>
<description>MyApp Maven</description>
........
<build>
<resources>
<resource>
<directory>Java Source</directory>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<warSourceDirectory>Web Content</warSourceDirectory>
</configuration>
</plugin>
</plugins>
</build>
......
EAR Project pom.xml (contains WAR module as dependency):
.....
<groupId>EARProject_EAR</groupId>
<artifactId>EARProject_EAR</artifactId>
<version>3.5</version>
<packaging>ear</packaging>
<description>My Project EAR</description>
<build>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.10</version>
<configuration>
<version>7</version>
<skinnyWars>true</skinnyWars>
<defaultLibBundleDir>lib</defaultLibBundleDir>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>MyApp</groupId>
<artifactId>MyApp</artifactId>
<version>3.5</version>
<type>war</type>
</dependency>
</dependencies>
......
SOLUTION:
The crash reported for the CLASSPATH is resolved. Since I am moving an old legacy application to Maven, there were some old references to be cleaned-up. Below changes were required:
There were duplicate classpath references in the eclipse Project
(Project -> Properties -> Java Build Path). Even though I had
dependencies mentioned in the pom.xml of the WAR file, the project
properties were also having its references. This may or may not be
the real reason.
Reverted earlier workaround solution. Removed libraries from
EAR->src-main->application->lib and added those as dependency in the
WAR pom.xml reference. Though it has re-created other legacy issue
but I believe this will adhere to the best practices.

I think, it should be possible this way:
Install the jar in your local maven repository.
Configure the maven-ear-plugin to include third party libraries as shown here.
Add <bundleFileName>myCommon.jar</bundleFileName> to jarModule in order to give your JAR file the desired name within the EAR.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>3.2.0</version>
<configuration>
[...]
<modules>
<jarModule>
<groupId>artifactGroupId</groupId>
<artifactId>artifactId</artifactId>
<includeInApplicationXml>true</includeInApplicationXml>
<bundleFileName>myCommon.jar</bundleFileName>
</jarModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
More information can be found at the usage page of the plugin.

Maven assembly plugin jar with dependencies - plugin not running

I've got a Maven project (submodule of a parent project) which I need to create a "jar with dependencies" for. I added the maven-assembly-plugin to the pom.xml, but it didn't create the artifact. I've slowly stripped everything else out of the pom.xml, until all that's left is dependencies and this plugin, and it still won't create a jar with dependencies. Watching the output of mvn clean package it runs clean, compile, and jar but never runs the assembly plugin. I don't know why. Here's the pom.xml, can anyone spot the problem?
<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>project</groupId>
<artifactId>project-name</artifactId>
<version>1.0</version>
<name>project-name</name>
<properties>
<build.time>${maven.build.timestamp}</build.time>
<spring.framework.version>4.3.1.RELEASE</spring.framework.version>
<spring.security.version>4.1.1.RELEASE</spring.security.version>
<spring.webflow.version>2.4.2.RELEASE</spring.webflow.version>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<build>
<sourceDirectory>${project.basedir}/src/java</sourceDirectory>
<resources>
<resource>
<directory>${project.basedir}/src/resources</directory>
</resource>
</resources>
<outputDirectory>${project.basedir}/target/classes</outputDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
[snip]
</dependencies>
</project>

Maven reference :
Assemble an application bundle or distribution from an assembly
descriptor. This goal is suitable either for binding to the lifecycle
or calling directly from the command line (provided all required files
are available before the build starts, or are produced by another goal
specified before this one on the command line).
The asssembly:single goal may be used in two ways :
either by binding it to the lifecycle
or by calling it directly from the command line
You do no one of them.
You can for example do it to bind the plugin execution to the package phase :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<phase>package</phase> <!-- bind to the packaging phase -->
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
Now the mvn package or mvn install command will create the jar with dependencies.
You can also keep your actual plugin configuration and run the mvn assembly:single command.
The second way allows to create the jar with dependencies on demand and not for every build.
Which may be desirable if the jar creation is a long task that doesn't need to be executed at each build.

mvn exec:java doesn't set classpath properly

I'm trying to run a Java program with Maven on the commandline, but it is not putting the correct entries on the classpath. If I run the program in IntelliJ (which has Maven support), the classpath has 80 or so entries including my project's jar dependencies, the compile program classes, and the resources from src/main/resources. If I run the program with mvn exec:java, I only get one entry for apache-maven-3.0.4/boot/plexus-classworlds-2.4.jar. There are no references to plexus in my entire project tree. Where is this entry coming from and why are the other expected classpath entries not there?
Maven version: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
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>com.example</groupId>
<artifactId>MyProject</artifactId>
<version>SNAPSHOT</version>
<packaging>jar</packaging>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<!-- lots of dependencies -->
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<showDeprecation>true</showDeprecation>
<showWarnings>true</showWarnings>
<executable>${env.JAVA_HOME}/bin/javac</executable>
<fork>true</fork>
</configuration>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${basedir}/src/assembly/assembly.xml</descriptor>
</descriptors>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<configuration>
<mainClass>com.example.MyApp</mainClass>
<executable>${env.JAVA_HOME}/bin/java</executable>
</configuration>
</plugin>
</plugins>
</build>
</project>

By default, the exec:java uses the 'runtime' scope, which will not bring your dependencies set with the 'compile' scope.
You can use:
exec:java -Dexec.classpathScope="compile"
To include the compile dependencies (not 100% sure about the -D syntax, but the variable is exec.classpathScope for sure).
This should do the trick.
If you need more info/options, the plugin page has some options listed: http://mojo.codehaus.org/exec-maven-plugin/java-mojo.html

I don't know about Plexus (I would guess it is a dependency of the Exec Maven Plugin?) , but try running with debugging turned on: mvn exec:java -X and it should be more clear that your dependencies are being added to the classpath:
....
[DEBUG] Invoking : com.example.MyApp.main()
[DEBUG] Plugin Dependencies will be excluded.
[DEBUG] Project Dependencies will be included.
[DEBUG] Collected project artifacts [log4j:log4j:jar:1.2.16:compile, commons-lang:commons-lang:jar:2.6:compile]
[DEBUG] Collected project classpath [C:\MyProject\target\classes]
[DEBUG] Adding to classpath : file:/C:/MyProject/target/classes/
[DEBUG] Adding project dependency artifact: log4j to classpath
[DEBUG] Adding project dependency artifact: commons-lang to classpath
....
You should see lots of the "Adding project dependency artifact" messages.

How to run a plugin only for "war" package type in Maven?

Provided two Maven projects: J (jar), W (war); both depend on one parent P (pom). The parent has a plugin, which must only run for the project "W".
How does one go about doing this:
without creating separate parent projects
without using a profile (so build must still be executed with mvn clean package)
J (jar)
<project>
<parent>
<artifactId>P</artifactId>
</parent>
<artifactId>J</artifactId>
<packaging>jar</packaging>
</project>
W (war)
<project>
<parent>
<artifactId>P</artifactId>
</parent>
<artifactId>W</artifactId>
<packaging>war</packaging>
</project>
P (pom)
<project>
<artifactId>P</artifactId>
<packaging>pom</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>classes</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

I think you can achieve this using Profile Activation. Ideally, the activation condition would be something like "packaging type is war", but apparently, this condition cannot be implemented in Maven. However, in your case, there is a condition that can be implemented and that is probably equivalent in practice: "there is a src/main/webapp directory".
This is how your pom.xml might look like:
<profiles>
<profile>
<activation>
<file>
<exists>src/main/webapp</exists>
</file>
</activation>
<build>
[plugin configuration]
</build>
</profile>
</profiles>

One way to do this would be to place the plugin in the parent pom within <pluginManagement> section. Thereafter specify the plugin in the project(s) that you want it to run.
In your case, you would specify the plugin for project J and not W.
P
<build>
...
<pluginManagement>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>...</artifactId>
... other plugin details ...
</plugin>
</plugins>
</pluginManagement>
...
</build>
J
<build>
...
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>...</artifactId>
<plugin>
</plugins>
...
</build>

Short answer: Maven doesn't appear to have a good way to do what you're trying to do. I've spent a fair amount of time trying to solve a similar problem and haven't found anything satisfactory.
You've already discovered two of the possible solutions: introduction of an additional parent pom for the wars (perhaps the additional pom extends the original parent so you don't have to duplicate all of its config), or duplicating the jar plugin config in all of the war poms. As you've said, neither of these is ideal.
Another possibility is to use the maven-assembly-plugin instead of the jar plugin to build the classified jar for the war projects. The assembly plugin is not included in the default lifecycles for either jar or war packaging, so you could configure it in the parent's <pluginManagement> section and then only reference it in the war projects as Raghuram described. If you need a custom assembly descriptor you will probably want to follow the sharing the assembly descriptors example.

How to resolve cyclic dependency in supplementary Maven sub-module?

There is a multi-module Maven-3 project, where one of sub-modules is used as <dependency> in all other modules. At the same time, all sub-modules inherit from parent module. Such a structure leads to cyclic dependency. How can I resolve it?
Project structure is rather typical:
/foo
/foo-testkit
/foo-core
This is parent foo/pom.xml:
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>checkstyle/checks.xml</configLocation>
</configuration>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>foo-testkit</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
In parent foo/pom.xml I specify how and when checkstyle plugin has to be executed in every sub-module. But I don't need checkstyle to be executed in foo-testkit, which is a sub-module inheriting from foo, but is at the same time a dependency..

One way is to disable the checkstyle plugin for module foo-testkit by adding the below to foo-testkit's pom.xml file.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
If that is not to your liking, another way is to move the checkstyle plugin configuration from build/plugins to build/pluginManagment/plugins in the parent pom.xml file. Then in each module you want checkstyle executed, add this to the build/plugins section of each module's pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
This invokes the plugin for that module and the configuration specified in the parent pom.xml under the pluginManagement section will be applied. You can verify that is working correctly by running mvn help:effective-pom on that module.

I agree with Tim Clemons's answer, but there is also an alternative, make your project nested.
root
/ \
common sub-root
/ | \
sub1 sub2 sub3
Define the dependency to common in the sub-root pom. I'm not saying this is a best practice, but it is a solution to your problem.

So I take it the parent pom is referencing one of the submodules as a dependency? I would suggest if you have any build logic going on in the parent module you push it down into a new submodule. The parent should limit itself to specifying the <modules>, <pluginManagement>, and <dependencyManagement> sections. All other work should be farmed out to submodules.
See the following for more advice on organizing multi-module projects:
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html

If you don't actually need it in foo (only in its sub modules), you can solve the cyclic issue by moving the plugin definition from the build segment to a pluginManagement segment in foo/pom.xml.