[MSHARED-632] Expose which dependency classes are used and where

[jhaber]

This PR is largely the same as apache/maven-shared#21, just targeting the new repo as requested. The JIRA includes the full context, but the basic idea with this PR is to introduce the concept of a DependencyUsage and expose this in the ProjectDependencyAnalysis. This exposes more information about specifically which class is used and where, which can then be used by the dependency plugin to produce more detailed output. Here's an example of the output it would enable:

Before:

[WARNING] Used undeclared dependencies found:
[WARNING]    com.google.inject:guice:jar:4.1.0:compile
[WARNING]    com.google.guava:guava:jar:19.0:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------ 

After:

[WARNING] Used undeclared dependencies found:
[WARNING]    com.google.inject:guice:jar:4.1.0:compile
[WARNING]     - com.google.inject.Module is referenced in com.hubspot.embedrest.EmbedRestService
[WARNING]     - com.google.inject.Inject is referenced in com.hubspot.embedrest.v3.FormsResource
[WARNING]     - com.google.inject.Provides is referenced in com.hubspot.embedrest.config.EmbedModule
[WARNING]     - com.google.inject.Singleton is referenced in com.hubspot.embedrest.config.EmbedModule
[WARNING]     - com.google.inject.name.Named is referenced in com.hubspot.embedrest.config.EmbedModule
[WARNING]     - ... and 7 more
[WARNING] 
[WARNING]    com.google.guava:guava:jar:19.0:compile
[WARNING]     - com.google.common.base.Strings is referenced in com.hubspot.embedrest.v3.FormsResource
[WARNING]     - com.google.common.base.Optional is referenced in com.hubspot.embedrest.managers.FormDefinitionsManager
[WARNING] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

---

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes. Also be sure having selected the correct component.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MSHARED-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MSHARED-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its clean verify). ([WARNING] The requested profile "run-its" could not be activated because it does not exist.)

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[elharo]

This is an incompatible change. Would it make sense to simply make analyze include usages?

[jhaber]

Would it make sense to simply make analyze include usages?

How were you thinking that would work, change the return type of analyze method? Isn't that also incompatible? And just to confirm, you're thinking about the case where someone wrote a custom implementation of DependencyAnalyzer and registered it for use with the dependency plugin?

One option that comes to mind is making analyzeWithUsages a default interface method with an implementation that throws something like UnsupportedOperationException. That way the dependency plugin can try to gracefully handle this case and fall back to the regular analyze method, for example:

  try 
  {
    return dependencyAnalyzer.analyzeWithUsages( url );
  }
  catch ( UnsupportedOperationException e )
  {
    log.warn( "Dependency analyzer {} should be updated to implement analyzeWithUsages", dependencyAnalyzer  );
    return dependencyAnalyzer.analyze( url );
  }

[elharo]

We don't have default interface methods until java 8. :-(

[jhaber]

In that case another option is to keep things as-is and have the dependency plugin use the same pseudo-code as above, except it would catch something like NoSuchMethodError instead of UnsupportedOperationException (with a comment explaining the situation). Certainly not ideal, but it seems like we ultimately need some way for the dependency plugin to detect that the analyzer doesn't support the new functionality and gracefully degrade

[elharo]

We don't have default interface methods until java 8. :-(

[jhaber]

Gentle bump on this, let me know if there's anything I can do to move this PR along

[elharo]

sorry I let this one drop. I can take another look, but you need to resolve conflicts first.