[
https://issues.apache.org/jira/browse/SOLR-15265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302136#comment-17302136
]
Chris M. Hostetter commented on SOLR-15265:
-------------------------------------------
Replying here to some comments from [~dweiss] in the parent issue...
{quote}I thought an alternative strategy could be to pull javadoc lucene
artifacts (jar files published by maven) and just unpack them locally to Solr
documentation... this would provide consistency and the ability to check
cross-links locally. And it's a relatively easy thing to do. If you need my
help there I can help out (a bit). Just confirm this is a direction you think
is worth exploring.
{quote}
that was in fact my first thought: that if lucene start publishing javadoc
jars, the ref-guide could depend on them, and unpack them for use in
checkLocalJavadocLinksSite ... but I wasn't sure if I could convince anyone
else that there was enough reason for lucene to start publishing javadoc jars.
my second thought was that maybe we could depend on lucene-src jars (which i
think already existing maven? ... maybe remembering wrong) and run javadocs on
them locally for the same purpose.
My final thought was that it might make sense to finally implement "remote"
link checking to validate every "http(s)://..." URL in the ref-guide (not on
every build, but maybe as part of a nightly job) including the lucene javadocs
.. but even then, as long as we are depending on a lucene SNAPSHOT version (or
even after 9.0, if we decide to start depending on 9.1.0-SNAPSHOT on a future
release branch), we would still need special logic to know to link to some
SNAPSHOT javadocs (ie: if get teh lucene jenkins jobs to start publishing them
from to nightlies.apache.org)
----
Given how many lucene javadoc links there are in the ref-guide, it would
probably still make sense to treat lucene as "special" as far as link checking
goes compared to other dependencies (we have 52 lines that refer to the
{{lucene-javadocs}} asciidoctor variable, but only 23 lines that refer to the
other {{ivy-*-version}} properties – and only 16 of those are lines that
involve URLs)
So if you think it would be relatively straight forward to start building
javadoc jars in lucene, I'm certainly game to update the ref-guide to start
using them for link checking.
> decide if/how to validate lucene javadoc links
> ----------------------------------------------
>
> Key: SOLR-15265
> URL: https://issues.apache.org/jira/browse/SOLR-15265
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> From parent issue...
> {quote}
> come up with a longer term plan for if/how we want to "validate" links to
> lucene javadocs
> * we currently don't do any validation of links to "remote" urls in the
> ref-guide content – regardless of wether they are hardcoded or version
> specific via ivy properties
> * we may want to revisit that now ... either in general, or via some lucene
> specific logic (possibly via fetching lucene src or javadoc jars) since we
> have so many links to lucene class javadocs
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
