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 <rcmuir@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.1111@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 <rcmuir@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.1111@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 <rcmuir@gmail.com>:
> >>>>
> >>>> On Tue, May 17, 2022 at 5:59 AM Alan Woodward <romseygeek@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-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org