Maven
  1. Maven
  2. MNG-2205

"provided" scope dependencies must be transitive

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.x / Backlog
    • Component/s: Dependencies
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      A provided scope dependency can also be thought of as "compile-only".

      Project A requires Sybase JConnect on the runtime classpath. Project A declares a "provided" dependency on Sybase JConnect.
      Project B depends upon Project A. Project B declares a "compile" dependency on Project A.
      Project C depends upon Project B. Project C declares a "compile" dependency on Project B.

      C
      | - compile dependency
      B
      | - compile dependency
      A
      | - provided dependency
      Sybase JConnect
      

      So, does Project C transitively depend on Sybase JConnect. Yes, of course! The "provided" dependency needs to be transitive.

      Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere on the runtime classpath in order for the application to function. It's valid for Project C to assume that Sybase JConnect is available and use JDBC all over the Project C code. Project C is safe to do this because it can happily deduce that Sybase JConnect will be there in the runtime environment because Project A NEEDS IT.

      I've got Use Cases all over my aggregated build which make it absolutely critical and common sense that provided scope dependencies are transitive. For the (very rare) odd case where you don't want to inherit provided dependencies, you can <exclude/> them.

        Issue Links

          Activity

          Hide
          Michael Osipov added a comment -

          As a side note: if you introduce model version 5.0.0, we could easily fix the provided scope and leave it in 4.0.0 as-is.

          Show
          Michael Osipov added a comment - As a side note: if you introduce model version 5.0.0, we could easily fix the provided scope and leave it in 4.0.0 as-is.
          Hide
          Jason van Zyl added a comment -

          I still think this would be confusing to have one behaviour with the 4.0.0 version of the POM and another behaviour with the 5.0.0 version of the model. I honestly think this would be confusing and after several years with this behaviour making a new scope name for the new behaviour is the way to go.

          Show
          Jason van Zyl added a comment - I still think this would be confusing to have one behaviour with the 4.0.0 version of the POM and another behaviour with the 5.0.0 version of the model. I honestly think this would be confusing and after several years with this behaviour making a new scope name for the new behaviour is the way to go.
          Hide
          Tibor Digana added a comment -

          I agree with Jason that the model version should not change.
          I agree with other commiters saying that XML schema should not be changed.
          Therefore a new scope should be introduced and we can call it something like "nonrunnable".
          Thus the behavior of scope "provided" should not change in spec.

          Show
          Tibor Digana added a comment - I agree with Jason that the model version should not change. I agree with other commiters saying that XML schema should not be changed. Therefore a new scope should be introduced and we can call it something like "nonrunnable". Thus the behavior of scope "provided" should not change in spec.
          Hide
          Paul Benedict added a comment -

          If this conversation is really about controlling the transitive nature of a dependency, I think we should introduce a <transitive> boolean tag. That won't need a version update since it's a new tag (no one has used it before). Then instead of inventing new scopes, we can just let programmers determine it for themselves based on their own needs.

          Show
          Paul Benedict added a comment - If this conversation is really about controlling the transitive nature of a dependency, I think we should introduce a <transitive> boolean tag. That won't need a version update since it's a new tag (no one has used it before). Then instead of inventing new scopes, we can just let programmers determine it for themselves based on their own needs.
          Hide
          Tibor Digana added a comment -

          @Paul
          We shouldn't introduce a new XML element like <transitive/>.
          The worst and still possible we can do is to introduce new scope.

          Show
          Tibor Digana added a comment - @Paul We shouldn't introduce a new XML element like <transitive/>. The worst and still possible we can do is to introduce new scope.

            People

            • Assignee:
              Unassigned
              Reporter:
              David Boden
            • Votes:
              61 Vote for this issue
              Watchers:
              67 Start watching this issue

              Dates

              • Created:
                Updated: