But that's not the case at all. I suspect it is simply that Alan used an older version of java 11, one that has a javadocs bug.
On Tue, May 17, 2022 at 11:26 PM Tomoko Uchida <tomoko.uchida.1...@gmail.com> wrote: > > > I think the issue will boil down to exact version of java 11. It has to be > > the one with the javadocs bug that emits broken links in this situation. > > Yes - I think it'd be great if we can detect bugs in our code and the > language itself we depend on (Java 11) on nightly CI builds, not on the > release process (if possible!) :) > > Tomoko > > > 2022年5月18日(水) 9:46 Robert Muir <rcm...@gmail.com>: >> >> I think the issue will boil down to exact version of java 11. It has to be >> the one with the javadocs bug that emits broken links in this situation. >> >> On Tue, May 17, 2022, 8:39 PM Tomoko Uchida <tomoko.uchida.1...@gmail.com> >> wrote: >>> >>> > I’ve started the release process using the wizard, which has found some >>> > broken links in javadoc. >>> >>> I'm just interested in this point - as Uwe pointed out, Jenkins servers >>> (and also GitHub Actions I think) should hit the problem as they run on >>> branch_9x and Java 11 on a regular basis. >>> Could you let me know the exact command or the corresponding wizard lines? >>> If there are gaps between the nightly build and the wizard, we could try to >>> fill the gap. >>> >>> Tomoko >>> >>> >>> 2022年5月17日(火) 21:54 Robert Muir <rcm...@gmail.com>: >>>> >>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseyg...@gmail.com> wrote: >>>> > >>>> > It was part of the release process, which runs with Java 11. It should >>>> > be fixed now. >>>> > >>>> > > Newer java versions won't make a broken link, you just won't have a >>>> > > link at all. >>>> > >>>> > This seems a bit of a shame, as some of the problems were genuine API >>>> > bugs - public methods with package-private parameter classes, and so on. >>>> > Do we have other ways of detecting these? Warning levels on the >>>> > compiler maybe? >>>> > >>>> >>>> Agreed, although we are really abusing the functionality. Main purpose >>>> of the check is to prevent broken links (HTTP 404 from the website, >>>> etc). >>>> >>>> I don't know of a built-in way to do the exact check. One idea is to >>>> add a check to our custom doclet: >>>> https://github.com/apache/lucene/blob/main/dev-tools/missing-doclet/src/main/java/org/apache/lucene/missingdoclet/MissingDoclet.java >>>> >>>> Element has getModifiers() which should be enough to check the >>>> visibility of things like parameters and return type. However, we >>>> might have to restructure the checker a bit, for most modules we >>>> aren't even descending into "parameter" level checks today: most >>>> modules are only enforcing at class level. >>>> >>>> Honestly it is still probably the wrong tool for this, as the issue >>>> really isn't javadocs related. But the doclet is a hammer we can use >>>> for checks like this. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
