Maven
  1. Maven
  2. MNG-4240

Direct dependencies with scope == provided will not have their transitive dependencies resolved for compiling and testing

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.2.1
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      While provided-scoped dependencies should never be passed forward from the current artifact (should not be resolved when the declaring project is itself used as a dependency), it is critical that provided scope and its full dependency sub-tree is resolved for compilation and testing.

        Activity

        Hide
        John Casey added a comment -

        this was an incorrect reading of the problem. Once I dug deeper into the case I was working on, we found the real problem

        Show
        John Casey added a comment - this was an incorrect reading of the problem. Once I dug deeper into the case I was working on, we found the real problem
        Hide
        John Casey added a comment -

        The big issue here that needs verification and/or fixing is that when a direct dependency is marked scope == provided, the transitive dependencies below that provided-scope dependency still need to be resolved for the purposes of testing.

        For example, assume I'm developing an extension for Maven and I declare a direct dependency on maven-core with scope == provided. My real interest in maven-core is DefaultMaven, to be used to spawn separate, second-level builds (I know, there are many many other reasons this might not work, but just go with it). In this case, maven-core has a dependency on maven-project which is critical.

        DefaultMaven depends on DefaultMavenProjectBuilder to read POMs and return MavenProject instances. If I create unit tests that attempt to execute my extension class, those unit tests will require the maven-project artifact (along with many others) to be present before a valid runtime environment for the unit test can be created. If maven-project is excluded from dependency resolution, the unit test will fail with a NoClassDefFoundError.

        The place where a problem could arise in all of this is when/if my direct dependency with provided scope itself declares a dependency with scope == provided. Surefire most likely cannot create a valid runtime environment in this case unless it traverses every provided- and non-provided-scope dependency. Since the code makes the assumption that those provided-scope dependencies will be present at runtime, the calculation for creating that runtime environment for the purposes of unit testing may become very difficult.

        Show
        John Casey added a comment - The big issue here that needs verification and/or fixing is that when a direct dependency is marked scope == provided, the transitive dependencies below that provided-scope dependency still need to be resolved for the purposes of testing. For example, assume I'm developing an extension for Maven and I declare a direct dependency on maven-core with scope == provided. My real interest in maven-core is DefaultMaven, to be used to spawn separate, second-level builds (I know, there are many many other reasons this might not work, but just go with it). In this case, maven-core has a dependency on maven-project which is critical. DefaultMaven depends on DefaultMavenProjectBuilder to read POMs and return MavenProject instances. If I create unit tests that attempt to execute my extension class, those unit tests will require the maven-project artifact (along with many others) to be present before a valid runtime environment for the unit test can be created. If maven-project is excluded from dependency resolution, the unit test will fail with a NoClassDefFoundError. The place where a problem could arise in all of this is when/if my direct dependency with provided scope itself declares a dependency with scope == provided. Surefire most likely cannot create a valid runtime environment in this case unless it traverses every provided- and non-provided-scope dependency. Since the code makes the assumption that those provided-scope dependencies will be present at runtime, the calculation for creating that runtime environment for the purposes of unit testing may become very difficult.

          People

          • Assignee:
            John Casey
            Reporter:
            John Casey
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: