Thanks for the info Detelin, and the good issue links. I think I can easily live with Gradle's flavor of 'archives', 'testCompile' and 'testRuntime'. But I think 'provided' should be defined in the java plugin as a standard best practice so that we are all more consistent and can share libraries.
The way we use it in our Ant/Ivy syetem, is when we are building a library that needs a particular api jar for compiling, but doesn't want to specify any specific implementation for runtime. The latter is left to the app module when it bundles its war, or even later by the app container. One simple example of this is servlet-api which has its implementation in the servlet container but a library might need to see the types at compile time. So, the conf has to be specified early in the graph at the library where the api dependency is declared and needed. But then it is non-transitive. I see the two 'providedCompile' and 'providedRuntime' in the war plugin, but this seems less optimal and more like a workaround to not having 'provided' in the published libraries. And, yes I agree, I think my next steps will be to move my prototype code into plugins to hook things up more efficiently. Any opinions from the Gradle masters? --carl -- View this message in context: http://gradle.1045684.n5.nabble.com/Ivy-vs-Gradle-configurations-tp4544242p4555468.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
