a. EAR A --> Contains a bunch of 3rd party libs in APP-INF/lib E.g. log4j, axis, etc
b. WAR B --> Has some classes which need say log4j to compile
c. WAR C --> Has some classes which need say log4, as well as axis to compile
I want the POMs of WAR B & WAR C to use the libs inside EAR A to compile. I do not intend to package the dependency jars into the generated EARs for B & C.
Finally on server EAR A would be deployed as a shared library for WAR B & WAR C.
I am trying to simulate the shared library concept of Weblogic basically. At the time of building my war files B & C I want the compilation to run fine by referencing the jars/dependencies already specified inside EAR.
Based on the article, looks like adding EAR A as dependency with "import" scope to the POMs of WAR B & WAR C should do the job. Please correct me if I am wrong.
However at the time of packaging WAR B & WAR C I don't want the dependency jars to get packaged as part of the WAR file. I guess I can achieve that by using some exclusion filters.
EARs are not "shared libraries", whether you use Maven to build or not.
An EAR is a deployable J2EE web component. As part of the deployment process, the EAR is installed in the appserver in its own unique classpath, which cannot be accessed via the classpaths of any other WARs or EARs in that server, and vice versa (since they, too have their own unique classpaths).
You can build library JARs as Maven components and make them dependencies for both WARs and EARs, but in any event, an EAR couldn't serve as a classpath library because the actual classes inside the EAR aren't located where the appserver's classloader will find them.
Customer surveys are for companies who didn't pay proper attention to begin with.
I want the compilation to run fine by referencing the jars/dependencies already specified inside EAR.
That is not how Maven works. Maven stores each artifact (JAR, WAR, EAR) separately, and you need to refer directly to your artifacts.
And as Tim pointed out, using an EAR as a dependency won't work because it is not a valid classpath item - there is no visibility to the JAR or WAR files it contains.
Joined: Aug 23, 2010
@Peter, @Tim - Both of you are totally correct in what you are saying and I am aware of that. However I am getting introduced to Weblogic for first time at my new workplace and I come across this concept of shared libraries in Weblogic where a war can have a dependency on another war's included libs. It looked weird to me as well when I first saw it. My intention was to replace regular Weblogic workshop builds (using shared libraries) with Maven equivalent.
Did some research and it turns out that what Weblogic internally is extract out the contents internally and add to classpath(at a very high level).
Anyways I have been able to achieve what I wanted using the Maven Warpath plugin. So of posting it so that others looking to achieve the same can find it easily.