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

Provide a 'provided' configuration

    Details

    • Type: Improvement
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None

      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)

        Activity

        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.

          People

          • Assignee:
            Unassigned
            Reporter:
            steve@hibernate.org Steve Ebersole
          • Votes:
            232 Vote for this issue
            Watchers:
            168 Start watching this issue

            Dates

            • Created:
              Updated:

              Development