Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-784

Provide a 'provided' configuration

    Details

    • Type: Improvement
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.12-rc-1

      Description

      The intent of 'provided' configuration is to define dependencies which are needed for compilation, but which should not be "exported" (aka should not show up in runtime configuration)

        Issue Links

          Activity

          steve@hibernate.org Steve Ebersole created issue -
          Hide
          narcomancer Uldis Karlovs-Karlovskis added a comment -

          This is specially for JavaPlugin I believe

          Show
          narcomancer Uldis Karlovs-Karlovskis added a comment - This is specially for JavaPlugin I believe
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

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

          Show
          steve@hibernate.org Steve Ebersole added a comment - Not sure why that would be the case, but ok.
          Hide
          peass Paulo Silveira added a comment -

          For now the solution is to create a new configuration:

          configurations {
          provided
          }

          and set it to be used with your compilation classpath:

          sourceSets {
          main

          { compileClasspath += configurations.provided }

          }

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

          Show
          peass Paulo Silveira added a comment - For now the solution is to create a new configuration: configurations { provided } and set it to be used with your compilation classpath: sourceSets { main { compileClasspath += configurations.provided } } this way it will not be inside your runtime deps. thanks to Steve Ebersole.
          Hide
          jaron.schut jaron schut added a comment -

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

          ~/build.gradle:

          subProjects {

          configurations

          { provided }

          sourceSets {
          main

          { compileClasspath += configurations.provided }

          }
          }

          ~/Module/build.gradle:

          dependencies {

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

          Show
          jaron.schut jaron schut added a comment - Could you please provide a more complete example how to configure the "provided" dependency scope in real life set up? ~/build.gradle: subProjects { configurations { provided } sourceSets { main { compileClasspath += configurations.provided } } } ~/Module/build.gradle: dependencies { provided 'org.axonframework:axon-core:0.6' }
          adammurdoch Adam Murdoch made changes -
          Field Original Value New Value
          Fix Version/s 1.0 [ 15740 ]
          adammurdoch Adam Murdoch made changes -
          Assignee Hans Dockter [ hans_d ]
          contegix Contegix Support made changes -
          Project Import Sat Mar 19 09:23:24 CDT 2011 [ 1300544604020 ]
          Hide
          blaine Blaine Simpson added a comment -

          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
          Show
          blaine Blaine Simpson added a comment - 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
          Hide
          cquinn Carl Quinn added a comment -

          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.

          Show
          cquinn Carl Quinn added a comment - 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.
          adammurdoch Adam Murdoch made changes -
          Fix Version/s someday [ 10053 ]
          Fix Version/s 1.0 [ 10051 ]
          daz Daz DeBoer made changes -
          Workflow jira [ 12184 ] jira with pivotal tracker [ 14393 ]
          Hide
          ansel1 Russ Egan added a comment -

          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.

          Show
          ansel1 Russ Egan added a comment - 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.
          Hide
          rodion Rodion Moiseev added a comment -

          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.

          Show
          rodion Rodion Moiseev added a comment - 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.
          adammurdoch Adam Murdoch made changes -
          Fix Version/s someday [ 10053 ]
          Hide
          cquinn Carl Quinn added a comment -

          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?

          Show
          cquinn Carl Quinn added a comment - 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?
          Hide
          cbeams Chris Beams added a comment - - edited

          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.

          Show
          cbeams Chris Beams added a comment - - edited 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

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

          Show
          steve@hibernate.org Steve Ebersole added a comment - I disagree about support for 'optional'. Even the Maven team acknowledge 'optional' as a mistake. 'optional' is used to circumvent badly isolated dependencies.
          Hide
          cbeams Chris Beams added a comment -

          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.

          Show
          cbeams Chris Beams added a comment - 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: the version of a dependency that my project builds against whether that dependency is required to be present on a client's runtime classpath 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          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.

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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.
          Hide
          cbeams Chris Beams added a comment -

          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.

          Show
          cbeams Chris Beams added a comment - 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          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!

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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!
          Hide
          cbeams Chris Beams added a comment -

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

          Show
          cbeams Chris Beams added a comment - Agreed. We shouldn't throw the provided baby out with the optional bathwater
          Hide
          randgalt Jordan Zimmerman added a comment -

          Any update on this?

          Show
          randgalt Jordan Zimmerman added a comment - Any update on this?
          Hide
          dty Danny Yates added a comment -

          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.

          Show
          dty Danny Yates added a comment - 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.
          Hide
          andrew.oberstar Andrew Oberstar added a comment - - edited

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

          eclipse.classpath.plusConfigurations += configurations.provided
          
          Show
          andrew.oberstar Andrew Oberstar added a comment - - edited Dan you should be able to get in on the eclipse classpath with this: eclipse.classpath.plusConfigurations += configurations.provided
          Hide
          dty Danny Yates added a comment -

          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.

          Show
          dty Danny Yates added a comment - 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.
          Hide
          andrew.oberstar Andrew Oberstar added a comment -

          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.

          Show
          andrew.oberstar Andrew Oberstar added a comment - 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.
          Hide
          adammurdoch Adam Murdoch added a comment -

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

          Show
          adammurdoch Adam Murdoch added a comment - @Danny, they both share the same model. If you change 'eclipse.classpath' then both plugins will see the change.
          Hide
          dty Danny Yates added a comment -

          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.

          Show
          dty Danny Yates added a comment - 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          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?

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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?
          Hide
          cquinn Carl Quinn added a comment -

          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.

          Show
          cquinn Carl Quinn added a comment - 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.
          Hide
          mauromol Mauro Molinari added a comment -

          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.

          Show
          mauromol Mauro Molinari added a comment - 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.
          Hide
          jminard Jayson Minard added a comment -

          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.

          Show
          jminard Jayson Minard added a comment - 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.
          Hide
          sgrossman Steven Grossman added a comment -

          @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
              }
          }
          
          Show
          sgrossman Steven Grossman added a comment - @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 } }
          Hide
          jminard Jayson Minard added a comment -

          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.

          Show
          jminard Jayson Minard added a comment - 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.
          Hide
          dty Danny Yates added a comment -

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

          Show
          dty Danny Yates added a comment - I've written up how to make this work (plus how to get it integrated with the Eclipse STS Gradle plugin) on my blog
          Hide
          sergeykad Sergey Kadaner added a comment -

          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.

          Show
          sergeykad Sergey Kadaner added a comment - 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.
          Hide
          dstine Dan Stine added a comment -
          Show
          dstine Dan Stine added a comment - Some new discussion here: https://github.com/gradle/gradle/pull/109
          Hide
          carymapa Matt Cary added a comment -

          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.

          Show
          carymapa Matt Cary added a comment - 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.
          Hide
          jminard Jayson Minard added a comment -

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

          Show
          jminard Jayson Minard added a comment - Knowing Carl, he is likely building class files using eMacs macros too. Yet, agreeing with Matt on the naming across plugins...
          ldaley Luke Daley made changes -
          Workflow jira with pivotal tracker [ 14393 ] jira with pivotal tracker (no resolved, only closed) [ 18695 ]
          ldaley Luke Daley made changes -
          Workflow jira with pivotal tracker (no resolved, only closed) [ 18695 ] Copy of jira with pivotal tracker (no closed, only resolved) [ 21294 ]
          Hide
          jptech Ryan J added a comment -

          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?

          Show
          jptech Ryan J added a comment - 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?
          Hide
          nikem Nikita Salnikov-Tarnovski added a comment -

          Is there any plans to implement this request?

          Show
          nikem Nikita Salnikov-Tarnovski added a comment - Is there any plans to implement this request?
          Hide
          pdeva Prashant Deva added a comment -

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

          Show
          pdeva Prashant Deva added a comment - +1. I am surprised this has still not been implemented.
          Hide
          ghynx Gregoire Henry added a comment -

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

          Show
          ghynx Gregoire Henry added a comment - +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)
          Hide
          elygre Eirik Lygre added a comment -

          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?

          Show
          elygre Eirik Lygre added a comment - 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?
          Hide
          SebTardif Sebastien Tardif added a comment -

          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.

          Show
          SebTardif Sebastien Tardif added a comment - 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.
          Hide
          fs111 Andre Kelpe added a comment -

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

          Show
          fs111 Andre Kelpe added a comment - @Sebastien: We moved to https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin and have no problem with it.
          Hide
          tilo.dickopp Tilo Dickopp added a comment -

          @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

          Show
          tilo.dickopp Tilo Dickopp added a comment - @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
          Hide
          jhuxhorn Joern Huxhorn added a comment -

          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.

          Show
          jhuxhorn Joern Huxhorn added a comment - 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.
          Hide
          SebTardif Sebastien Tardif added a comment -

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

          Show
          SebTardif Sebastien Tardif added a comment - 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."
          Hide
          dasAnderl dasAnderl added a comment -

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

          Show
          dasAnderl dasAnderl added a comment - please provide this scope also for non-war packaging. it would be really usefull.
          Hide
          fedotxxl Fedor Belov added a comment -

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

          Show
          fedotxxl Fedor Belov added a comment - Strange that Gradle doesn't support this yet. Pls make it work correctly with IDEA plugin
          Hide
          Raphael Raphael added a comment -

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

          Show
          Raphael Raphael added a comment - Is there any word on when this bug will be resolved closed?
          Hide
          fge Francis Galiegue added a comment - - edited

          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!

          Show
          fge Francis Galiegue added a comment - - edited 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!
          Hide
          alishafa Ali Shafai added a comment -

          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.

          Show
          alishafa Ali Shafai added a comment - 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.
          Hide
          ryon_day Ryon Day added a comment - - edited

          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?

          Show
          ryon_day Ryon Day added a comment - - edited 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?
          Hide
          bclozel Brian Clozel added a comment -

          Hi Ryon Day, Spring's propdeps-plugins has been recently updated and important issues were fixed. Hopefully this will avoid some boilerplate code in your build files.

          Show
          bclozel Brian Clozel added a comment - Hi Ryon Day , Spring's propdeps-plugins has been recently updated and important issues were fixed . Hopefully this will avoid some boilerplate code in your build files.
          Hide
          jhuxhorn Joern Huxhorn added a comment - - edited

          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.

          Show
          jhuxhorn Joern Huxhorn added a comment - - edited 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.
          Hide
          edeandrea Eric Deandrea added a comment -

          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.

          Show
          edeandrea Eric Deandrea added a comment - 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.
          Hide
          jjzazuet Jesus Zazueta added a comment -

          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!

          Show
          jjzazuet Jesus Zazueta added a comment - 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!
          Hide
          gimelit Geula Vainappel added a comment -

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

          Show
          gimelit Geula Vainappel added a comment - Upvoting too. Some maven builds are simply impossible to migrate to Gradle without this!
          Hide
          idarwin Ian Darwin added a comment -

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

          Show
          idarwin Ian Darwin added a comment - Such a basic functionality missing - makes me wonder why I even tried migrating.
          Hide
          vampire Björn Kautler added a comment -

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

          Show
          vampire Björn Kautler added a comment - @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.
          Hide
          TheChrisPratt Chris Pratt added a comment -

          @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*)

          Show
          TheChrisPratt Chris Pratt added a comment - @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*)
          Hide
          Yaneeve Yaneeve Shekel added a comment -

          @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

          Show
          Yaneeve Yaneeve Shekel added a comment - @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
          Hide
          vampire Björn Kautler added a comment -

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

          Show
          vampire Björn Kautler added a comment - I think the newly open-sourced nebula gradle plugins from netflix also provide a provided configuration, but never used either of the two
          Show
          dejan.stojadinovic Dejan Stojadinović added a comment - Björn Kautler are you referring to this one: https://github.com/nebula-plugins/nebula-extra-configurations-plugin ?
          Hide
          vampire Björn Kautler added a comment -

          yes

          Show
          vampire Björn Kautler added a comment - yes
          ldaley Luke Daley made changes -
          Comment [ The table, they're all nonjudicial minorities.
          http://www.surveyanalytics.com//userimages/sub-2/2007589/3153260/29851518/7787449-29851518-stopadd31.html
          Starting with blood 22 the season was changed to make it the nature plan back. ]
          Hide
          Pitt Pierre Mardon added a comment -

          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.

          Show
          Pitt Pierre Mardon added a comment - 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.
          Hide
          jminard Jayson Minard added a comment -
          Show
          jminard Jayson Minard added a comment - @Pierre, use https://github.com/spring-projects/gradle-plugins/tree/master/propdeps-plugin for other projects, works well.
          Hide
          Yaneeve Yaneeve Shekel added a comment -

          @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!

          Show
          Yaneeve Yaneeve Shekel added a comment - @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!
          Hide
          jminard Jayson Minard added a comment -

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

          Show
          jminard Jayson Minard added a comment - @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.
          Hide
          fortuna Ben Fortuna added a comment -

          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.

          Show
          fortuna Ben Fortuna added a comment - 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.
          Hide
          pajatopmr Paul Michael Reilly added a comment -

          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.

          Show
          pajatopmr Paul Michael Reilly added a comment - 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.
          Hide
          rick-rainer.ludwig Rick-Rainer Ludwig added a comment -

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

          Show
          rick-rainer.ludwig Rick-Rainer Ludwig added a comment - 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'.
          Hide
          Yaneeve Yaneeve Shekel added a comment -

          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

          Show
          Yaneeve Yaneeve Shekel added a comment - 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
          Hide
          virgo47 Richard Richter added a comment -

          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.

          Show
          virgo47 Richard Richter added a comment - 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.
          Hide
          Morgan Creighton Morgan Creighton added a comment - - edited

          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.

          Show
          Morgan Creighton Morgan Creighton added a comment - - edited 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.
          Hide
          powerlord Ross Bemrose added a comment - - edited

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

          Show
          powerlord Ross Bemrose added a comment - - edited 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...
          Hide
          mirceade mirceade added a comment -

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

          Show
          mirceade mirceade added a comment - ...and I don't want to troll but Maven is upping its game also: http://www.alexecollins.com/polyglot-maven-first-steps/
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          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

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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
          Hide
          mirceade mirceade added a comment - - edited

          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.

          Show
          mirceade mirceade added a comment - - edited 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

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

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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...
          Hide
          mirceade mirceade added a comment -

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

          Show
          mirceade mirceade added a comment - 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".
          Hide
          BoD Benoît 'BoD' Lubek added a comment -

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

          Show
          BoD Benoît 'BoD' Lubek added a comment - Very surprised this doesn't exist by default. I guess I'll use the nebula / provided-base plugin for now...
          Hide
          jot1109 Jochen Hinrichsen added a comment -

          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.

          Show
          jot1109 Jochen Hinrichsen added a comment - 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.
          Hide
          jot1109 Jochen Hinrichsen added a comment -

          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.

          Show
          jot1109 Jochen Hinrichsen added a comment - 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.
          Hide
          carymapa Matt Cary added a comment - - edited

          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.

          Show
          carymapa Matt Cary added a comment - - edited 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.
          Hide
          elygre Eirik Lygre added a comment -

          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.

          Show
          elygre Eirik Lygre added a comment - 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.
          Hide
          geissld Daniel G added a comment -

          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!

          Show
          geissld Daniel G added a comment - 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!
          Hide
          ryon_day Ryon Day added a comment - - edited

          #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

          Show
          ryon_day Ryon Day added a comment - - edited #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
          Hide
          jhuxhorn Joern Huxhorn added a comment -

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

          Show
          jhuxhorn Joern Huxhorn added a comment - Fun fact: I actually have a birthday reminder for this bug.
          Hide
          tshock65 Tim Shockley added a comment -

          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.

          Show
          tshock65 Tim Shockley added a comment - 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.
          Hide
          t.link Tomasz Linkowski added a comment -

          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

          Show
          t.link Tomasz Linkowski added a comment - 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
          Hide
          jhuxhorn Joern Huxhorn added a comment -

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

          Show
          jhuxhorn Joern Huxhorn added a comment - Support all scopes (including provided ) is now a reasonable feature list bullet point for build tools.
          Hide
          robertoschwald Robert Oschwald added a comment -

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

          Show
          robertoschwald Robert Oschwald added a comment - 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).
          Hide
          baarney Barney Barumba added a comment - - edited

          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?

          Show
          baarney Barney Barumba added a comment - - edited Reading through the comments, one problem appears to me to be the conflation of two separate requirements: Libraries which are required at compile time and at runtime, but are expected to be supplied by the server container (servlet-api etc.). 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?
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          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.

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

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

          Show
          steve@hibernate.org Steve Ebersole added a comment - FWIW I reached out to the development team and they agreed to discuss and respond in the next few days.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

          Or not...

          Show
          steve@hibernate.org Steve Ebersole added a comment - Or not...
          Hide
          jot1109 Jochen Hinrichsen added a comment -

          Show
          jot1109 Jochen Hinrichsen added a comment -
          Hide
          fs111 Andre Kelpe added a comment -
          Show
          fs111 Andre Kelpe added a comment - Just use https://github.com/nebula-plugins/gradle-extra-configurations-plugin and be happy like the rest of us.
          Hide
          BoD Benoît 'BoD' Lubek added a comment -

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

          Show
          BoD Benoît 'BoD' Lubek added a comment - I hereby officially declare this issue an Epic Facepalm™. Kind regards.
          Hide
          bond Ravi Teja added a comment - - edited

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

          Show
          bond Ravi Teja added a comment - - edited If there were like buttons in JIRA we'd be liking each other's comments. Just a BTW.
          Hide
          geissld Daniel G added a comment -

          @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!

          Show
          geissld Daniel G added a comment - @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!
          Hide
          baarney Barney Barumba added a comment - - edited

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

          Show
          baarney Barney Barumba added a comment - - edited @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.
          Hide
          sashao Sasha Ovsankin added a comment -

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

          Show
          sashao Sasha Ovsankin added a comment - @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.
          Hide
          baarney Barney Barumba added a comment -

          @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!

          Show
          baarney Barney Barumba added a comment - @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!
          Hide
          jhuxhorn Joern Huxhorn added a comment -

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

          Show
          jhuxhorn Joern Huxhorn added a comment - ♪♫♩ Happy Birthday to You Happy Birthday to You Happy Birthday Dear GRADLE-784 Happy Birthday to You. ♬♪
          Hide
          randgalt Jordan Zimmerman added a comment -

          Show
          randgalt Jordan Zimmerman added a comment -
          Hide
          piotr Piotr Jagielski added a comment -

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

          Show
          piotr Piotr Jagielski added a comment - We are intensively discussing this within Gradle team and will come back with some response soon.
          Hide
          ryon_day Ryon Day added a comment -

          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/

          Show
          ryon_day Ryon Day added a comment - 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/
          Hide
          daniel-m@freeuniversegames.com Daniel Merwin added a comment -

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

          Show
          daniel-m@freeuniversegames.com Daniel Merwin added a comment - @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.
          Hide
          ryon_day Ryon Day added a comment -

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

          Show
          ryon_day Ryon Day added a comment - @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.
          Hide
          randgalt Jordan Zimmerman added a comment -

          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.

          Show
          randgalt Jordan Zimmerman added a comment - 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.
          Hide
          kwon37xi KwonNam Son added a comment - - edited

          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?

          Show
          kwon37xi KwonNam Son added a comment - - edited 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?
          Hide
          daniel-m@freeuniversegames.com Daniel Merwin added a comment -

          @KwonNam Son - How are they harmful?

          Show
          daniel-m@freeuniversegames.com Daniel Merwin added a comment - @KwonNam Son - How are they harmful?
          Hide
          ryon_day Ryon Day added a comment -

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

          Show
          ryon_day Ryon Day added a comment - @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.
          Hide
          kwon37xi KwonNam Son added a comment - - edited

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

          Show
          kwon37xi KwonNam Son added a comment - - edited @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.
          Hide
          ryon_day Ryon Day added a comment -

          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!

          Show
          ryon_day Ryon Day added a comment - 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!
          mvieira Mark Vieira made changes -
          Assignee Mark Vieira [ mvieira ]
          Hide
          mvieira Mark Vieira added a comment -

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

          Show
          mvieira Mark Vieira added a comment - Work on this issue has begun. The design document covering the "compile only dependencies" use case can be found here .
          Hide
          jhuxhorn Joern Huxhorn added a comment -

          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.

          Show
          jhuxhorn Joern Huxhorn added a comment - 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.
          Hide
          mvieira Mark Vieira added a comment -

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

          Show
          mvieira Mark Vieira added a comment - Maven publication will likely be addressed in a subsequent story since it's not strictly required to satisfy this use case.
          Hide
          jnizet Jean-Baptiste Nizet added a comment -

          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

          Show
          jnizet Jean-Baptiste Nizet added a comment - 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
          Hide
          mvieira Mark Vieira added a comment -

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

          Show
          mvieira Mark Vieira added a comment - 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'.
          Hide
          jnizet Jean-Baptiste Nizet added a comment - - edited

          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.

          Show
          jnizet Jean-Baptiste Nizet added a comment - - edited 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.
          Hide
          mvieira Mark Vieira added a comment -

          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.

          Show
          mvieira Mark Vieira added a comment - 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.
          Hide
          mvieira Mark Vieira added a comment -

          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.

          Show
          mvieira Mark Vieira added a comment - 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.
          Hide
          jayson.minard Jayson Minard added a comment -

          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.

          Show
          jayson.minard Jayson Minard added a comment - 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.
          Hide
          mvieira Mark Vieira added a comment -

          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.

          Show
          mvieira Mark Vieira added a comment - 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.
          mvieira Mark Vieira made changes -
          Link This issue dependent on GRADLE-3399 [ GRADLE-3399 ]
          Hide
          bmuschko Benjamin Muschko added a comment -

          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!

          Show
          bmuschko Benjamin Muschko added a comment - 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!
          Hide
          geissld Daniel G added a comment -

          Still voting for this issue - after all these years!

          Show
          geissld Daniel G added a comment - Still voting for this issue - after all these years!
          Hide
          jhuxhorn Joern Huxhorn added a comment -

          I'd consider this one fixed by compileOnly.

          Show
          jhuxhorn Joern Huxhorn added a comment - I'd consider this one fixed by compileOnly .
          Hide
          geissld Daniel G added a comment -

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

          Show
          geissld Daniel G added a comment - compileOnly fixes the Lombok szenario, but not for container libraries (Servlet, EJB, CDI and stuff).
          Hide
          jhuxhorn Joern Huxhorn added a comment -

          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.

          Show
          jhuxhorn Joern Huxhorn added a comment - 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.
          Hide
          dty Danny Yates added a comment -

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

          Show
          dty Danny Yates added a comment - LOL! 7 years! I'm at least 3 languages and 5 build systems away from this bug now.
          Hide
          steve@hibernate.org Steve Ebersole added a comment -

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

          Show
          steve@hibernate.org Steve Ebersole added a comment - 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).
          Hide
          geissld Daniel G added a comment -

          @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

          Show
          geissld Daniel G added a comment - @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
          Hide
          bmuschko Benjamin Muschko added a comment -

          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.

          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.

          Show
          bmuschko Benjamin Muschko added a comment - 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.
          bmuschko Benjamin Muschko made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          bmuschko Benjamin Muschko made changes -
          Fix Version/s 2.12 [ 11566 ]
          eriwen Eric Wendelin made changes -
          Fix Version/s 2.12-rc-1 [ 11567 ]
          Fix Version/s 2.12 [ 11566 ]

            People

            • Assignee:
              mvieira Mark Vieira
              Reporter:
              steve@hibernate.org Steve Ebersole
            • Votes:
              262 Vote for this issue
              Watchers:
              189 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development