This is what I’m doing to be able to have the concept of “provided scope” dependencies in Gradle (i.e. dependencies not included in release artifacts). Is there a better way?
configurations {
provided
compile.extendsFrom provided
}
This is what I’m doing to be able to have the concept of “provided scope” dependencies in Gradle (i.e. dependencies not included in release artifacts). Is there a better way?
configurations {
provided
compile.extendsFrom provided
}
The corresponding JIRA issue also suggests:
configurations {
provided
}
sourceSets {
main { compileClasspath += configurations.provided }
}
dependencies {
provided '...'
}
I too had this question. With gradle milestone 3, the solution proposed in @evgenyg’s linked JIRA issue didn’t work for me. However, the solution you posed in your question DOES work for me.
Here’s a sample… if you run the list task, you should see commons-lang printed. However, if you comment out the configurations block and uncomment what’s currently commented, nothing gets printed.
apply plugin: ‘java’
/*
configurations {
provided }
sourceSets {
main { compileClasspath += configurations.provided } }
*/
/* */ configurations {
provided
compile.extendsFrom provided }
repositories {
mavenCentral() //add central maven repo to your buildfile }
dependencies {
provided “commons-lang:commons-lang:2.3” }
task list(dependsOn: configurations.testRuntime) << {
println “classpath = ${configurations.testRuntime.collect {File file -> file.name}}” }
@Doug
IIRC with this method you need to remember to manage the dependencies to then exclude provided when it comes to building a war file.
I’m going to mark this one as answered, even though it’s still a workaround right now. If you are interested in this issue then you should follow this forum entry and GRADLE-784.
There are some longer term plans to address this. In short, the concept of a provided set of dependencies is a a characteristic of how something is used and not how it is built. At some point we’ll start modelling this kind of thing and that’s where this logic will sit.
I use the propdeps-plugin for provided scope. They just released v0.0.7 which is compatible with Gradle 2.0.