Maven Dependency Plugin
  1. Maven Dependency Plugin
  2. MDEP-124

Dependency incorrectly reported as "Unused declared"

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: analyze
    • Labels:
      None
    • Number of attachments :
      0

      Description

      When a dependency is only required for a constant in a JAR, dependency:analyze incorrectly reports the dependency as "Unused declared".
      Example:

      Constants.jar has 1 class called Constants.java:

      package com.myco.util;
      
      public class Constants 
      {
          private Constants() {};
      
          public static final double PI = 3.14159;
      }
      

      Then App jar has App.java as:

      package com.myco.app;
      
      public class App 
      {
          public static void main( String[] args )
          {
              System.out.println( com.myco.util.Constants.PI );
          }
      }
      

      Since the constant gets optimized away in the generated App.class, the dependency is not detected, even though the project won't compile without it.

        Issue Links

          Activity

          Hide
          Barend Garvelink added a comment -

          Likewise, if you run dependency-analyze[Only] on a project without any source code in it (the plugin is defined in my root pom, and I'm building an EAR module), all project dependencies are reported as unused declared.

          Show
          Barend Garvelink added a comment - Likewise, if you run dependency-analyze [Only] on a project without any source code in it (the plugin is defined in my root pom, and I'm building an EAR module), all project dependencies are reported as unused declared.
          Hide
          brianfox brianfox added a comment -

          There's no way to fix the analysis in this instance since it's looking at bytecode. We should be able to safely skip the analysis though when we find no classes to analyze.

          Show
          brianfox brianfox added a comment - There's no way to fix the analysis in this instance since it's looking at bytecode. We should be able to safely skip the analysis though when we find no classes to analyze.
          Hide
          Max Bowsher added a comment -

          Regarding the "optimized away constant" problem, it would be handy for the plugin to offer a configuration element like:

          <suppressUnusedWarnings>
            <suppressUnusedWarning>com.example.foo:my-constants-artifact</suppressUnusedWarning>
          </suppressUnusedWarnings>
          
          Show
          Max Bowsher added a comment - Regarding the "optimized away constant" problem, it would be handy for the plugin to offer a configuration element like: <suppressUnusedWarnings> <suppressUnusedWarning> com.example.foo:my-constants-artifact </suppressUnusedWarning> </suppressUnusedWarnings>
          Hide
          Christian Schulte added a comment -

          Same happens with annotations @Retention(value=SOURCE).

          {xml}
          <dependency>
          <groupId>javax.annotation</groupId>
          <artifactId>jsr250-api</artifactId>
          <scope>compile</scope>
          <optional>true</optional>
          </dependency>{xml}

          Using the @Generated annotation compilation fails without the dependency.

          +1 for having the ability to configure the plugin to not print a warning in such situations.

          Show
          Christian Schulte added a comment - Same happens with annotations @Retention(value=SOURCE). {xml} <dependency> <groupId>javax.annotation</groupId> <artifactId>jsr250-api</artifactId> <scope>compile</scope> <optional>true</optional> </dependency>{xml} Using the @Generated annotation compilation fails without the dependency. +1 for having the ability to configure the plugin to not print a warning in such situations.
          Hide
          brianfox brianfox added a comment -

          The analyzer walks all classes and collects the list of imports essentially and then tries to mark dependencies when it finds an imported class in that dependency. There is no processing of the annotations or constants in the analyzer since it's looking purely at the bytecode. The best we can do here is allow you to annotate the configuration with a list of artifacts that should be ignored.

          Show
          brianfox brianfox added a comment - The analyzer walks all classes and collects the list of imports essentially and then tries to mark dependencies when it finds an imported class in that dependency. There is no processing of the annotations or constants in the analyzer since it's looking purely at the bytecode. The best we can do here is allow you to annotate the configuration with a list of artifacts that should be ignored.
          Hide
          Christoph Kutzinski added a comment -

          I'm seeing the problem with an annotation with RetentionPolicy.SOURCE, too.

          I know this would mean probably a lot of work, but the way to fix it IMHO would be to process the sourcecode, too.
          Otherwise what the dependency:analyze goal promises to do (finding unused, declared compile-time dependencies), is severely broken.

          Show
          Christoph Kutzinski added a comment - I'm seeing the problem with an annotation with RetentionPolicy.SOURCE, too. I know this would mean probably a lot of work, but the way to fix it IMHO would be to process the sourcecode, too. Otherwise what the dependency:analyze goal promises to do (finding unused, declared compile-time dependencies), is severely broken.
          Hide
          Herve Boutemy added a comment - - edited

          probably an explanation in the javadoc would be a first step, just to help people understand things the goal is missing (ie eveything that can't be detected at bytecode analysis level)

          Then it would be another task (another Jira issue) to enhance the way analysis is done to work on source instead of bytecode, which is another (more ambitious) approach than MDEP-122 = manually declare such exceptions

          Show
          Herve Boutemy added a comment - - edited probably an explanation in the javadoc would be a first step, just to help people understand things the goal is missing (ie eveything that can't be detected at bytecode analysis level) Then it would be another task (another Jira issue) to enhance the way analysis is done to work on source instead of bytecode, which is another (more ambitious) approach than MDEP-122 = manually declare such exceptions
          Hide
          Herve Boutemy added a comment -

          FAQ entry added in r1400733

          Show
          Herve Boutemy added a comment - FAQ entry added in r1400733

            People

            • Assignee:
              Herve Boutemy
              Reporter:
              Olivier Dehon
            • Votes:
              13 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: