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)

        Issue Links

          Activity

          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

            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:

                Development