Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Auto Closed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: dependencies task
    • Labels:
      None

      Description

      It appears that the type filter doesn't work properly with indirect dependencies. It doesn't look like an issue with the TypeArtifactFilter itself, but somewhere deeper. However, it's related to this feature, so here it is...

      The problem manifests with transitive dependencies that are of different type, e.g. a war artefact depends on a jar library. Whatever the type in that case (jar or war), the dependency list returned by artifact:dependencies is empty.

      I've traced through it and here is some more information:

      DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. This iterates over the (dependency) node trail and applies the specified filter to each dependency in turn. If all dependencies are of the same type and the type matches the one specified in the filter, no problems. However, I've got a dependency that is a war archive and that in turn has some jar dependencies. If type is set to jar, filter fails when testing the first dependency in the trail - the war in this case and never gets to the jar. The result is that whatever the value of the type attribute, the dependency list always ends up empty for trails that contain dependencies of different types.

      1. pom.xml
        0.6 kB
        Tomislav Bodor
      2. build.xml
        2 kB
        Tomislav Bodor

        Issue Links

          Activity

          Tomislav Bodor created issue -
          Hide
          Brett Porter added a comment -

          I may be misunderstanding the problem, but if this is exclusive to WARs, it is correct beahviour. Since WARs include all of their dependencies, its dependencies themselves are not transitive. However, if the dependencies were given elsewhere they should still be included...

          Show
          Brett Porter added a comment - I may be misunderstanding the problem, but if this is exclusive to WARs, it is correct beahviour. Since WARs include all of their dependencies, its dependencies themselves are not transitive. However, if the dependencies were given elsewhere they should still be included...
          Brett Porter made changes -
          Field Original Value New Value
          Assignee Brett Porter [ brettporter ]
          Resolution Won't Fix [ 2 ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Tomislav Bodor added a comment -

          The problem manifests itself whenever you have a dependency trail in which not all dependencies are of the same type. However, I am struggling to find a non-war example since there are not that many types that are in use... But there is nothing in the code that specifically checks for wars, so the correct behaviour for wars is a coincidence. And it's only correct for fat wars (I'll come to that in a minute).

          I still think the prolem is real, though, so I'll try to explain a bit better what I was trying to do. WAR dependencies as such are indeed not transitive, except in one case: when you want to build a slim war (that doesn't include its dependencies) and then you want to include all dependencies at the ear level. Filtering dependencies by type would allow pulling in all dependencies of type war and insert corresponding <module><web> entries in the application.xml. Similarly, all jar dependencies translate to <module><java> entries.

          Also, not quite applicable at the moment as you cannot yet handle attached artefacts, but another example would be when you have an EJB client jar that has some dependencies (of type jar). As far as I understand, EJB client jars are of type 'ejb-client' in maven, not jar, so again you have a heterogeneous trail and none of those dependencies will be included.

          I would expect the type filter to work on the final transitive closure of all dependencies and give me a subset that are of the specified type. Instead, it operates on dependency trails and has a side effect: not only does it apply to the dependency at the end of a trail (the one currently being considered), but it also (as a side effect) eliminates dependencies with heterogeneous trails. This feels wrong. But perhaps not... What was the original intention of supporting the type filter?

          Thanks for looking at this.

          Show
          Tomislav Bodor added a comment - The problem manifests itself whenever you have a dependency trail in which not all dependencies are of the same type. However, I am struggling to find a non-war example since there are not that many types that are in use... But there is nothing in the code that specifically checks for wars, so the correct behaviour for wars is a coincidence. And it's only correct for fat wars (I'll come to that in a minute). I still think the prolem is real, though, so I'll try to explain a bit better what I was trying to do. WAR dependencies as such are indeed not transitive, except in one case: when you want to build a slim war (that doesn't include its dependencies) and then you want to include all dependencies at the ear level. Filtering dependencies by type would allow pulling in all dependencies of type war and insert corresponding <module><web> entries in the application.xml. Similarly, all jar dependencies translate to <module><java> entries. Also, not quite applicable at the moment as you cannot yet handle attached artefacts, but another example would be when you have an EJB client jar that has some dependencies (of type jar). As far as I understand, EJB client jars are of type 'ejb-client' in maven, not jar, so again you have a heterogeneous trail and none of those dependencies will be included. I would expect the type filter to work on the final transitive closure of all dependencies and give me a subset that are of the specified type. Instead, it operates on dependency trails and has a side effect: not only does it apply to the dependency at the end of a trail (the one currently being considered), but it also (as a side effect) eliminates dependencies with heterogeneous trails. This feels wrong. But perhaps not... What was the original intention of supporting the type filter? Thanks for looking at this.
          Hide
          Brett Porter added a comment -

          reopening for further investigation

          Show
          Brett Porter added a comment - reopening for further investigation
          Brett Porter made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Won't Fix [ 2 ]
          Tomislav Bodor made changes -
          Attachment pom.xml [ 17715 ]
          Tomislav Bodor made changes -
          Attachment build.xml [ 17716 ]
          Hide
          Tomislav Bodor added a comment -

          Attached a small example demonstrating the problem. The example is a war project for which it's impossible to get jar dependencies (even from within the project itself, not just from the outside). All trails start with the project itself (of type war) and so they are all heterogenenous, so any type filter will fail and return an empty fileset.

          Show
          Tomislav Bodor added a comment - Attached a small example demonstrating the problem. The example is a war project for which it's impossible to get jar dependencies (even from within the project itself, not just from the outside). All trails start with the project itself (of type war) and so they are all heterogenenous, so any type filter will fail and return an empty fileset.
          Brett Porter made changes -
          Assignee Brett Porter [ brettporter ]
          Vincent Massol made changes -
          Workflow Maven [ 41951 ] Maven New [ 48170 ]
          Hide
          Jeff Maxwell added a comment -

          I have possible workaround/fix

          In the DefaultArtifactCollector.collect method where the filters are applied.

          Here is filter line:
          if (node.filterTrail( filter ) )

          I get the expected behavior when I change the line to:
          if (filter.include(artifact)||node.filterTrail( filter ) )

          This workaround might cause other problems but it has gotten me passed my issue.

          Show
          Jeff Maxwell added a comment - I have possible workaround/fix In the DefaultArtifactCollector.collect method where the filters are applied. Here is filter line: if (node.filterTrail( filter ) ) I get the expected behavior when I change the line to: if (filter.include(artifact)||node.filterTrail( filter ) ) This workaround might cause other problems but it has gotten me passed my issue.
          John Casey made changes -
          Fix Version/s 2.1 [ 11704 ]
          Hide
          Tomislav Bodor added a comment -

          I have implemented an internal workaround for our project that doesn't pass the TypeArtifactFilter to the resolver/collector, but instead retrieves unfiltered dependencies and then post-filters them based on type (and creates another fileset or path) with dependencies not matching the filter removed. This is not implemented in a generic enough way to be used in standard Maven code, but perhaps suggests am alternative way of solving the filtering problem.

          Your fix looks like it will work and is simple enough (small and localised), but I do not know enough about Maven internals to tell what other consequences it may have.

          Show
          Tomislav Bodor added a comment - I have implemented an internal workaround for our project that doesn't pass the TypeArtifactFilter to the resolver/collector, but instead retrieves unfiltered dependencies and then post-filters them based on type (and creates another fileset or path) with dependencies not matching the filter removed. This is not implemented in a generic enough way to be used in standard Maven code, but perhaps suggests am alternative way of solving the filtering problem. Your fix looks like it will work and is simple enough (small and localised), but I do not know enough about Maven internals to tell what other consequences it may have.
          Hide
          Jeff Maxwell added a comment -

          Actually my fix had a bug.

          filter may be passed as NULL leading to a NPE

          Here is the fixed code:
          if ((filter != null) && (filter.include(artifact))|| node.filterTrail(filter))

          This allows me to create filesets of all one type.

          <maven2:dependencies verbose="true"
          filesetId="maven.cpp.dependency.fileset"
          type="zip">
          <pom refid="maven.project.pom" />
          <localRepository refid="maven.local.repository"/>
          </maven2:dependencies>

          Show
          Jeff Maxwell added a comment - Actually my fix had a bug. filter may be passed as NULL leading to a NPE Here is the fixed code: if ((filter != null) && (filter.include(artifact))|| node.filterTrail(filter)) This allows me to create filesets of all one type. <maven2:dependencies verbose="true" filesetId="maven.cpp.dependency.fileset" type="zip"> <pom refid="maven.project.pom" /> <localRepository refid="maven.local.repository"/> </maven2:dependencies>
          Jason van Zyl made changes -
          Fix Version/s 2.1 [ 11704 ]
          Fix Version/s 2.1.x [ 13142 ]
          Jason van Zyl made changes -
          Workflow Maven New [ 48170 ] jira [ 48170 ]
          Key MNG-1542 MANTTASKS-41
          Complexity Intermediate
          Project Maven 2 [ 10500 ] Maven 2.x Ant Tasks [ 11533 ]
          Jason van Zyl made changes -
          Fix Version/s 2.1.x [ 13142 ]
          Brett Porter made changes -
          Workflow jira [ 69372 ] Maven New [ 69409 ]
          Jason van Zyl made changes -
          Component/s Ant tasks [ 11532 ]
          Hervé Boutemy made changes -
          Component/s dependencies task [ 12843 ]
          Affects Version/s 2.0 [ 11703 ]
          Hide
          Bruce Brouwer added a comment - - edited

          I've just now been running into this problem as well. Is there any chance that this will be looked into?

          In my own debugging, I found that it does all come down to that node.filterTrail(filter) call. What I think needs to happen is that the TypeArtifactFilter needs to somehow not be called for the root node, which in this example would be the war. This way, when we specify a type of "jar", the filterTrail won't reject the root node of "war". Maybe this needs to be a new filter: TransitiveTypeArtifactFilter which ignores root nodes.

          I disagree, however, with Jeff Maxwell's solution. If I had a chain of war -> war -> jar (I know it's a bad example), then I would not want the jar included.

          Maybe a better example would be if I'm trying to get all the jars for an ear. In this case the node chain might be ear -> war -> jar. In this case, I would want not want this JAR in my fileset, but I would want a JAR from a node chain of ear -> jar in my fileset. Furthermore, I would also want a JAR from ear -> jar -> jar to show up.

          Jeff Maxwell's solution would even get me the ear -> war -> jar, which is not what I want.

          Show
          Bruce Brouwer added a comment - - edited I've just now been running into this problem as well. Is there any chance that this will be looked into? In my own debugging, I found that it does all come down to that node.filterTrail(filter) call. What I think needs to happen is that the TypeArtifactFilter needs to somehow not be called for the root node, which in this example would be the war. This way, when we specify a type of "jar", the filterTrail won't reject the root node of "war". Maybe this needs to be a new filter: TransitiveTypeArtifactFilter which ignores root nodes. I disagree, however, with Jeff Maxwell's solution. If I had a chain of war -> war -> jar (I know it's a bad example), then I would not want the jar included. Maybe a better example would be if I'm trying to get all the jars for an ear. In this case the node chain might be ear -> war -> jar. In this case, I would want not want this JAR in my fileset, but I would want a JAR from a node chain of ear -> jar in my fileset. Furthermore, I would also want a JAR from ear -> jar -> jar to show up. Jeff Maxwell's solution would even get me the ear -> war -> jar, which is not what I want.
          Paul Gier made changes -
          Link This issue is related to MANTTASKS-149 [ MANTTASKS-149 ]
          Hide
          Paul Gier added a comment -

          I ran into a simliar issue where I was using a pom with packaging set to "pom". When I set the type field to "jar" none of the dependencies were included in the resulting fileset because the root node was a pom type. I created MANTTASKS-149 to allow me to specify "pom" and "jar" in the acceptable types. This could also be used to specify "war, jar" to resolve some of the cases described in this issue.

          However, this won't solve situations where you have a tree like Bruce's example where you have war->war->jar, and you really only want jar files because the war will also be included in the resulting fileset.

          This probably needs to be fixed in maven's dependency management so that the tree is built first, and then the artifacts are filtered.

          Show
          Paul Gier added a comment - I ran into a simliar issue where I was using a pom with packaging set to "pom". When I set the type field to "jar" none of the dependencies were included in the resulting fileset because the root node was a pom type. I created MANTTASKS-149 to allow me to specify "pom" and "jar" in the acceptable types. This could also be used to specify "war, jar" to resolve some of the cases described in this issue. However, this won't solve situations where you have a tree like Bruce's example where you have war->war->jar, and you really only want jar files because the war will also be included in the resulting fileset. This probably needs to be fixed in maven's dependency management so that the tree is built first, and then the artifacts are filtered.
          Mark Thomas made changes -
          Project Import Sun Apr 05 09:00:58 UTC 2015 [ 1428224458201 ]
          Mark Thomas made changes -
          Workflow jira [ 12716112 ] Default workflow, editable Closed status [ 12759959 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 22:08:22 UTC 2015 [ 1428271702400 ]
          Mark Thomas made changes -
          Workflow jira [ 12953563 ] Default workflow, editable Closed status [ 12990681 ]
          Hide
          Michael Osipov added a comment -

          This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

          Show
          Michael Osipov added a comment - This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.
          Michael Osipov made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Auto Closed [ 10000 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          8d 21h 29m 1 Brett Porter 22/Nov/05 02:30
          Closed Closed Reopened Reopened
          17h 5m 1 Brett Porter 22/Nov/05 19:35
          Reopened Reopened Closed Closed
          3575d 1h 8m 1 Michael Osipov 06/Sep/15 20:44

            People

            • Assignee:
              Unassigned
              Reporter:
              Tomislav Bodor
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development