Maven 2.x Dependency Plugin

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

depends upon

Bug - A problem which impairs or prevents the functions of the product. MDEP-122 Analyze target does not work correctly when only using a constant defined in a different module

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
Brian Fox 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
Brian Fox 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
Permalink
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
Permalink
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
Permalink
Brian Fox 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
Brian Fox 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
Permalink
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
Permalink
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
Permalink
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
Vote (13)
Watch (19)

Dates

  • Created:
    Updated:
    Resolved: