dependency:analyze functionality

[sviperll]

maven-dependency-plugin provides very useful analyze goal. This goal allows you to find out unused and indirect dependencies.

maven-dependency-plugin operates over runtime dependencies only. The result is that if you use an annotation or compile-time constant from some package, this package will be considered unused. I think takari can overcome this limitation using compile-time information gathering, much like accessRulesViolation option works.

[ifedorenko]

Can you explain the problem you are trying to solve, maybe using small example project and observed/desired behaviour?

[sviperll]

I want a better replacement for dependency:analyze

dependency:analyze is limited, as stated here

Natural goal is to keep dependencies at minimum, this is good by many reasons: minimizing chance of incompatibility, breakage, integration problems, abandonment of one of dependencies.

Unavoidable requirement on a way to this goal is knowing your dependencies. You can have some dependencies on you dependency-list just in case. You can use classes from package not stated on dependency-list (as a transitive dependency). Using transitive dependencies is bad since it's additional implicit assumption that some package will always depend on some another package. And it is very difficult to find what's wrong when this assumption is not true any more. dependency:analyze allows you to find and eliminate such cases and thus keep you project healthy.

[electrum]

Module foo:

public class Foo {
    public static final String FOO = "hello world";
}

Module bar:

@MyAnnotation(value = Foo.FOO)

Now, suppose bar depends on foo and the above constant is the only thing it uses from foo. The Java compiler will inline the constant into the annotation and thus there will be no usages in the class files, causing dependency:analyze to incorrectly report that you aren't using it.

This situation can be quite difficult to figure out, especially if you don't understand how the plugin works and aren't intimately familiar with inlining rules, class files, etc. However, in my experience, it rarely occurs in practice.