[
https://issues.apache.org/jira/browse/LUCENE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14286498#comment-14286498
]
Erick Erickson commented on LUCENE-6188:
----------------------------------------
Hmmm, thanks of pointing this out, but it makes things... complicated.
Problem is that until this is done, SOLR-6902 is blocked as that patch fails
precommit. For no good reason I can find. If I'm reading things right, doclint
is only in Java 8, so is simply not an option for 5x even if the problems you
point out are fixed up.
If I'm reading this right, Ramkumar's claim is that the html checking in this
patch that is being removed is unnecessary anyway, so removing it doesn't lose
us anything. And it's incorrectly failing this doc for some reason. I checked
the generated doc file and it looks fine, I think I even ran it through an XML
validator. I could always have missed something of course.
That said, the proposed changes in this JIRA to take a lot of code out of
checkJavaDocs.py, and I'll very much admit I haven't gone through the changes
in much detail, but they do appear to just be doing HTML validation.
I can treat this somewhat as a black box and do something like apply this patch
locally and:
1> create some invalid JavaDoc links and insure that they're flagged if this
patch is applied (any suggestions for a candidate list)? If that works (or,
more accurately fails the invalid javadocs), commit this patch to trunk and 5x
and then commit SOLR-6902
or
2> just remove the javadocs from SOLR-6902 or possibly munge them until that
code succeeds precommit.
or
3> try to figure out what the false failure is here and fix checkJavaDocs.py
I think <1> is my first choice, and <3> is a very distant third. Spending time
debugging code that it sounds like we're going to remove on trunk seems like a
waste. I may do <2> anyway, remove the javaDocs and put them if one of the
other approaches works. SOLR-6902 is hard to keep up to date since it touches
so much, Alan's checkin is already going to be a headache to reconcile. So
keeping it our of the code line just because of a bad (and possibly redundant)
bit of non-standard HTML checking seems like a poor tradeoff.
This last can be argued of course....
Anyway, I'll do some poking around and report back before committing anything.
> Remove HTML verification from checkJavaDocs.py
> ----------------------------------------------
>
> Key: LUCENE-6188
> URL: https://issues.apache.org/jira/browse/LUCENE-6188
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
> Reporter: Ramkumar Aiyengar
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: LUCENE-6188.patch, LUCENE-6188.patch
>
>
> Currently, the broken HTML verification in {{checkJavaDocs.py}} has issues in
> some cases (see SOLR-6902).
> On looking further to fix it with the {{html.parser}} package instead,
> noticed that there is broken HTML verification already present (using
> {{html.parser}}!)in {{checkJavadocLinks.py}} anyway which takes care of
> validation, and probably {{jTidy}} does it as well, going by the output
> (haven't verified it).
> Given this, the validation in {{checkJavaDocs.py}} doesn't seem to add any
> further value, so here's a patch to just nuke it instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
