[
https://issues.apache.org/jira/browse/MJAVADOC-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MJAVADOC-507:
-----------------------------------
Description:
For weird reasons, we're trying to use <offlineLinks> rather than <links> for
some of our links. Our configuration includes:
{code:xml} <offlineLink>
<url>https://checkerframework.org/api</url>
<location>https://checkerframework.org/api</location>
</offlineLink>{code}
If I run javadoc with -linkoffline set to this URL and location, I get links in
the resulting docs. However, if I run maven-javadoc-plugin, I get an error:
{noformat}[ERROR] Error fetching link:
https://checkerframework.org/api/package-list. Ignored it.{noformat}
Since javadoc can load the package-list fine and so can my browser, there seems
to be something wrong in maven-javadoc-plugin. To debug, I built my own
maven-javadoc-plugin, modified to display the full error that caused the
failure. It showed this:
{noformat}javax.net.ssl.SSLException: Certificate for <checkerframework.org>
doesn't match any of the subject alternative names: [*.cs.washington.edu]
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
at
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
at
org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:580)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:554)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at
org.apache.maven.plugins.javadoc.JavadocUtil.isValidPackageList(JavadocUtil.java:1666){noformat}
Now, I *don't* see this error if I run with Java 9. This suggests to me that
each copy of Java has its own certificate list/logic. That means that the
problem isn't in maven-javadoc-plugin per se.
However, it seems inevitable that the built-in Java list will go out of date
again, and maven-javadoc-plugin will fail again for some other site.
One solution would be for maven-javadoc-plugin to do whatever it is that
Javadoc itself does to recognize more certificates. However, this sounds
complicated.
The simple solution would be for maven-javadoc-plugin to stop pre-validating
package-list files altogether (since Javadoc will ignore them if they're truly
missing). But, if you want to keep the validation, then I'd suggest passing all
URLs to Javadoc, even the ones that fail validation. That way, users still get
a loud, red/yellow Maven error/warning for real problems, but false problems
like the one here don't keep Javadoc links from working.
was:
For weird reasons, we're trying to use <offlineLinks> rather than <links> for
some of our links. Our configuration includes:
<offlineLink>
<url>https://checkerframework.org/api</url>
<location>https://checkerframework.org/api</location>
</offlineLink>
If I run javadoc with -linkoffline set to this URL and location, I get links in
the resulting docs. However, if I run maven-javadoc-plugin, I get an error:
[ERROR] Error fetching link: https://checkerframework.org/api/package-list.
Ignored it.
Since javadoc can load the package-list fine and so can my browser, there seems
to be something wrong in maven-javadoc-plugin. To debug, I built my own
maven-javadoc-plugin, modified to display the full error that caused the
failure. It showed this:
javax.net.ssl.SSLException: Certificate for <checkerframework.org> doesn't
match any of the subject alternative names: [*.cs.washington.edu]
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
at
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
at
org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:580)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:554)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at
org.apache.maven.plugins.javadoc.JavadocUtil.isValidPackageList(JavadocUtil.java:1666)
Now, I *don't* see this error if I run with Java 9. This suggests to me that
each copy of Java has its own certificate list/logic. That means that the
problem isn't in maven-javadoc-plugin per se.
However, it seems inevitable that the built-in Java list will go out of date
again, and maven-javadoc-plugin will fail again for some other site.
One solution would be for maven-javadoc-plugin to do whatever it is that
Javadoc itself does to recognize more certificates. However, this sounds
complicated.
The simple solution would be for maven-javadoc-plugin to stop pre-validating
package-list files altogether (since Javadoc will ignore them if they're truly
missing). But, if you want to keep the validation, then I'd suggest passing all
URLs to Javadoc, even the ones that fail validation. That way, users still get
a loud, red/yellow Maven error/warning for real problems, but false problems
like the one here don't keep Javadoc links from working.
> -linkoffline rejects valid package-list files because of SSL problems
> ---------------------------------------------------------------------
>
> Key: MJAVADOC-507
> URL: https://issues.apache.org/jira/browse/MJAVADOC-507
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
> Affects Versions: 3.0.0
> Environment: Java 8
> Reporter: Chris Povirk
> Priority: Minor
>
> For weird reasons, we're trying to use <offlineLinks> rather than <links> for
> some of our links. Our configuration includes:
> {code:xml} <offlineLink>
> <url>https://checkerframework.org/api</url>
> <location>https://checkerframework.org/api</location>
> </offlineLink>{code}
> If I run javadoc with -linkoffline set to this URL and location, I get links
> in the resulting docs. However, if I run maven-javadoc-plugin, I get an error:
> {noformat}[ERROR] Error fetching link:
> https://checkerframework.org/api/package-list. Ignored it.{noformat}
> Since javadoc can load the package-list fine and so can my browser, there
> seems to be something wrong in maven-javadoc-plugin. To debug, I built my own
> maven-javadoc-plugin, modified to display the full error that caused the
> failure. It showed this:
> {noformat}javax.net.ssl.SSLException: Certificate for <checkerframework.org>
> doesn't match any of the subject alternative names: [*.cs.washington.edu]
> at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
> at
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
> at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
> at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:580)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:554)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.maven.plugins.javadoc.JavadocUtil.isValidPackageList(JavadocUtil.java:1666){noformat}
> Now, I *don't* see this error if I run with Java 9. This suggests to me that
> each copy of Java has its own certificate list/logic. That means that the
> problem isn't in maven-javadoc-plugin per se.
> However, it seems inevitable that the built-in Java list will go out of date
> again, and maven-javadoc-plugin will fail again for some other site.
> One solution would be for maven-javadoc-plugin to do whatever it is that
> Javadoc itself does to recognize more certificates. However, this sounds
> complicated.
> The simple solution would be for maven-javadoc-plugin to stop pre-validating
> package-list files altogether (since Javadoc will ignore them if they're
> truly missing). But, if you want to keep the validation, then I'd suggest
> passing all URLs to Javadoc, even the ones that fail validation. That way,
> users still get a loud, red/yellow Maven error/warning for real problems, but
> false problems like the one here don't keep Javadoc links from working.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
