Details

    • Type: Sub-task Sub-task
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: dependencies task
    • Labels:
      None
    • Number of attachments :
      2

      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. build.xml
        2 kB
        Tomislav Bodor
      2. pom.xml
        0.6 kB
        Tomislav Bodor

        Issue Links

          Activity

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

            People

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

              Dates

              • Created:
                Updated: