[MJAVADOC-694] Avoid empty warn message from getResolvePathResult

[slawekjaranowski]

Because user can't do nothing with such message, and exception don't break execution,
logging in verbose mode with stacktrace will be enough.

---

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.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MJAVADOC-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 -Prun-its to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.

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.

[slawekjaranowski]

@rfscholte please look, you last fix plugin fo java modules - MJAVADOC-568

[rfscholte]

type in resove (missing the L)

[rfscholte]

Don't write the stacktrace, it is not useful. If the message is empty, it must be fixed in plexus-java.

[slawekjaranowski]

Implementation in plexus-java for jdk < 9 is:

https://github.com/codehaus-plexus/plexus-languages/blob/e1450e99c53e45a4935f4bd65b4349877d6cdbb1/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/CmdModuleNameExtractor.java#L44-L47

What is your proposition for code here?

we can provide some message for UnsupportedOperationException in plexus-java ... but logging warn here is too talkative, it look like standard flow for detecting modules support

[rfscholte]

The problem is that if there's no module descriptor nor Manifest file with an Automatic-Module-Name, you need Java 9 code to get the module name based on the filename. So you must set in JdkHome in the request if you're not running with Java 9+.
The plugin is responsible to set this up correctly.
IIRC due to a recent change this method became exposed, otherwise it would never occur. So better to improve the message of the exception.

[slawekjaranowski]

probably it is another issue that plugin don't set JdkHome .. all test pass so such behavior is not coverage by regression ...

[rfscholte]

JdkHome should only be set when using ToolChain

[slawekjaranowski]

It seems more complicated, i don't see any test for toolchains in project, so it should be done as separate bigger issue.

[rfscholte]

discovered an existing bug here: e should be cause

[slawekjaranowski]

I don't exactly understood your comments, do you want change message of .debug("...")?

[rfscholte]

The purpose it to log the message of the root cause, so it should be
getLog().debug( "resolve path for: " + artifactFile + " cause error: " + cause );

[slawekjaranowski]

I see, fixed

[rfscholte]

Let's give it a try; I hope that if javadoc fails, that exception is clear enough to solve the issue.

[slawekjaranowski]

Thanks for approval, so please merge and process jira issue

[cowwoc]

@rfscholte I don't think that <jdkToolchain> works as expected. I filed https://issues.apache.org/jira/browse/MJAVADOC-704 related to this issue.

[jira-importer]

Resolve #1070