This is specially for JavaPlugin I believe

Not sure why that would be the case, but ok.

For now the solution is to create a new configuration:

configurations {
provided
}

and set it to be used with your compilation classpath:

sourceSets {
main

}

this way it will not be inside your runtime deps. thanks to Steve Ebersole.

Could you please provide a more complete example how to configure the "provided" dependency scope in real life set up?

~/build.gradle:

subProjects {

configurations

sourceSets {
main

}
}

~/Module/build.gradle:

dependencies {

provided 'org.axonframework:axon-core:0.6'
}

Wouldn't it be a whole lot simpler and more intuitive to just remove the magic inheritance and honor what the user sets for compile vs. runtime classpath? Direct Ivy cnfigurations don't do magic inheritance: They inherit if you specify to inherit and do not inherit by default. The provided configurations discussed here and those present for the war plugin add unnecessary complexity. Am I the only one who thinks it is crazy to be adding lists which subtract from other lists when all use cases could be handled in a straight-forward manner by just specifying positive lists.

To handle the common situation where most compile classpath elements are also desired on the runtime classpath, what is so difficult about

compiletimeArtifacts = [...]
runtimeArtifacts = [...]
runtimeArtifacts.addAll(compiletimeArtifacts)
compiletimeArtifacts.addAll([compileTimeOnlyArtifacts...])
dependencies {
    compile compiletimeArtifacts
    runtime runtimeArtifacts

Here are some use cases the we leverage 'provided' for:

We have the 'provided' conf set up in the Ivy default way. It is like 'compile', but 'runtime' does not inherit from it. When we setup the javac classpath for compiling, we include all jars from 'compile' and from 'provided'.

In use, there are 3 cases where we find it helpful:

1) When you have an API library that a module needs to compile against, but whose implementation may be provided by a totally different jar at runtime, either by the app in its war, or by the app container. Some examples of this might be servlet-api, ojdbc, etc.

2) Provided also gives you a way of having a general non-transitive compile-time conf. This is useful, for example, if your library needs a jar to compile against, but you know that downstream builds won't need it implicitly. For example, for compile-time-only annotation processing, or other compiler helper libs.

3) Another use case is for libraries that provide optional services, where each optional service requires runtime support only if it is enabled. The final app build gets to decide which services it will want, and adds the runtime conf on those in its build. This allows the apps to opt-in to these services, instead of the war task's (unmaintainable) approach of requiring apps to opt-out or suppress dependencies that they don't want.

A variation of the 3rd item is when you have giant fat 3rd party libraries like wlfullclient that bundle both the APIs needed for compiling and a bloated runtime that you might not actually need. Using 'provided' on these allows them to be skipped by apps that don't need them.

Is the approach here (adding directly to the source sets) better than the approach used in the WarPlugin (provided.visible = false, and compile.extends provided)? The WarPlugin approach seems a little simpler.

Though I wish there was a simple way to define "providedCompile" and "providedRuntime" for all Java projects without conflicting with the same names used by the WarPlugin.

I think the issue I have created (GRADLE-1709) is a duplicate of this.

I often use lombok in my projects which is only needed at compile time and doesn't need to be exported for runtime, so I face this problem very often. Another good example is annotation based source code quality tools like FindBugs which mainly use SOURCE retention policy for annotations.

There are some workarounds out there but I would agree with Blain Simpson that it would be easier not to have runtime extend from compile by default.

PS. Could someone with authority mark GRADLE-1709 as a duplicate? Thanks.

Responding to Russ' comment: The variation that I am asking for is to have it available in the JavaPlugin because that is exactly where the provided confs need to be specified: when building the libraries. Then the WarPlugin should leverage the knowledge of provided confs and leave those out of the war or let the app add them in as needed.

Without having a standard provided conf across JavaPlugin and WarPlugin, there is no way to coordinate this cleanly. The hack of having the app / WarPlugin remove things at package-time seems very brittle--how will it know exactly what it should remove?

I strongly agree that first-class support for optional and provided dependencies is important. As Carl points out, this need is felt particularly by framework developers building their libraries with Gradle. It's a different audience than the typical application developer building, for example a web app.

Folks may be interested to see what we've done within the Spring Framework's Gradle build to introduce what feels like first-class support for optional and provided deps.

Here's an example of declaring dependencies as 'optional' or 'provided' within spring-framework's build.gradle:
https://github.com/SpringSource/spring-framework/blob/963b4e49a98e85e70989427c3e8faec2e408ba5d/build.gradle#L157

The optional and provided objects there are actually closures that add the given dependency to a data structure declared in publish-maven.gradle. This line demonstrates applying the publish-maven.gradle script to all spring-framework subprojects:
https://github.com/SpringSource/spring-framework/blob/963b4e49a98e85e70989427c3e8faec2e408ba5d/build.gradle#L48

And here is the declaration of the optional and provided closures. You can see how they append the dependency to their respective optionalDeps and providedDeps arrays:
https://github.com/SpringSource/spring-framework/blob/963b4e49a98e85e70989427c3e8faec2e408ba5d/publish-maven.gradle#L7

Finally, you can see how these arrays are interrogated when generating the Maven poms for each submodule jar:
https://github.com/SpringSource/spring-framework/blob/963b4e49a98e85e70989427c3e8faec2e408ba5d/publish-maven.gradle#L21

Again it's unfortunate this workaround is necessary at all, but this approach does end up with a nice enough syntax when declaring dependencies. Hope it's of use to others. And thanks to Peter Niederweiser and his Spock project for the original inspiration.

