> 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.
This should be simple. In alternative-jdk-support.gradle, che
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 de
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 d
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
wrote:
>
> > I think the issue will boil down to exact version of java 11. It has to be
> > the one with the javadocs bug
> 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
releas
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
wrote:
> > I’ve started the release process using the wizard, which has found some
> broken links in jav
> 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
https://issues.apache.org/jira/browse/LUCENE-10477 could be backported via
https://github.com/apache/lucene-solr/pull/2656 which is ready for review.
Glad to hear there'll be a 8.11.2 release, thanks for volunteering to RM it!
From: dev@lucene.apache.org At: 05/13/22 00:04:02 UTC+1:00To:
dev@l
On Tue, May 17, 2022 at 5:59 AM Alan Woodward 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 wer
Sorry - my mistake. It's included in the check task on both the main and 9x
branches. Humans are unlikely to run it on 9x branch, but CI servers
(Jenkins and GitHub Actions) should run it every day on Java 11 at the
clean checkout.
./gradlew check --dry-run | grep checkBrokenLinks
:lucene:document
I traced what tasks are actually executed in "gradlew check" task from the
GitHub Actions log.
Not fully sure but javadocs/documentation validation (such as the broken
links check) could be possibly omitted from it?
If so, I think we should include it in the check task... I'll look at it;
please co
Thanks Uwe!
> On 16 May 2022, at 17:39, Uwe Schindler wrote:
>
> Hi,
>
> I enabled Policeman Jenkins builds of 9.2.
>
> I will enable ASF Jenkins, too. Takes a few minutes.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
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
13 matches
Mail list logo
