Hi,
I fixed this. Was a merge problem, because in 9.x, Dawid's module system
changed were not yet merged.
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Apache Jenkins Server
> Sent: Thursday, January 6,
I confirmed that the Lucene-Check-main job now passes:
https://builds.apache.org/job/Lucene/job/Lucene-Check-main/.
On Thu, Jan 6, 2022 at 2:49 PM Dawid Weiss wrote:
>
>
> > And then another "private one" next to it. The Github-supplied one should
> > include a local one.
>
> I'd love such a
Perhaps an alternative would be to create an identical set of tags pointing
at a single commit which would contain a plain text file delegating you to
where the code for these tags actually is (different repository)? :) Hell,
you could even set up a submodule (to the shared repository) inside new
> And then another "private one" next to it. The Github-supplied one
should include a local one.
I'd love such a solution too. But there is no way to do it, as far as I
know - these properties are read early on (they determine jvm settings).
Also, these settings do depend on the local
I agree with Dawid, why the hell do we need those tags? The old lucene-solr
repo can stay forever on Github. If I want to checkout an older version, I
would go into the old repo and check it out. In fact that’s also what tools may
do, because the old git repo is stated in the pom.xml files (or
Hi Adrien,
all is setup. I copied an example file over and just added the jvm/worker props
and gradle daemon shit. Actually the gradle.properties stuff is a bit shitty to
handle in CI environments, as you always have to workaround some shortcomings
of gradle.
I'd prefer to have some local
Hi Uwe,
There is no hurry to merge the pull request, so feel free to go back
to JDK 11 on Policeman Jenkins and I'll merge the PR when everything
is ready.
On Thu, Jan 6, 2022 at 12:08 PM Uwe Schindler wrote:
>
> I think I know: On Policeman Jenkins it starts with clean checkout always
> (same
I think I know: On Policeman Jenkins it starts with clean checkout always (same
on ASF Jenkins), but ASF Jenkins places the config file template after
checkout. So there's no gradle.properties file. On policeman, I have to
replicate the full file into the global jenkins one. An alternative is
Hi,
it still fails with Policeman Jenkins and I think we can't easily fix this
until we patch the build file, too:
Policeman Jenkins uses the feature of RUNTIME_JAVA_HOME. If that is enabled,
javac will be forked and runs as a separate process. And this separate process
seems to not get the
Hi,
On my jenkins all nodes had a local gradle.properties file in their home
directory to setup node-specific values. As Gradle searches for all those files
and applies them, the node-specific ones now only have the daemon disable and
the number of workers. Everything else I removed.
So it
Your gradle.properties looks good, it shouldn't hit the same issue as
the ASF Jenkins. The gradle.properties of the ASF Jenkins looked like
this before I updated it:
```
# Disable Gradle daemon for all builds.
org.gradle.daemon=false
# Lucene specific settings for lucene2 build nodes
But Jenkins removes its gradle.properties file from the build directory before
each build as it starts with a clean checkout.
So it is not understandable to me. It recreated the file:
https://jenkins.thetaphi.de/job/Lucene-main-Linux/ws/gradle.properties/*view*/
See also timestamp:
I just updated the gradle.properties file under "Config files" to add
the module exports to JVM args, the next build should pass.
On Thu, Jan 6, 2022 at 11:28 AM Adrien Grand wrote:
>
> To clarify, merging the PR wouldn't address the test failures.
>
> On Thu, Jan 6, 2022 at 11:27 AM Adrien
To clarify, merging the PR wouldn't address the test failures.
On Thu, Jan 6, 2022 at 11:27 AM Adrien Grand wrote:
>
> This seems to be due to the fact that it's using an old
> gradle.properties file that doesn't have the module exports that Dawid
> added as part of LUCENE-10066.
>
This seems to be due to the fact that it's using an old
gradle.properties file that doesn't have the module exports that Dawid
added as part of LUCENE-10066.
https://github.com/apache/lucene/pull/259/files#diff-fbdfae634c6898f4a415bc2a278ff771c38436d70b0e64250ab068b4b3e58426R48-R52
Let me look
Thanks Uwe!
On Thu, Jan 6, 2022 at 11:07 AM Uwe Schindler wrote:
>
> Hi Adrien,
>
> I updated the jobs and their randomization to only randomize >=17 for
> RUNTIME_JAVA_HOME and use JDK 17 as Gradle JDK (JAVA_HOME).
>
> Later today I only need to update to latest jdk-17 bugfix release,
Hi Adrien again,
I just noticed: Spotless now fails on main builds, is this expected? I have the
feeling you updated it only in the new branch. So will you merge very soon or
should I revert? I think merging now may be better as its lot of work.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357
Hi Adrien,
I updated the jobs and their randomization to only randomize >=17 for
RUNTIME_JAVA_HOME and use JDK 17 as Gradle JDK (JAVA_HOME).
Later today I only need to update to latest jdk-17 bugfix release, currently it
is GA release only.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357
I just disabled 8.11 jobs on the ASF Jenkins.
On Thu, Jan 6, 2022 at 9:33 AM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.11-MacOSX/164/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
>
> 1 tests failed.
> FAILED:
>
Hello all,
I am about to bump the minimum required version to build Lucene from
11 to 17 on the main branch, ie. Lucene 10.0, so you won't be able to
build Lucene unless JAVA_HOME points to a JDK 17.
Here is the link to the PR for those interested:
https://github.com/apache/lucene/pull/579.
I
Sorry, I found and use api addreplicaprop, it's what I need, thanks четверг, 30
декабря 2021г., 19:39 +03:00 от Alex Bulygin alex_buly...@bk.ru.invalid :
>Hi all!
>Anyone who know, please tell me, it is possible to add a custom property to
>replica state in zk? While I see that properties
21 matches
Mail list logo