I disagree about support for 'optional'. Even the Maven team acknowledge 'optional' as a mistake. 'optional' is used to circumvent badly isolated dependencies.

Hi Steve,

Understood, and I know it's a justifiable reluctance to repeat this mistake that has kept the Gradle team from implementing 'optional' dependency support thus far.

What's actually necessary is expressing that "this project builds against org.foo:bar:1.2.3, but clients of this project's artifact(s) need not necessarily have it on their classpath at runtime. i.e. this dependency is is required at build-time, but optional at runtime.

Even better would be expressing that this project builds against org.foo:bar:1.2.3, and clients of this project's artifacts may safely run with org.foo:bar versions [1.2.0, 1.3.0) on their classpath. (without going down the OSGi rabbit hole).

"optional" dependencies in our Gradle-generated POMs are a poor man's version of this today. We don't have to publish optional dependencies in our POMs at all, but we do it just to give users a 'recommendation' about which version of a library to use, i.e. "we build against this version, so you're safe to run against it if you need to".

So there are three related concerns here:

1. the version of a dependency that my project builds against
2. whether that dependency is required to be present on a client's runtime classpath
3. the version range of the dependency that my project is compatible with

I've mentioned the above to the Gradle team previously, and while they generally agree, I'm not sure there are any concrete plans to make this sort of thing happen.

Chris we used to have the same exact things (optional deps) in Hibernate as well. And I can tell you from experience its strictly a mistake of not isolating dependencies properly; a mistake in how you structure the projects. You never need to use optional.

'provided' is a different beast. That actually is needed. There are lots of times when you need to compile against a dependency that should not become transitive.

It is certainly possible to arrive at a module decomposition that eliminates any need for optional dependencies; there's no theoretical argument to the contrary. Rather it's a question of tradeoffs in practice. In Spring's case, perfect dependency isolation would equal a perfect explosion of modules. Our choice over time has been to organize modules in a relatively coarse-grained fashion, grouping conceptually related functionality together, allowing users to pick and choose at a high level which parts of the framework they're interested in, and not forcing them to micro-manage dozens of jars.

This means that a user who wants to take advantage of Spring's ORM support may compile and run against spring-orm.jar, and it's then up to the user whether they will be using the Hibernate or EclipseLink support therein. At this point, the user needs to add one of those dependencies to their classpath – neither will be dragged in transitively, because they're "optional".

There is room for argument here as to whether this is the 'right' or 'best' approach. It is indeed possible that we could publish spring-orm-core.jar, spring-orm-jpa1.jar, spring-orm-jpa2.jar, spring-eclipselink-1.jar, spring-eclipselink-2.jar, spring-hibernate3.jar, spring-hibernate4.jar and so on, perfectly isolating dependencies as we go, and simply creating a different kind of hassle for the user. It's just pushing complexity around at this point, and we chose the side of the tradeoff that results in fewer modules and optional dependencies instead of many modules with isolated dependencies.

The point of this conversation is not to pass judgement on this approach, but rather to point out that there do exist legitimate and well-reasoned use cases for optional dependencies.

The good news is that Gradle has been flexible enough to allow us to build what we needed without too much fuss; and in any case we're agreed that 'provided' is a necessary concept. I'll just offer here that perhaps any future support toward provided dependencies in Gradle could be implemented in a fashion flexible enough to accommodate optional dependencies too, so that teams like ours don't have to roll their own every time.

Sure, and its not my place to decide. My point is simply that this is a request to add standard support for the 'provided' configuration which most everyone seems to agree is a valid configuration. Not everyone agrees that 'optional' is a good thing. So I'd rather not have that taint the decision of whether 'provided' ever actually gets added.

Basically, don't piggy back!

Agreed. We shouldn't throw the provided baby out with the optional bathwater

Any update on this?

I'm also interested in an update on this. Whilst the workaround above works (creating a provided configuration and adding it to sourceSets.main.compileClasspath, etc.) it does seem to confuse the Eclipse STS Gradle plugin.

My use-case is that I'm building a custom Ant task, so I would like the Ant JAR to have "provided" scope, since it will already be present at runtime. Using the solutions above with the Eclipse STS Gradle plugin, the Ant JAR doesn't make it onto my Eclipse build path, so I get compile errors.

Dan you should be able to get in on the eclipse classpath with this:

eclipse.classpath.plusConfigurations += configurations.provided

Thanks. I'll try this when I get home tonight. However, I'm assuming this is for the Gradle Eclipse plugin? (That is, for having Gradle generate the Eclipse .classpath and .project files.) I'm not using those - I'm using the SpringSource plugin inside Eclipse to pull a managed classpath out of the Gradle build script.

Ah... You're correct, that's for Gradle's eclipse plugin. I'm not too familiar with that STS plugin, so I don't know where it determines its classpaths from.

@Danny, they both share the same model. If you change 'eclipse.classpath' then both plugins will see the change.

Thanks, that works. But I have now had to add the Eclipse plugin to my Gradle build file when I wouldn't otherwise use it.

I still think the Java plugin would benefit from having a 'provided' config by default. It doesn't look that hard, and I'm struggling to understand why this issue is so contentious and not getting traction. With reference to figure 23.2 of the documentation (http://www.gradle.org/docs/current/userguide/userguide_single.html#customJavaSourceLayout), it seems that all you need is another conf called 'provided' which is 'used by' the 'compileJava' task, the 'compileTestJava' task and the 'test' task.

I have to agree with Danny here. Why is this taking so long to get in? This seems like a total no-brainer. What are the arguments for Gradle not supporting this?

I agree with Danny and Steve and many others. As I enumerated in my email from over a year ago on 06/Jul/11, the support for provided is important for larger ecosystems that have to manage many many dependencies. In our case a few hundred. We're using provided with Ant+Ivy now and without this in Gradle it adds an extra burden for our migration.

Our use case for a "providedCompile" configuration for a Java project is the following: we need a compile time dependency against the JNLP API jar. However, we don't want this dependency to be carried out at runtime with our project JAR, since the needed JNLP classes are already provided by the JRE at runtime.

The lack of this is a killer. There are cases where you just CANNOT deploy a JAR that is required for compilation. Servlet-api is such a common example. And without this moving into Gradle formally, the IDE's (Intellij plugin for one) don't see the new JAR's and add them to their provided scope; therefore requiring manual classpath changes.

@Jayson, here's the workaround I use for the intellij plugin:

idea {
    module {
        scopes.PROVIDED.plus += configurations.provided
    }
}

And here's the complete workaround:

configurations {
    provided
}

sourceSets {
    main { compileClasspath += configurations.provided }
}

idea {
    module {
        scopes.PROVIDED.plus += configurations.provided
    }
}

I did find the documentation linked from GRADLE-2055 to work, feeding Intellij what I need. So my changes to my project are:

use providedCompile in war projects for javax.servlet-api instead of custom configuration.

in non war projects, use custom scope, with the addition of informing the idea plugin about the scope as documented in http://gradle.org/docs/current/dsl/org.gradle.plugins.ide.idea.model.IdeaModule.html#org.gradle.plugins.ide.idea.model.IdeaModule:scopes

I do this in afterEvaluate to make sure subprojects that add to the scope have all the dependencies added.

I've written up how to make this work (plus how to get it integrated with the Eclipse STS Gradle plugin) on my blog

There is an additional issue: Since Gradle does not have provided dependency it does not respect dependencies with "provided" scope in Maven POMs.

For example our project depends on foo.jar created with Maven. One of dependencies in the foo jar was changed to provided scope and as a result it disappeared completely from Gradle dependencies report.

Some new discussion here: https://github.com/gradle/gradle/pull/109

Knowing Carl Quinn's environment and seeing similar issues in mine, I'll add one more request for 'provided' scope for the Java plugin. Ideally

• the name should line up with the war plugin's scope of the same nature
• the scope defined in one should not clash with the other

I have implemented 'providedCompile' in our common build files, as part of a plugin which each project applies. Unfortunately, I have yet to update the sub-projects which build war files and include the Jetty plugin. Jetty includes the war plugin, which blindly declares 'providedCompile' scope, and so collides with the 'providedCompile' I declared before-hand. I am about to rename 'providedCompile' to 'provided' yet this could lead to other issues.

Knowing Carl, he is likely building class files using eMacs macros too. Yet, agreeing with Matt on the naming across plugins...

I ran into something recently that I think is related to this. Guava (com.google.guava:guava:13.0.1) has jsr-305 (com.google.code.findbugs:jsr305:1.3.9) as a dependency in the provided scope. Running the javadoc task for a project that depends on guava (v13+ only) will produce a bunch of warnings (there are a bunch, but they're all very similar, so I cherry picked a couple lines).

guava-13.0.jar(com/google/common/util/concurrent/Monitor.class): warning: Cannot find annotation method 'value()' in type 'GuardedBy': class file for javax.annotation.concurrent.GuardedBy not found
guava-13.0.jar(com/google/common/util/concurrent/AbstractService.class): warning: Cannot find annotation method 'value()' in type 'GuardedBy'

I don't know if I should be putting jsr-305.jar on the classpath for the javadoc task, which gets rid of the warnings, or if I should simply ignore the warnings. From what I can see, my generated javadocs don't have any references to the things being complained about, so I assume the warnings are safe to ignore.

If those warnings aren't safe to ignore, could first class support for a provided scope make sure the needed dependencies end up on the classpath for the javadoc task?

Is there any plans to implement this request?

+1. I am surprised this has still not been implemented.

+1 we need this ...
My use case is to compile ejb (need ejb api ) without to grab api on the final project distribution (ear/lib)
Unfortunately (but why ?) the given workaround don't work (gradle 1.6)

The spring people have created a plugin that adds "provided" and "optional" scopes to the java, eclipse, idea and maven plugins, ref https://github.com/SpringSource/gradle-plugins/tree/master/propdeps-plugin.

Is this something that could be imported into and maintained as part of the standard distribution?

We have 103+ votes so far on this issue. I would like to know where the project stands on this, like changing the status to something like "WILL-NOT-FIX" or "IN PROGRESS". Also, if the voting system is not driving anything, it could be should be removed from the tool, we already have the watch count.

@Sebastien: We moved to https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin and have no problem with it.

@Andre: That plugin caused me a major headache after I updated to Gradle 1.8, cf. http://forums.gradle.org/gradle/topics/how_can_i_exclude_all_transitive_dependencies

The fact that this issue has been around for nearly 4 years is pretty much the opposite of "The sweet spot in between standardization, declarativeness and necessary flexibility."

The comments above have given various examples of good reasons for the "provided" scope.
My current one is the implementation of a javax.servlet.ServletContextListener, i.e. the classic servlet-api dependency for which providedCompile and providedRuntime has been added to the 'War' plugin.

Yes, I've been able to solve this by means of https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin - but it's quite intrusive. I don't think that 'idea' and 'eclipse' configuration should "leak" into the build file. It seems to work fine for me but Tilos comment directly above mine isn't exactly reassuring...

I frankly don't understand why you insist that this shouldn't simply be added even if you'll come up with a better approach in the future. It wouldn't be the first deprecated feature and definitely won't be the last either.

The new "maven-publish" approach that will replace the other ways, doesn't work with propdeps-plugin, so the pom generated has "runtime" for all the dependencies' scope.

Extract from: http://www.gradle.org/docs/current/userguide/publishing_maven.html ->
"Eventually this new publishing support will replace publishing via the Upload task."

please provide this scope also for non-war packaging. it would be really usefull.

Strange that Gradle doesn't support this yet. Pls make it work correctly with IDEA plugin

Is there any word on when this bug will be resolved closed?

It has been more than 4 years now that this issue has been opened, and it has 100+ votes.

I have read on Github that some core developers consider "provided" as broken, but I (and I guess, the 100+ voters) beg to (strongly) disagree; it is quite the opposite: Maven's "provided" scope is darn useful.

Why not just implement it? I see no reason NOT to implement it.

STILL not here as of version 1.10, and it doesn't look like 1.11-rc* have it either... Come on, gradle!

This seems not to work for android-library plugin. I tested it with android plugin and the jar classes could not be found in the dex file. but when I use provided for a jar file included in a library and the use that library in my app, the jar classes end up being present in the dex file.

The vigil continues. It's not in 1.12-rc1 either.

Can we at least get a conversation started about this somewhere? The last time it was raised on the gradle-dev list, it was met with the forlorn sound of crickets.

There is not even documentation on which of the many workarounds for this is the "official" one. That would be one thing if this it were some esoteric and exotic corner case. That's not what it is though. This is very basic, widely-used functionality (every single Java project I've ever worked on has used some sort of provided scope).

As a result, users trying to migrate from Maven by reading the official documentation scratch their heads because they can't find a way to do something that is both very simple and very important. When they turn to Google searches they get more confused because they get back many conflicting workarounds just from the Gradle forums, not all of which work the same, or at all.

In the end, EVERYONE loses because they end up with yucky, boilerplate code in all of their buildfiles.

EDIT: I notice that this is the number one issue in terms of votes. Can this get some love?

Hi important issues were fixed. Hopefully this will avoid some boilerplate code in your build files.

Thanks for the info, Brian Clozel.

It's still very annoying that this isn't working out of the box. This is one of the last remaining pain points of Gradle... alongside GRADLE-2579 and GRADLE-1276. And Ryon Day is right: it's quite hard to find a proper workaround.

Agreed. We've implemented our own provided configuration in our custom distro. The only issue is it gets confusing when building web apps, since we now have provided alongside providedCompile & providedRuntime.

One more upvote here.

Coming up with a provided scope (which right now is a workaround) and combining it with the 'war' and 'eclipse-wtp' plugins, just to get WARs and Eclipse JST deployments whose jar library classpath will be wildly different (unless we do backflips on the buildscript like this: http://forums.gradle.org/gradle/topics/configurations_provided_with_eclipse_wtp_plugin) isn't a reliable approach to developing Java web applications.

Now don't get me wrong. This is absolutely waaay better than Maven, but I still feel the pain of unwanted jars crawling up into my deployments.

Thanks!

Upvoting too. Some maven builds are simply impossible to migrate to Gradle without this!

Such a basic functionality missing - makes me wonder why I even tried migrating.

@IanDarwin Well, because despite this flaw Gradle is still a hundred times better than what you are currently using. Especially as you can easily add this functionality manually or via plugin easily as was noted earlier.

@BjörnKautler, where can I find the plugin you speak of? I've tried implementing the provided configuration myself, but unwanted jars keep creeping into my war file.
(*Chris*)

@ChrisPratt, Not perfect, I would rather it be natively supported by gradle, but here it is: https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin

I think the newly open-sourced nebula gradle plugins from netflix also provide a provided configuration, but never used either of the two

https://github.com/nebula-plugins/nebula-extra-configurations-plugin ?

yes

Just had to migrate to Gradle to work on android projects. This missing feature is my first big disappointment.
Android plugin fixes this, but if I want my Lombok DTOs to be shared with the server part ? Yes, there are workarounds but it's a pity there's no built-in "provided" scope.

@Pierre, use https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin for other projects, works well.

@Pierre & @Jayson, just a note. I had used both the spring plugin and the nebula plugin and I had found that the nebula plugin is a little "friendlier" . Nevertheless, the provided scope should have been natively supportted by gradle!

@Yaneeve, probably because it doesn't have the support for IDE's to pick up provided/optional. propdeps has intellij and eclipse support which is critical for me.

To play devil's advocate for a moment, is it possibly better to limit the native scopes (I.e. not support provided, optional natively) due to the ambiguity in how people expect/want the scope to behave? I know with maven there has been much confusion over how it works.

No. If there is a "provided" feature, then at least one has a fighting chance to solve problems that the lack of it creates. And, worse, there is a normal compilation provided scope but not a test compilation provided scope. I am simply after consistency so that Dex does for test builds what it does for product builds — not clutter the apk with class files that should not be there.

I am evaluating Gradle for usage as build system for JavaEE development with OSGi frontend. Unfortunately, the dependency scope provided is crucial for such projects, because a lot of dependencies are provided by the containers and are only needed during compile time. All the arguments for a provided scope are mentioned above and the vote counter is up to 207 (with me). What will happen to this issue? If it is not going to be implemented, is there a reasonable explanation?

I agree also on the the comments above, that an 'optional' scope is not needed and is in Maven builds a 'bad smell'.

I would like to back up @Rick-Rainer Ludwig by saying that not only is it an issue with JEE + OSGI, we encounter likewise issues in the bigdata domain especially within the hadoop ecosystem. We use the nebula plugin, but it would have been better had it been supported out-of-the-box

I can't find anything about Gradle's plan or strategy how to solve this "provided" problem. I tried some answers, but many of them didn't work anymore (shooting on a moving target) or just proved a bit more complicated than a single word "provided" we are used to in Maven builds. I'd like to move to Gradle, but even such a silly thing like "provided" is nearly showstopper for me. Reportedly it makes only sense in WAR, but that's far from truth. Virtually any project I worked on used this dependency scope - probably because they were using some managed environment that provided the dependency. We use it often for JARs, because we don't want to put all the classes into WEB-INF/classes every time and we rely on the fact that provided does not drag these dependencies into WEB-INF/lib.

Provided (or providedCompile, however it would be named) out of the box would be definitely more than welcome addition. It is not just cherry on some icecream. Is there anywhere some summary why modelling this takes so long? While I had problems with many Maven's things, "provided" worked absolutely smooth and never surprised me as a concept.

Another use case... It's nice to add the findbugs annotation jar to providedCompile scope. These annotations are class level, and therefore ignored by the JVM. If the provided scope were added to Gradle, then there would be a standard way to suppress spurious findbugs warnings without polluting production code with test tool jars.

So... I was looking into Gradle to replace Maven in some projects I'm working on, both personal and for my job.

At least one of these projects is a multi-project setup that has data classes in their own project... so imagine my surprise when I found out that I couldn't just mark the javaee and/or servlet-api libraries as providedCompile since you can only do that if you're using the war plugin.

I was rather hoping to not have to use a workaround, but it's either that or stick with Maven...

...and I don't want to troll but Maven is upping its game also: http://www.alexecollins.com/polyglot-maven-first-steps/

As the person who actually first reported this, I obviously see the benefit of a provided configuration. But I think everyone who complains about how this forces them back to Maven utterly misses the point and power of Gradle especially compared to Maven. Configurations in Gradle are meant to be expanded (add new ones). I do it all the time. Maven forces you into a small subset of predefined and non-expandable configurations (scopes). Gradle is inherently not limiting in this manner. Again, I initially reported the issue. I completely agree that there is enough of a well-known semantic that provided should in fact be a standard Configuration provided by the Java plugin. However, it is completely absurd to go back to Maven because of this. Personally I think too many Java developers (sadly) just do not understand ClassLoaders enough to understand the purpose and power of Configurations.

As for polygot-maven, as I said 5 years ago[1] (yep that's right, that feature has been in planning/development for over 5 years at least, not 2). It's just window dressing man; lipstick on a pig. The same major underlying limitations still exist. You can't wish that away with a new shiny way to configure it.

Gradle devs... Its obviously hard to tell because y'all decided to limit access to Jira, but I'd have to believe this is one of the all-time top vote getters for Gradle. I'd highly suggest you either added this support or reject this issue ("get busy living or get busy dying, as my friend Andy would say"). Leaving this open, not responding and just letting it drag out is, imo, not good marketing.

[1] https://developer.jboss.org/wiki/GradleWhy

Hi Steve,
I don't want to start a religious war (I'm already trolling too much) but for me the greatest advantage of Gradle over Maven was, stupidly enough, that one could in-line groovy code in Gradle's build files. I'm just guessing that that and the concise syntax of gradle files was what most beginners saw as advantages in Gradle.
With Maven's polyglot feature finally coming of age (they don't move too fast either, do they?) and more importantly the core extensions feature (http://www.infoq.com/news/2015/03/maven-polyglot) I've found my itch scratched.
In Maven's rigidity I've always found strength instead of weakness. It always takes me ages to debug and understand a broken heavily-customized Gradle build but I always know where to search with Maven builds. There never are "standard ways" of doing stuff in Gradle.

Leaving the grose maven fan-boy trolling apart, I think all the voters/watchers of this issue totally agree with you: "get busy living or get busy dying" gradle devs.

Yep, I know you are trolling. You were even in the first post It's like the girl you meet that says "Hi, I hate drama..." and then you immediately know she is full of drama...

Unfortunately, that's all the drama this issue is going to get . I get mail notifications about it each year, and each year I say: "Damn, they still haven't even decided what to do with this issue yet".

Very surprised this doesn't exist by default. I guess I'll use the nebula / provided-base plugin for now...

I just copied the 'test.compileClasspath += configurations.provided' snippet the 12th time, that's about 20% of all gradle based projects. Maybe this stems from a complete misunderstanding of dependencies on the developer side, but this is nothing that i'm in control of.

Come on, folks, kick it.

In addition, i just tried the 'Buildship' Gradle <-> Eclipse plugin, as official as one can get: made by Gradle Inc., part of Eclipse core. Dependencies in 'provided' scope are just missing and show up as unresolvable. There's a possible workaround (http://blog.codeaholics.org/2012/emulating-mavens-provided-scope-in-gradle/), but that includes applying the 'eclipse' plugin, something that i do not feel comfortable with because developer will start generating .classpath and .project files and curse me out because Eclipse and Gradle based builds are out of sync.

Almost three years ago now I added my thoughts on this issue.

I've changed companies twice since then. Provided-dependency support is an issue in each place, whether the issue is a in some form of "container" or wrapping library (Tomcat, Jetty, Hadoop/Spark, etc) or simply writing to a spec (servlet-api). In each place someone has had to either add a third-party plugin to support provided/providedCompile, or write it afresh. Each implementation is just enough inconsistent with the others that the result is... in polite company, deplorable.

Is there at least any insight to share on what difficulties lie in implementing a provided / providedCompile scope, in the Gradle 2.x world? At worst from my vantage point, the WAR plugin needs to play nicely in the case where some other plugin has already added provided / providedCompile.

Has there been any more information or discussion, as promised in the discussion at https://github.com/gradle/gradle/pull/109?

This isn't something that we'll incorporate into the Java plugin. The “provided” scope is a broken concept that we don't want to introduce at the base level of Gradle. What might be possible though is to move this into a kind of maven compatibility plugin that people who are used to it and its quirks can opt into.

I'll raise this idea with the team and post back.

and

We will include support for this in some way, that's not in question. What needs to be decided is how that will work.

and

I think for this to get in, there'd need to be a renewed round of discussion on the dev list.

provided scope dependencies are nothing extraordinary or special. They are everywhere in JEE development.
Every ejb project (that is a jar) needs the jee api jars to compile but should never declare them as compile scoped, as they do not get packaged in a war or ear including them.

What i don't get is that the votes for this tickets are going through the roof (currently 234 votes, while 2nd place has 56 votes so far) and we don't even see a discussion going on!

#ProvidedGate continues to rock the Gradle world.

Almost 18 months since I last commented, a new Major version (2.0) and several minor versions (we're up to 2.7 now as of a few days ago) have been released and the most popular issue on the Gradle issue tracker has yet to get the slightest touch of love from the devs.

Just last week I helped debug an issue where not one, but two different Java servlet-api jars were being included in our distribution package.

Come on guys.

EDIT: As a side bit of hilarity, a change in Gradle 2.0 actually broke the dev-team recommended workaround for this, causing further confusion around this subject. https://discuss.gradle.org/t/provided-dependency-is-not-added-to-compile-classpath/2539

Fun fact:
I actually have a birthday reminder for this bug.

I have spent about 10 hours trying to get a decent work around. Granted I'm fairly new to gradle but this is causing me to stumble a lot.

Could any dev, please, let us know why there is no progress on 'provided' scope for JavaPlugin, since it seems so straightforward to include it?

Excuse me but argumentation that 'provided' is a broken concept is really unconvincing. For example, there are such wide-adopted Java projects like Project Lombok on which there is no runtime dependency and it makes absolutely no sense in declaring it as a 'compile' dependency.

And what about some 'servlet libraries' (utility libraries for servlets) - they are not WARs (they are libraries so they are simply JARs) and they need a 'provided' dependency on servlet-api. In such scenario, when these 'servlet libraries' are included in a WAR project, there might even be a conflict between now-emulated 'provided' and WarPlugin's 'providedCompile'.

To conclude, would it not be easier to simply move 'providedCompile' and 'providedRuntime' from WarPlugin to JavaPlugin and be done with it?

Thank you in advance

Support all scopes (including provided) is now a reasonable feature list bullet point for build tools.

Almost 6 years open issue and still nothing.

This missing feature is annoying if using Intellij IDEA, since I always need to manually set dependencies to "provided" in IDEA when deploying to an artifact. For a war build, this isn't an issue that much, is it has providedCompile, but I think we need a common "provided" dependency scope with works ootb (and therefore with IDEA).

Reading through the comments, one problem appears to me to be the conflation of two separate requirements:

1. Libraries which are required at compile time and at runtime, but are expected to be supplied by the server container (servlet-api etc.).
2. Libraries which are required at compile time but not at runtime (Project Lombok, Apache Velocity etc.).

The concept of "provided" as I understand it only really applies to (1), and whenever I see this used for (2) it seems to be because it happens to produce the desired result, not because it was designed for that usage.

So is it worth splitting (2) out into a separate issue, and adding "compileOnly" and "testCompileOnly" configurations to the standard Java plugin? I know it is simple to add this myself, but there is a knock on effect to IDE plugins and other external tools.

If this were added, people may decide to use the "compileOnly" configuration for "provided" libraries, for the exact same reason as above: although not designed for that purpose it may well produce the desired result. Whilst I can see that may happen, I don't think that potential usage should affect the viability of the "compileOnly" option. The difference is that "compileOnly" stands on its own merits as a fairly straightforward, self-contained concept, with easily understood existing use cases (Lombok annotations, Velocity templates etc.), and should be evaluated as such.

Also, one of the issues I see discussed with "provided" is it is not about the jar file itself, but about how it is used. Logically, this information should be in the packaging stage, which is why I imagine it ended up in the war plugin. Practically however, for most quoted use-cases (servlet-api etc.), every container supplies these so it is easier to add the information it to the compilation stage. Anyway, that's a separate discussion... the point I'm trying to make here is that a "compileOnly" scope does not have this characteristic - it is completely self-contained to the object being built.

So just seeing if anyone thinks there is any merit in splitting the "compileOnly" concept out into its own issue?

It is really a shame that the Gradle team have let this grow to such an extreme. 249 votes!? This really ought to have been nipped in the bud, but now it has grown to an ugly mess.

FWIW I reached out to the development team and they agreed to discuss and respond in the next few days.

Or not...

Just use https://github.com/nebula-plugins/gradle-extra-configurations-plugin and be happy like the rest of us.

I hereby officially declare this issue an Epic Facepalm™. Kind regards.

If there were like buttons in JIRA we'd be liking each other's comments. Just a BTW.

@Andre Kelpe
The problem is not that there is no solution. The problem is, that there are so many and all of them differ.

I've seen a plugin from netflix, spring, nebula a manual exclusion of provided jars in the final ear/war packaging and manual implementations. Sometimes the new configurations are marked as not transitive (i don't know why) some mark them as transitive... and so on.

When i came here it was because I wanted to give gradle a try if it can replace maven in my current projects. But all the obstacles that i found in the first days (for nearly every one a open jira ticket exists) and the way those questions are handeled don't give me a good feeling. It's not like i am expecting a solution within 4 days, but in those 4 days this Issue will "celebrate" its 6th birthday!

If provided so so evil than why is there no official FAQ that tells everyone how it's meant to be?
EJB jars or EARs will not disappear just from ignoring the question!

@Andre Kelpe
The problem with any self-written or external plugin is that it is not standard, so other plugins (IDE plugins etc.) will not use it, and so there's still manual work to be done. The only way other plugins will include this is if it is part of the core product.

@Daniel G
"The problem is, that there are so many and all of them differ"... again, I'd say that is because they are trying to solve two separate problems (compileOnly and provided) in the same plugin, and depending on which way you lean there are different solutions.

So I would suggest a "compileOnly" configuration, which incidentally is exactly what the original text of this bug report asked for: "dependencies which are needed for compilation ... should not show up in runtime configuration". If Steve had not included the word "provided" in the bug title this may have been a much shorter discussion

Something as simple as:

  configurations {
    compileOnly
  }
  sourceSets {
    main {
      compileClasspath += configurations.compileOnly
    }
  }

And probably a corresponding testCompileOnly, although I'm sure there's some subtleties I've missed.

Then address "provided" as its own, separate issue.

@Barney Barumba I am interested in this issue as specified in the subject and the description, which is "provided" ,as needed by most application server and Hadoop users, your use case #1. I am guessing this is what most voters are interested in as well.

You are welcome to create a new issue for compileOnly but let's not change the definition of this ticket.

@Sasha Ovsankin That is actually what I suggested a couple of comments ago: "So just seeing if anyone thinks there is any merit in splitting the "compileOnly" concept out into its own issue?". I don't care which is which, I'm just trying to make the point that I think there are two separate issues here, and conflating them is just adding to the confusion.

However, I'm not sure I see any point in raising any new issues in this area until the devs come back on this one... which I'm sure they soon will!

♪♫♩
Happy Birthday to You
Happy Birthday to You
Happy Birthday Dear GRADLE-784
Happy Birthday to You.
♬♪

We are intensively discussing this within Gradle team and will come back with some response soon.

It now appears that the official recommendation of the Gradle team is to use third-party plugins: http://gradle.org/migrating-a-maven-build-to-gradle/

@Ryon Day Meh. While I wrote my own plugin for the provided dependency and an additional, it was problematic with the order of work and broke from some builds to others due to the nature of the build files. I ended up just throwing the provided configuration in each build file by hand.

@Daniel It's pretty silly that the 'provided' configuration is important enough to specifically mention in a migration guide, but not important enough to merit any actual attention from the development team.

It's pretty silly that the 'provided' configuration is important enough to specifically mention in a migration guide, but not important enough to merit any actual attention from the development team.

That means it's a religious issue with the Gradle devs.

Gradle team, If you really think that provided/optional are harmful, shouldn't you write about why they are harmful and how to avoid provided/optional instead of introducing 3rd party plugins for them?
When you are writing about 3rd party plugins for provided/optional, Doesn't that mean you admit provided/optional unavoidable?

@KwonNam Son - How are they harmful?

@Jordan

I remember when I was first searching for help on this issue, among the tons of responses I found on Google was one from a Gradle developer who said something about a 'provided' configuration being a part of this complete breakfast of some new dependency management system they were designing. Funnily enough, a search for the exact verbiage used (I cannot remember it and alas, can no longer find the post in question; perhaps someone else can have more luck) yielded no results besides the post itself. Judging by six years of no substantive responses, I think you're right about this being a religious or ideological issue where they don't want to give a maven-like 'provided' configuration but at the same time there is a lack of political will to finish whatever their intended system was in the first place.

@Daniel Merwin - I don't think they are harmful, I think the gradle team think provided/optional are harmful, so they don't add provided/optional to gradle.

Buddies, I feel that over the past six years we've all grown so close!

Since it's almost the new year I decided to celebrate our time here by putting a little scrapbook together with this past year's activity around this issue!

It appears the last time this was brought up on the dev list was here:

we are finally have started work on the foundation we need to solve this the way we want to solve it. With hindsight we should have provided a standardized provided configuration as a workaround for the time (i.e. years) being Now we just do it properly.

Here's the discussion that Issue progenitor and thread hero Steve Ebersole started recently. WARNING: Sausage making therein along with hints about "The New Software Model".

So there you have it folks! At some point, we will have an all-singing, all-dancing system.

Bonus: for the sake of humor, I want to call attention to the surprising amount of e-ink that's been spilled in Gradle's own codebase around provided dependencies.

Happy new year everyone, shall we meet back here next year? I hope to hear about many promotions/transitions/new kids next December!

Work on this issue has begun. The design document covering the "compile only dependencies" use case can be found here.

Looks good.

I'm just wondering about this part:

Both 'maven' and 'maven-publish' plugins ignore 'compileOnly' dependencies

Why not map it to provided instead? While not very helpful for tools, it still gives some info about the version of the provided dependency to a human.

Maven publication will likely be addressed in a subsequent story since it's not strictly required to satisfy this use case.

The document, unless I missed something, doesn't talk about the relationship between the testCompile and testRuntime configurations, and this new compileOnly configuration.

I would expect to have testCompile additionally extend from compileOnly, so that test source code can use classes, at compile-time and at runtime, that are provided by the system in production.

I'd be reassured if that was made clear in the document

This is addressed in the document.

When using 'java' plugin, 'main' sourceset 'compileOnly' dependencies are not available on the test compile classpath

Tests in this case are considered a consumer, so these dependencies are non-transitive. If 'compileOnly' dependencies leak through your code's API then you'll need to additionally add them as test dependencies. If they require an implementation at runtime then you'll need to add that to 'testRuntime'.

I missed that part. This has pros, but also serious cons.

Pros:

• if you don't want your tests to depend on compileOnly dependencies, that's the default. Adding compileOnly dependencies to testCompile or testRuntime is easier than removing them.

Cons:

• provided dependencies in IntelliJ are in the test compile classpath. Tests that use compileOnly dependencies will thus compile/run in IntelliJ, but not in gradle, even though the IntelliJ project has been generated from gradle
• not exported dependencies in Eclipse are in the test compile classpath. Tests that use compileOnly dependencies will thus compile/run in Eclipse, but not in gradle, even though the IntelliJ project has been generated from gradle
• In Maven, provided dependencies are in the test classpath. I understand that the goal is not to do exactly what Maven does, but still, this is a notable difference that makes the switch to gradle more painful
• AFAIK, the war providedCompile dependencies are in the test classpath, so compileOnly and providedCompile are not equivalent, making it more confusing
• For the two main usecases I see for this configuration (dependencies provided by a container, and annotations only used by a build-time analysis tool like FindBugs), having the compileOnly dependencies in the test classpath would be necessary, or wouldn't hurt.

This is food for thought. I'm not saying I completely disagree with the design. But various use-cases describing why compileOnly is necessary and why it's better not to make testCompile extend it would be welcome.

These are valid points. The compile only use case is just one of many in reality. Future stories will more appropriately address this. Right now we see compile only dependencies as a strict subset of the multitude of use cases that folks leverage "provided" for.

For all intents and purposes this is because we consider tests to be a consumer of the production code. That means it's interaction in terms of dependencies should be the same as the runtime environment. If I am publishing a module that expects a dependency to be provided by the runtime environment then the test runtime environment should also be required to provide this explicitly. In many cases the "implementation" will simply be the API we compile against plus mocks. However, there's no reason your tests couldn't run against a different implementation.

The IDE integration issue is not a new one. Mapping 'compileOnly' to 'provided' is simply an approximation. Eclipse is even worse in this regard as it doesn't even have a separate testing or compile/runtime classpaths.

It's worth noting that having 'testCompileOnly' inherit 'compileOnly' would also not solve the IntelliJ case since there is no such thing as 'testProvided'. That means we would have to map these to 'test' meaning these dependencies would be on the runtime classpath, which is incorrect. We already suffer from this problem today since 'testCompile' and 'testRuntime' both map to 'test' which is essentially both the test compile and runtime classpath.

Note, comments about Intellij behaviour might be outdated given UPCOMING Intellij 16 aligns more closely with Gradle, see more in release announcement for Intellij 16: http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-starts-the-faster-release-cycle/ ... although it talks about sourceSets, not sure if other changes were/are coming.

Thanks, Jayson, that is a good point. IntelliJ 16 models each source set as module. That said, I'm sure there's still some notion of test vs production code. It would be nice if this would now allow the separation of compile vs runtime dependencies for the 'test' source set. I'll make a note to experiment with this.

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!

Still voting for this issue - after all these years!

I'd consider this one fixed by compileOnly.

compileOnly fixes the Lombok szenario, but not for container libraries (Servlet, EJB, CDI and stuff).

Hm. What isn't fixed in that scenario? I had no problems writing libs depending on (but not including) e.g. servlet api.
I previously used spring propdep but switched to "native" compileOnly instead.

LOL! 7 years! I'm at least 3 languages and 5 build systems away from this bug now.

TBH I had missed compileOnly in any releases so I have not played with it. And to be even more honest, 7 years later and all the shit I had to add to my builds to support this, its actually more of a hassle to rip that all out and try compileOnly.

Assuming compileOnly operates as out-lined in how I thought provided should work, it should also work for "container libraries" (assuming plugins pick that up and do not add them to WARs, EARs, etc).

@Joern Huxhorn
compileOnly gives us the dependency only during compilation. To be able to test these classes you'll need to add the same dependency to testCompile / testRuntime (maybe it's even useful in runtime see https://github.com/spring-projects/gradle-plugins/issues/45) configuration too, that's neither convenient nor does is follow the principals of DRY.
I simply don't understand the heavy resistance against the providedCompile scope for the jar plugin, while it's a first class concept for the war plugin.
At least for me as jee developer this configuration is the foundation of 90% of all projects. I have given up getting the full jee support as provided by maven, but this one ... well maybe we can tell our children one day about it.

I wonder how many gradle projects actually add propdeps or smth. alike to their basic configuration... at least i've had a good laugh for the birthday reminder from Joern Huxhorn

I am considering this issue fixed with the introduction of the compileOnly configuration in Gradle 2.12. It covers the original use case described in the issue.

We recognize that are more aspects in the realm of Maven `provided` that have not been implemented yet. Any work in this area will be fleshed out in this design specification. Additionally, we started to gather related issues on GitHub mentioned in the discussion of this JIRA card e.g.

• Differences between compileOnly and providedCompile: https://github.com/gradle/gradle/issues/1171
• optional dependencies: https://github.com/gradle/gradle/issues/867
• API/implementation dependency separation: https://github.com/gradle/gradle/issues/1118

Please continue the discussion on the relevant GitHub issues or create a new GitHub issue if you think your use case is not covered yet.