[GRADLE-471] Make providedCompile and providedRuntime configurations available outside of the WAR plugin Created: 10/May/09  Updated: 27/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.12-rc-1

Type: Improvement
Reporter: Andrew Pietsch Assignee: Unassigned
Resolution: Fixed Votes: 16


Currently the providedCompile and providedRuntime configurations are defined by the War plugin. There are cases where these configurations need to be used outside of a war environment. One particular example is when creating GWT based libraries (i.e. gwt-user.jar is required to compile the library, but should not be deployed).

Gradle should respect the providedCompile/providedRuntime configurations when deploying to a maven repository.

Comment by Hans Dockter [ 22/Apr/10 ]

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

Comment by Dan Allen [ 07/Sep/10 ]

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:

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).

Comment by Hans Dockter [ 13/Sep/10 ]


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.


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 {

{ notPackaged = true // Excludes it from all publications }


{ notPackaged inContainer // a list of publications where this should be excluded }


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

Comment by Steve Ebersole [ 11/Oct/10 ]

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'.

Comment by Graham Cox [ 08/Dec/12 ]

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...

Comment by Casey McGinty [ 29/Oct/13 ]

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.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 24/Jan/17 ]

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.

Generated at Wed Jun 30 11:30:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.