Maven Ear Plugin
  1. Maven Ear Plugin
  2. MEAR-143

Plugin does not respect transitive dependency scopes properly

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 2.6
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      1

      Description

      The Introduction to the Dependency Mechanism page has a handy table for deciding what to do with transitive dependencies and various scopes. The Maven ear plugin does not honor it in all cases.

      Suppose I have a .jar file. Its name is b.jar. It declares a runtime dependency on a.jar.

      Suppose now I have an .ear project. It declares a compile scope dependency on b.jar.

      By the rules of the chart, a.jar should end up being a runtime dependency (transitively) of the .ear, and should be included in the lib directory. It is not.

        Activity

        Hide
        Jörg Schaible added a comment -

        This works for us since years and I am sure we're not alone. So, without providing a small project that exhibit this behavior, this issue will probably simply closed with "cannot reproduce".

        Show
        Jörg Schaible added a comment - This works for us since years and I am sure we're not alone. So, without providing a small project that exhibit this behavior, this issue will probably simply closed with "cannot reproduce".
        Hide
        Laird Nelson added a comment -

        Yes; interestingly the simple test case I'm putting together does not manifest this bug. There must be another wrinkle to it as this is demonstrable in our main product. I will (hopefully) attach my test case shortly or close the bug and chalk it up to magic. I am thinking that dependency management plays a part here.

        Show
        Laird Nelson added a comment - Yes; interestingly the simple test case I'm putting together does not manifest this bug. There must be another wrinkle to it as this is demonstrable in our main product. I will (hopefully) attach my test case shortly or close the bug and chalk it up to magic. I am thinking that dependency management plays a part here.
        Hide
        Laird Nelson added a comment -

        Ha, got a test case that reproduces it; will attach it in a moment. The problem is with dependency management and scope overriding.

        Show
        Laird Nelson added a comment - Ha, got a test case that reproduces it; will attach it in a moment. The problem is with dependency management and scope overriding.
        Hide
        Laird Nelson added a comment -

        A test case demonstrating the problem, or demonstrating my misunderstanding (one or the other).

        Unzip and run mvn clean install and then look at the resulting .ear project (and study the pom.xml files).

        Note that the .ear project does not contain mear-143-leaf.jar. It is my understanding that it should.

        When dependency management of mear-143-leaf.jar is eliminated, this works as expected. Is this a bug or a misunderstanding on my part about how dependency management works?

        Show
        Laird Nelson added a comment - A test case demonstrating the problem, or demonstrating my misunderstanding (one or the other). Unzip and run mvn clean install and then look at the resulting .ear project (and study the pom.xml files). Note that the .ear project does not contain mear-143-leaf.jar. It is my understanding that it should. When dependency management of mear-143-leaf.jar is eliminated, this works as expected. Is this a bug or a misunderstanding on my part about how dependency management works?
        Hide
        Jörg Schaible added a comment -

        This is exactly how dependencyManagement works!
        http://maven.apache.org/pom.html#Dependency_Management

        Show
        Jörg Schaible added a comment - This is exactly how dependencyManagement works! http://maven.apache.org/pom.html#Dependency_Management
        Hide
        Laird Nelson added a comment - - edited

        I assume you're trying to point me to the text that reads:

        In addition, the version and scope of artifacts which are incorporated from transitive dependencies may also be controlled by specifying them in a dependency management section.

        But I was under the impression that if I "overrode" the scope the overridden scope would be honored? Note that the document to which you referred me does not address scope overriding.

        Note as well that the <dependencyManagement> section initially defines mear-143-leaf's scope to be test. But the actual <dependencies> information in mear-143-middle overrides the scope to be runtime. Shouldn't the scope of the ear file's transitive mear-143-leaf dependency therefore be runtime? No?

        I based my theory off of http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management, specifically the section that begins "A second and very important use...". Note that in project B in that section project B overrides the scope of c to be runtime.

        Show
        Laird Nelson added a comment - - edited I assume you're trying to point me to the text that reads: In addition, the version and scope of artifacts which are incorporated from transitive dependencies may also be controlled by specifying them in a dependency management section. But I was under the impression that if I "overrode" the scope the overridden scope would be honored? Note that the document to which you referred me does not address scope overriding. Note as well that the <dependencyManagement> section initially defines mear-143-leaf 's scope to be test . But the actual <dependencies> information in mear-143-middle overrides the scope to be runtime . Shouldn't the scope of the ear file's transitive mear-143-leaf dependency therefore be runtime ? No? I based my theory off of http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management , specifically the section that begins "A second and very important use...". Note that in project B in that section project B overrides the scope of c to be runtime .
        Hide
        Laird Nelson added a comment -

        This StackOverflow answer helped educate me on the fact that dependency management trumps dependency mediation even for scope, which I had not realized.

        Show
        Laird Nelson added a comment - This StackOverflow answer helped educate me on the fact that dependency management trumps dependency mediation even for scope, which I had not realized.

          People

          • Assignee:
            Unassigned
            Reporter:
            Laird Nelson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: