This directly feeds into how things are autowired up for convenience, and how to easily adjust for someone diverging from the norm.
Technically there is nothing special about providedCompile and providedRuntime except that the war plugin uses them to declare the classpath. Really, what it is doing essentially is the following: classpath = sourceSets.main.classes + configurations.runtime - configurations.providedRuntime We re-wire this to include the jar (manually re-enabled) so it is this: classpath = jar.outputs.files + configurations.runtime - configurations.providedRuntime Since we generate artifacts that are essentially the same, but are targeted at multiple application servers we really have something like this for each task and we simply use the default providedRuntime as the "base" excludes shared by all app servers: classpath = jar.outputs.files + configurations.runtime - configurations.providedRuntime - configurations.provided<AppServerName> If the jar/war (and someday ear) tasks made it very simple to assign a set of "include" configurations and "exclude" configurations in addition to the default ones of compile and runtime I don't think having any additional special named configurations would be necessary. This way nothing changes for the average user, but lays the framework for someone extending the jar/war tasks and simply setting the extra configurations includes/excludes to handle most other cases. -Spencer --- On Thu, 4/14/11, Jason Porter <[email protected]> wrote: From: Jason Porter <[email protected]> Subject: Re: [gradle-user] Work on http://issues.gradle.org/browse/GRADLE-471 ? To: [email protected] Cc: "Adam Murdoch" <[email protected]> Date: Thursday, April 14, 2011, 11:19 PM Sure, framework code that relies on libs that will be in the server. For example with Seam 3 and CDI classes, or Hibernate needing JPA classes. Those classes will be there in the server. These are jar projects, not webapps. On Thu, Apr 14, 2011 at 20:59, Adam Murdoch <[email protected]> wrote: On 15/04/2011, at 1:59 AM, Jason Porter wrote: Has there been any work done on this issue (providedCompile outside of war projects)? I see Hans said this would be a 1.0 thing, and probably something to do with the publishing API rework. I'm not sure we want to do this, at least not without a good use case. Do you have an example of why you want a provideCompile configuration? --Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
