Thanks Robert for elaborating. In that case (older Java11 is the cause), it makes sense to me that CI builds didn't hit it.
> I'm also ok with failing hard on the build if someone tries to use > such old stuff. I'd agree with this and it'd be great if we can fail to build locally and encourage devs to use a newer patch version of Java (instead of blaming developers for not upgrading jdk they use) - I have no good idea at all though. Tomoko 2022年5月18日(水) 13:04 Robert Muir <rcm...@gmail.com>: > I'm unable to even download an old enough jdk version to reproduce the > javadocs bugs Alan hits. The oldest you can get from adoptopenjdk > archives are 4-year old java 11 versions, still not old enough. > > There's no value to testing such broken old versions (e.g. 11.0.1) in > our CI when we've already done exactly that, years ago, and reported > bugs back and iterated. ppl should use most recent versions (e.g. > 11.0.15), especially for smoketesting and development. It is expected > that tests may fail, build may fail, you might hit SIGSEGV from > compiler, etc, if you use old buggy java 11.0.1 or similar. > I'm also ok with failing hard on the build if someone tries to use > such old stuff. > > On Tue, May 17, 2022 at 11:39 PM Robert Muir <rcm...@gmail.com> wrote: > > > > 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 > >
