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

            People

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

              Dates

              • Created:
                Updated:

                Development