Skinny War

[Timothy Twelves <ti...@yahoo.com>]

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

Re: Skinny War

[Timothy Twelves <ti...@yahoo.com>]

Hi,

1. You are correct - it is up to the ear plugin and the war plugin to package these dependencies correctly.

2. The purpose of having an "application" dependency would be to remove the need to specify every dependency within your ear pom and also remove the need to have an aggregation pom*.  Maven finds "application" dependencies applicable for compile and test classpaths ensuring that test execution and compilation occurs correctly.

The ear plugin treats ejb modules correctly by automatically putting the ejb dependencies in the ear lib folder.  The war pluging would typically put dependencies into its WEB-INF/lib but by declaring the scope of the war dependencies as "application" the ear-plugin should pick up these dependencies as transitive and package them in the ear unless the war is marked as standalone application.

A standalone war would have application dependencies packaged inside its WEB-INF/lib because it is the application.  For a skinny war it is part of a larger application and therefore the application dependencies are transitive.

"application" dependencies can be declared in anywhere normal compile dependencies may be declared.  It may not make sense to define an application dependency within a normal jar project but this still has reasonable use cases with results that make sense.

* The aggregation pom, as i understand it, solves the problem of ensuring that a set of
libraries are all used together and is something that I have wanted for some
time.


Thank you for your feedback.



________________________________
From: Timothy Reilly <tr...@prolifics.com>
To: Maven Developers List <de...@maven.apache.org>
Sent: Monday, 2 February, 2009 21:13:41
Subject: RE: Skinny War

I'm surprised no one has commented. 
Since it's an important issue in my work or anyone that packages ears I
would think.
I'll comment below.

>     1. add a new scope called "application" that is exposed 
> as application dependencies

Having a scope for these seems to be a better approach in my mind. The
term  "application" jars "ear libs" is what I use in day-to-day
conversation. I believe the specification uses the term "bundled
optional classes" and very likely why the dependency attribute is called
"optional". I have no affinity to a particular name.

>     2. modify the maven-ear-plugin to utilize application 
> dependencies (as found applicable by maven) and package them 
> into the bundled lib directory.

So this realizes the benefit of promoting the attribute to a proper
scope? 

Where are these dependencies declared? I think this question is the
major sticking point. 
I've found that I need to build the J2EE parent, or ear project or war
projects separately at times. 
I see two choices wrt where the dependencies are declared (maybe other
ways exist) - 1) declare these dependencies in the parent project, 2)
create a pom dependency aggregation project / a pattern described and
debated on the mailing lists - I think some folks object to it but as
the saying goes "a layer of indirection solves every IT problem". The
solution in my opinion should allow both ways and in the end the dilemma
is really about the build order. I think your solution is reasonable so
long as the reactor (if it's even still called that) can determine the
appropriate build order.

> Are there any recommendations, thoughts or critics on the 
> problem and solution as I have proposed?  

I'm not a maven committer so those guys would have much better insight
about the merit of the proposal and what it would mean exactly to the
war and ear plugins and the latest changes in dependency resolution and
build ordering.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Skinny War

[Timothy Reilly <tr...@prolifics.com>]

I'm surprised no one has commented. 
Since it's an important issue in my work or anyone that packages ears I
would think.
I'll comment below.

> 	1. add a new scope called "application" that is exposed 
> as application dependencies

Having a scope for these seems to be a better approach in my mind. The
term  "application" jars "ear libs" is what I use in day-to-day
conversation. I believe the specification uses the term "bundled
optional classes" and very likely why the dependency attribute is called
"optional". I have no affinity to a particular name.

> 	2. modify the maven-ear-plugin to utilize application 
> dependencies (as found applicable by maven) and package them 
> into the bundled lib directory.

So this realizes the benefit of promoting the attribute to a proper
scope? 

Where are these dependencies declared? I think this question is the
major sticking point. 
I've found that I need to build the J2EE parent, or ear project or war
projects separately at times. 
I see two choices wrt where the dependencies are declared (maybe other
ways exist) - 1) declare these dependencies in the parent project, 2)
create a pom dependency aggregation project / a pattern described and
debated on the mailing lists - I think some folks object to it but as
the saying goes "a layer of indirection solves every IT problem". The
solution in my opinion should allow both ways and in the end the dilemma
is really about the build order. I think your solution is reasonable so
long as the reactor (if it's even still called that) can determine the
appropriate build order.

> Are there any recommendations, thoughts or critics on the 
> problem and solution as I have proposed?  

I'm not a maven committer so those guys would have much better insight
about the merit of the proposal and what it would mean exactly to the
war and ear plugins and the latest changes in dependency resolution and
build ordering.



 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org