In 1.0 we plan to provide a more powerful mechanism that achieves the same as provided configurations.

I feel that the names compileOnly and testCompileOnly are more intuitive than providedCompile and providedRuntime. Here's how I define the compile-only configuration variants:

compileOnly
testCompileOnly { extendsFrom compileOnly }

sourceSets {
   main {
      compileClasspath = configurations.compile + configurations.compileOnly
   }
   test {
      compileClasspath = compileClasspath + configurations.testCompileOnly  + configurations.compileOnly
   }
}

The purpose of these two scopes are for when you are compiling against APIs for runtimes that provide them. Neither configuration is present in any runtime. If you want something on the test runtime, then you should just put it in testCompile.

If you need something in compile, test compile and test runtime, then I suppose that would be provided (though a better name might be notPackaged).

compileOnly

I'm wondering what use case that would solve (vs. notPackaged). I guess for the unit tests you need some API in the runtime. For the integration test you would use the package.

notPackaged

This naming points more to the solution we have in mind. From a domain modeling point of view we think the provided, notPackaged, ... information does not belong to the dependency. It belongs to the publication (e.g. the published archive). In Maven this does not matter so much as there is only one published archive.

Hibernate provides a nice use case for this. The JPA spec itself is vendor-dependent. Hibernate published a stand alone dist and an in-container dist. The first would include the hibernate JPA spec in the runtime. The latter not. They are both published by the same project.

I think for convenience it is important that you can provide this information when declaring your dependencies. Something like:

dependencies {
compile("org.hibernate:xyz:2.0")

compile("org.hibernate:jpa:2.0")

}

In the domain model the provided information belongs to the publication. This gives us much more flexibility.

Dan the term comes from Maven which has this same notion. 'provided' makes sense if you think about the implication: the dependency is expected to be provided by the runtime environment. 'compileOnly' and 'testCompileOnly' are ok too, but i don't find them any more inherently intuitive personally. And while Gradle should not be looking to copy everything from Maven nor Ivy, where correlations exist I think it makes sense to reuse the terms used in Maven/Ivy for familiarity sake. IMHO

Hans, if I understand correctly, this notion of package/not-packaged deals with whether the dependency is added to the artifact produced by this project. If I understand correctly, its really getting at "should this dependency be added to the WAR's web-inf/lib?" or "should this dependency be added to the EAR's app-inf/lib?". Which is not really the same thing as 'provided', at least as I understand it. To me, the notion of 'provided' is the same as 'exported' I talked to you and Adam about before, which is more about transitivity. In terms of dependencies you have artifacts you import and those that you export. There are, I think, lots of examples of things you need to import but that you do not want to export because they should be part of the target environment where this gets run. The ones we have talked about are JTA, XML parsers. And yes JPA itself is one in certain environments.

I guess the difference is that in the case of Hibernate, if my understanding of the intent of 'notPackaged' is correct, these dependencies are not packaged anyway. So its a question of whether you want Hibernate to declare that JTA is a 'provided' dependency once, or if you want every consumer of Hibernate to declare it as 'notPackaged'.

I'm hitting a problem right now where providedCompile or similar is necessary.

I'm using AspectJ to weave in the spring-aspects library at build time, but I'm not using JPA. Because of a bug in the Spring Aspects library, it doesn't work if JPA isn't available on the build-time classpath - even though I'm not using it at runtime. I'm loathe to add it as a compile scope dependency, but the library I'm building isn't a war so I don't have providedCompile without defining it myself...

I have the same issue with the ear plugin. I need to filter some transitive dependencies form earlib. AFAIK filtering module dependencies are supported, but local file dependencies are not.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

The use case is now support via compileOnly released with 2.12. The configurations providedCompile and compileOnly are going to be aligned with this issue.