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

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