Thanks Adam. I just read all of your replies. I'll summarize in this email.
I think we're all on the same page as to what "provided" is. What it really means all depends on your dependency resolution scheme. Unfortunately, maven is king in that area, and it does not do a good job, so we're ultimately limited to maven's impl when someone uses an artifact's pom. However the solution is implemented doesn't really matter as long as it's easy and DRY -- I don't want to declare my deps twice (via export or exclusion to publish an artifact descriptor). I think what you've suggested sounds fine. I really hope to see this in Milestone-3, we've been waiting and hacking solutions for a long time. On Sunday, April 17, 2011, Adam Murdoch <[email protected]> wrote: > > On 16/04/2011, at 2:07 AM, Luke Taylor wrote: > On 15/04/2011 15:22, John Murph wrote: > On Thu, Apr 14, 2011 at 10:59 PM, Adam Murdoch > <[email protected] <mailto:[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? > > > > I'll just chime in that we also have a need for this. It's easy enough > to solve (we have a "provided" custom configuration we are using), but > it seems common enough that Gradle should provide this right out of the > box. > > > We also have a "provided" configuration and it seems like a common > requirement. Lots of project modules are compiled against the > servlet-api, even though they aren't actually WAR files, and you don't > want it exported as a transitive dependency. > > But why not? It is actually a runtime dependency of the code, isn't it? > > > --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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
