[jira] [Commented] (SOLR-15265) decide if/how to validate lucene javadoc links

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

    [ 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)