On 06/01/2011, at 5:40 AM, Jason Porter wrote:
>>> On Jan 5, 2011, at 1:58 AM, Mathias Kalb wrote:
>>>
>>>> Hi,
>>>>
>>>> our webapplication contains a JAR with common features for all WARs. It
>>>> is placed at a shared tomcat folder. All dependend JARs (Spring, JSF,
>>>> Apache commons, ...) are also placed at this shared folder.
>>>>
>>>> But there are also dependencies to Tomcat libaries which are provided
>>>> (Servlet, JSP, tomcat).
>>>>
>>>> I want to copy the dependencies and all dependencies of them to a
>>>> special folder for the installation/release.
>>>>
>>>> This works fine, but how can I exclude the provided dependencies
>>>> (servlet, JPS, tomcat)?
>>>>
>>>> I think a "providedCompile" would be very useful for the java plugin (JAR).
>
> It's not currently, but I'm pretty sure Hans and Adam want to add it.
>
I'm not so sure. What does a 'provided' classpath actually mean for a java
project?
To me, the 'provided' classpaths really only make sense when you are bundling
some code to execute in a particular container (container in the abstract sense
here, ie some environment where the code is executed).
This really shouldn't be the concern of a java project. It should be the
concern of the project which builds the bundle. Sometimes these are the same
project, sometimes they are different projects. Sometimes there are multiple
projects which bundle the code. Sometimes the code is included in different
bundles for different environments, where the provided classes are different.
Given this, declaring the 'provided' classpath in the source project, in a
global configuration, really doesn't make any sense.
Instead, I'd do a couple of things:
1. Make it easy to exclude one classpath from another. This is the primitive
that you could use to deal with this problem:
war {
classpath = configurations.runtime - configurations.providedRuntime
}
2. Get rid of the provided classpaths, and instead model the target
environments. For a war, you'd define the target web container, which would
include the provided classpath. This would allow you to build different wars
for different target containers.
The war plugin would wire up some defaults, so that the war targets a generic
web container with the appropriate servlet version. You'd then be able to
configure that web container, or add others.
This same definition would also be usable for deployment, too. The jetty plugin
can use the web container definition to determine which version of jetty to
use, and what to make available in the container classpath.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
