Hi,
I am new to maven development and have been tackling the "skinny" war problem
(http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem).
After a few attempts and considering pros and cons of various solutions and
their implementations I am resigned to the fact that the only solution is the
"right thing" and anything short is going to be a hack that is unwieldy. To
comprehend the skinny war problem you have to comprehend how people
expect maven dependencies to work and the two ambiguities around the
"provided" scope within the context of an EAR and a WAR.
The right solution (as i see it) is to:
1. add a new scope called "application" that is exposed as application
dependencies
2. modify the maven-ear-plugin to utilize application dependencies (as
found applicable by maven) and package them into the bundled lib directory.
3. modify the maven-war-plugin to include into the WEB-INF/lib
directory the application dependencies (as found applicable by maven) when a
configuration the parameter (standaloneApplication) is set to true, otherwise
application dependencies will be ignored and it is expected that they will be
provided by an ear.
4. modify the maven-assembly-plugin to support creating war assemblies
and the inclusion of application dependencies if the assembly specifies that
the war is a standaloneApplication.
Note 1: The semantic meaning of "provided" now becomes "This is much like
compile, but
indicates you expect the JDK or a container to provide the dependency
at runtime."
Note 2: The semantic meaning of "application" is that it is "This is much like
compile, but
indicates you expect that final packaging of the application will provide this
library at runtime."
To update documentation (
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
) it should follow that
* compile
Compile
dependencies are available in all classpaths of a project. Furthermore,
those dependencies are propagated to dependent projects.
* provided
This is much like compile, but
indicates you expect the JDK or a container to provide the dependency
at runtime. For example, when building a web application for the Java
Enterprise Edition, you would set the dependency on the Servlet API and
related Java EE APIs to scope provided because the web
container provides those classes. This scope is only available on the
compilation and test classpath, and is not transitive.
* application
This is much like compile, but
indicates you expect that final packaging of the application will provide the
dependency at runtime. For example, when building a web application for the Java
Enterprise Edition, you would set the dependency on Hibernate and
related business model objects to scope application because the final
application (as packaged in an ear) must provide those classes in the final
distributable and it is not necessary to duplicate these shared libraries
within each web application. This scope is only available on the
compilation and test classpath, and is transitive.
* runtime
This scope indicates that the dependency is not required for
compilation, but is for execution. It is in the runtime and test
classpaths, but not the compile classpath.
* system
This scope is similar to provided except that you have to provide the JAR which
contains it explicitly.
The artifact is always available and is not looked up in a repository.My
immediate concerns are around the interpretation (or lack of interpretation) of
the new scope by existing plugins. The obvious plugins (war, assembly and ear)
can easily be accounted for. I and would have to check all standard maven
plugins.
Adding a new scope should be treated and considered carefully because it is
easy to give and very difficult to take away however I believe that it is the
right solution because of the ambiguity around "provided" and the unnecessary
hacks that are in use to solve the skinny war problem. Furthermore it makes
sense. My implementation touches on quite a few classes to add the new scope
aswell as the 3 plugins mentioned and I can imagine various problems with
plugins not knowing or interpreting the new scope correctly but this just
requires testing.
Are there any recommendations, thoughts or critics on the problem and solution
as I have proposed?
How can I find out the development timelines for 2.0.10 and 2.0.11?
Thank you,
-Timothy Twelves
