Re: [PR] Fix usage of deprecated Gradle APIs scheduled to be removed in Gradle 9.0 [lucene]
dweiss commented on PR #14781: URL: https://github.com/apache/lucene/pull/14781#issuecomment-2975245870 > One problem that gradle is suffering from is, all the freedom it had given in the (groovy) DSL implementation in its early days. Thanks. It's subjective, I know, but I have been a user of gradle since these early days and that freedom... I miss it. My subjective gut feeling is also that in the early days - when stripped of all the added-on features like build caches, configuration caches, etc. - gradle startup wasn't even a problem. My memory may be playing tricks on me but I do miss the simplicity of the early days (when it was basically ant tasks + groovy to configure everything). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[I] build and push release regression [lucene]
dweiss opened a new issue, #14786: URL: https://github.com/apache/lucene/issues/14786 ### Description Something stopped working here - https://github.com/apache/lucene/actions/runs/15670563859 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] compileMain24Java fails with JDK25+ [lucene]
dweiss commented on issue #14782: URL: https://github.com/apache/lucene/issues/14782#issuecomment-2975278118 I've applied your patch, looks better indeed, thank you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] Remove duplicate -Xlint:options flags. [lucene]
dweiss opened a new pull request, #14788: URL: https://github.com/apache/lucene/pull/14788 Fixes #14782 by not emitting duplicate lint flags to javac. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[I] spotlessGradleScripts doesn't work with whitespace-paths on Windows [lucene]
dweiss opened a new issue, #14787: URL: https://github.com/apache/lucene/issues/14787 ### Description As reported by Uwe - ``` > Task :spotlessGradleScripts Missing required bundle org.eclipse.jdt.debug needed by [org.eclipse.jdt.launching, org.eclipse.jdt.launching.macosx] Missing required capability osgi.extender:osgi.extender=osgi.serviceloader.processor needed by org.apache.commons.commons-logging Missing required capability osgi.serviceloader:osgi.serviceloader=org.apache.commons.logging.LogFactory needed by org.apache.commons.commons-logging Recommend setting osgi.configuration.area to a directory, getDataFile will return null Error in activator of org.eclipse.equinox.registry java.lang.RuntimeException: java.nio.file.NoSuchFileException: C:\Users\Uwe%20Schindler\.m2\repository\dev\equo\p2-data\bundle-pool\https-download.eclipse.org-eclipse-updates-4.35-R-4.35-202502280140-\org.eclipse.osgi_3.23.0.v20250228-0640.jar at dev.equo.solstice.Unchecked.wrap(Unchecked.java:47) at dev.equo.solstice.ShimBundle.parseFromZip(ShimBundle.java:265) at dev.equo.solstice.ShimBundle.getEntry(ShimBundle.java:241) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.getExtensionURL(EclipseBundleListener.java:122) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.addBundle(EclipseBundleListener.java:168) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.processBundles(EclipseBundleListener.java:94) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.onStart(RegistryStrategyOSGI.java:278) at org.eclipse.core.internal.registry.ExtensionRegistry.(ExtensionRegistry.java:789) at org.eclipse.core.runtime.RegistryFactory.createRegistry(RegistryFactory.java:69) at org.eclipse.core.internal.registry.osgi.Activator.startRegistry(Activator.java:147) at org.eclipse.core.internal.registry.osgi.Activator.start(Activator.java:60) at dev.equo.solstice.ShimBundle.activate(ShimBundle.java:166) at dev.equo.solstice.ShimBundle.start(ShimBundle.java:132) at dev.equo.solstice.Solstice.start(Solstice.java:453) at dev.equo.solstice.Solstice.start(Solstice.java:407) at dev.equo.solstice.Solstice.start(Solstice.java:446) at dev.equo.solstice.Solstice.start(Solstice.java:407) ``` ### Version and environment details _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[I] Revert back to jgit for collecting git status [lucene]
dweiss opened a new issue, #14785: URL: https://github.com/apache/lucene/issues/14785 ### Description Revert native git to jgit for collecting git status. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Remove duplicate -Xlint:options flags. [lucene]
dweiss commented on code in PR #14788:
URL: https://github.com/apache/lucene/pull/14788#discussion_r2149179129
##
build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle:
##
@@ -32,9 +32,14 @@ configure(project(":lucene:core")) {
tasks.named("compileMain${jdkVersion}Java").configure {
def apijar = apijars.file("jdk${jdkVersion}.apijar")
+// TODO: this depends on the order of argument configuration...
int releaseIndex = options.compilerArgs.indexOf("--release")
options.compilerArgs.removeAt(releaseIndex)
options.compilerArgs.removeAt(releaseIndex)
+
+// Remove conflicting options for the linter. #14782
+options.compilerArgs.removeAll("-Xlint:options")
Review Comment:
@breskeby is there any nicer way to do this kind of compilerArgs
manipulation that doesn't
depend on the ordering of those configuration callbacks? I can think of a
custom argument provider but this would be even more confusing than what it is
now, I think.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Remove duplicate -Xlint:options flags. [lucene]
github-actions[bot] commented on PR #14788: URL: https://github.com/apache/lucene/pull/14788#issuecomment-2975317328 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] compileMain24Java fails with JDK25+ [lucene]
dweiss commented on issue #14782: URL: https://github.com/apache/lucene/issues/14782#issuecomment-2975300641 I looked at the JDK issue and Archie couldn't reproduce the issue. Here's a repro - ``` .../jdk-25+27/bin/javac -source 24 -target 24 -Xlint:options -Xlint:-options -Werror Foo.java warning: [options] location of system modules is not set in conjunction with -source 24 not setting the location of system modules may lead to class files that cannot run on JDK 24 --release 24 is recommended instead of -source 24 -target 24 because it sets the location of system modules automatically error: warnings found and -Werror specified 1 error 1 warning ``` note there is a pair of -Xlint options - one enabling, the other disabling the 'options' flag. Archie is right that it works well if it's just ```-Xlint:-options``` so I don't know if it should be classified as a bug in JDK... perhaps it could be more informative about conflicting options (or use their sequential order to enable/disable flags). I'll try to fix it in our build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Make `pack` methods public for `BigIntegerPoint` and `HalfFloatPoint` [lucene]
prudhvigodithi commented on PR #14784: URL: https://github.com/apache/lucene/pull/14784#issuecomment-2974928884 I have just updated the CHANGES.txt adding to 10.2.2, please let me know if this is ok else I can change back to 10.3.0. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] Make `pack` methods public for `BigIntegerPoint` and `HalfFloatPoint` [lucene]
prudhvigodithi opened a new pull request, #14784: URL: https://github.com/apache/lucene/pull/14784 ### Description Following this commit https://github.com/apache/lucene/commit/94c76c790cd0b8b1bca384c5de18ec5c7957d5d9 make `pack` methods public for `BigIntegerPoint` and `HalfFloatPoint`. Please let me know if there’s any restriction in sandbox packages that requires methods to be non-public. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Make `pack` methods public for `BigIntegerPoint` and `HalfFloatPoint` [lucene]
github-actions[bot] commented on PR #14784: URL: https://github.com/apache/lucene/pull/14784#issuecomment-2974683710 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] [Build] Fix more gradle deprecation warnings scheduled to be removed in 9.0 [lucene]
github-actions[bot] commented on PR #14783: URL: https://github.com/apache/lucene/pull/14783#issuecomment-2973667019 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] [Build] Fix more gradle deprecation warnings scheduled to be removed in 9.0 [lucene]
breskeby opened a new pull request, #14783: URL: https://github.com/apache/lucene/pull/14783 ### Description This fixes two more types of deprecations seen in the build: 1. Fix file permission setup using non deprecated Gradle API 2. Fix deprecated usage of other projects configurations Resolution of the configuration :icu_current was done from a context different than the root project. This is problematic and deprecated behavior scheduled to be removed in Gradle 9.0. See https://docs.gradle.org/8.14/userguide/how_to_share_outputs_between_projects.html\#variant-aware-sharing for details how dependencies should be shared accross projects. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] [Build] Fix more gradle deprecation warnings scheduled to be removed in 9.0 [lucene]
breskeby commented on code in PR #14783:
URL: https://github.com/apache/lucene/pull/14783#discussion_r2147569228
##
build-tools/build-infra/src/main/groovy/lucene.regenerate.icu.gradle:
##
@@ -30,14 +30,15 @@ def resources = rootProject.file("gradle/regenerate/icu")
* download and compile a matching icu4c version automatically.
*/
-// Configure different icu4j dependencies.
-configure(rootProject) {
Review Comment:
Declaring a configuration in one project and use it in another as done here
before was one. of those things that had been technically possible forever,
never recommended and now been deprecated. A good example of the problem with
the historical approach in Gradle that in build logic there hasn't been any
boundaries accross projects and the whole global model has been available from
everywhere.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] [Build] Fix more gradle deprecation warnings scheduled to be removed in 9.0 [lucene]
breskeby commented on code in PR #14783:
URL: https://github.com/apache/lucene/pull/14783#discussion_r2147573314
##
build-tools/build-infra/src/main/groovy/lucene.regenerate.icu.gradle:
##
@@ -30,14 +30,15 @@ def resources = rootProject.file("gradle/regenerate/icu")
* download and compile a matching icu4c version automatically.
*/
-// Configure different icu4j dependencies.
-configure(rootProject) {
Review Comment:
IMO this plugin is a good example of something that can benefit from been
ported into a binary plugin and only keep its actual implementation in this
convention plugin rather all the nitty bits of implementation details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] [Build] Fix more gradle deprecation warnings scheduled to be removed in 9.0 [lucene]
github-actions[bot] commented on PR #14783: URL: https://github.com/apache/lucene/pull/14783#issuecomment-2973676150 This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] compileMain24Java fails with JDK25+ [lucene]
uschindler commented on issue #14782:
URL: https://github.com/apache/lucene/issues/14782#issuecomment-2973765065
I added a similar hack to 10.x branch:
2503e832c17f6744dc33fd837f7e9f0e07d4
I'd prefer to only apply this to the MR-JAR part of compilation:
```patch
build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle | 2 ++
build-tools/build-infra/src/main/groovy/lucene.java.javac.gradle | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
a/build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle
b/build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle
index 60a4588ba2d..3838cf9854f 100644
--- a/build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle
+++ b/build-tools/build-infra/src/main/groovy/lucene.java.core.mrjar.gradle
@@ -43,6 +43,8 @@ configure(project(":lucene:core")) {
"--add-exports",
"java.base/jdk.incubator.vector=ALL-UNNAMED",
]
+// hack because -Xlint:-options does not work for all options
(regression in JDK 25+?):
+options.compilerArgs.remove("-Werror")
def argsProvider = objects.newInstance(CompilerArgsProvider)
argsProvider.apiJarFile.set(apijar)
diff --git
a/build-tools/build-infra/src/main/groovy/lucene.java.javac.gradle
b/build-tools/build-infra/src/main/groovy/lucene.java.javac.gradle
index 67aaf29c7a4..8f20d9c030b 100644
--- a/build-tools/build-infra/src/main/groovy/lucene.java.javac.gradle
+++ b/build-tools/build-infra/src/main/groovy/lucene.java.javac.gradle
@@ -81,7 +81,7 @@ tasks.withType(JavaCompile).configureEach {
// proc:none was added because of LOG4J2-1925 / JDK-8186647
options.compilerArgs += ["-proc:none"]
-if (failOnWarningsOption.get() && (rootProject.ext.runtimeJavaVersion <
JavaVersion.VERSION_25)) {
+if (failOnWarningsOption.get()) {
options.compilerArgs += "-Werror"
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] compileMain24Java fails with JDK25+ [lucene]
uschindler commented on issue #14782: URL: https://github.com/apache/lucene/issues/14782#issuecomment-2973767174 Of course you could add the version check, too, but disabling -Werror for the MR-JAR part is fine IMHO, because it is a hack anyways and further warnings may appear any time soon. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [I] compileMain24Java fails with JDK25+ [lucene]
uschindler commented on issue #14782: URL: https://github.com/apache/lucene/issues/14782#issuecomment-2973762322 I opened an issue @ JDK: https://bugs.openjdk.org/browse/JDK-8359596 > This used to work with JDK 25-beta+11-ea. It also worked afterwards (25 ea+15). It is a rather new problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Build refactoring and cleanups (moving from build scripts to convention plugins) [lucene]
uschindler commented on PR #14764: URL: https://github.com/apache/lucene/pull/14764#issuecomment-2973786942 > * `:spotlessGradleScripts` seems incredibly slow, but it is just a one-time pain, the very first time you run it. I think it downloads. It is also slow when you run it later. It doenloads a lot of shit yes, but execution is also slow. You won't notice later unless you change anything in build infrastructure. An what's worst: If you have whitespace in your checkout (we test this also on ASF Jenkins), it spams you with this insane amout of bullshit: ``` > Task :spotlessGradleScripts Missing required bundle org.eclipse.jdt.debug needed by [org.eclipse.jdt.launching, org.eclipse.jdt.launching.macosx] Missing required capability osgi.extender:osgi.extender=osgi.serviceloader.processor needed by org.apache.commons.commons-logging Missing required capability osgi.serviceloader:osgi.serviceloader=org.apache.commons.logging.LogFactory needed by org.apache.commons.commons-logging Recommend setting osgi.configuration.area to a directory, getDataFile will return null Error in activator of org.eclipse.equinox.registry java.lang.RuntimeException: java.nio.file.NoSuchFileException: C:\Users\Uwe%20Schindler\.m2\repository\dev\equo\p2-data\bundle-pool\https-download.eclipse.org-eclipse-updates-4.35-R-4.35-202502280140-\org.eclipse.osgi_3.23.0.v20250228-0640.jar at dev.equo.solstice.Unchecked.wrap(Unchecked.java:47) at dev.equo.solstice.ShimBundle.parseFromZip(ShimBundle.java:265) at dev.equo.solstice.ShimBundle.getEntry(ShimBundle.java:241) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.getExtensionURL(EclipseBundleListener.java:122) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.addBundle(EclipseBundleListener.java:168) at org.eclipse.core.internal.registry.osgi.EclipseBundleListener.processBundles(EclipseBundleListener.java:94) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.onStart(RegistryStrategyOSGI.java:278) at org.eclipse.core.internal.registry.ExtensionRegistry.(ExtensionRegistry.java:789) at org.eclipse.core.runtime.RegistryFactory.createRegistry(RegistryFactory.java:69) at org.eclipse.core.internal.registry.osgi.Activator.startRegistry(Activator.java:147) at org.eclipse.core.internal.registry.osgi.Activator.start(Activator.java:60) at dev.equo.solstice.ShimBundle.activate(ShimBundle.java:166) at dev.equo.solstice.ShimBundle.start(ShimBundle.java:132) at dev.equo.solstice.Solstice.start(Solstice.java:453) at dev.equo.solstice.Solstice.start(Solstice.java:407) at dev.equo.solstice.Solstice.start(Solstice.java:446) at dev.equo.solstice.Solstice.start(Solstice.java:407) at dev.equo.solstice.Solstice.start(Solstice.java:446) at dev.equo.solstice.Solstice.start(Solstice.java:407) at dev.equo.solstice.Solstice.start(Solstice.java:446) at dev.equo.solstice.Solstice.start(Solstice.java:407) at dev.equo.solstice.Solstice.start(Solstice.java:446) at dev.equo.solstice.Solstice.start(Solstice.java:397) at dev.equo.solstice.Solstice.start(Solstice.java:381) at com.diffplug.spotless.extra.glue.groovy.GrEclipseFormatterStepImpl.(GrEclipseFormatterStepImpl.java:66) at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method) at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1166) at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:341) at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:104) at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:143) at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:546) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:496) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483) at com.diffplug.spotless.extra.groovy.GrEclipseFormatterStep.apply(GrEclipseFormatterStep.java:92) at com.diffplug.spotless.FormatterStepSerializationRoundtrip.stateToFormatter(FormatterStepSerializationRoundtrip.java:64) at com.diffplug.spotless.FormatterStepEqualityOnStateSerialization.format(FormatterStepEqualityOnStateSerialization.java:47) at com.diffplug.spotless.Formatter.computeWithLint(Formatter.java:170) at com.diffplug.spotless.DirtyState.of(DirtyState.java:97) at com.diffplug.spotless.LintState.of(LintState.java:140) at com.diffplug.sp
Re: [PR] Implement `ConstantScoreScorer#nextDocsAndScores` [lucene]
HUSTERGS commented on PR #14772: URL: https://github.com/apache/lucene/pull/14772#issuecomment-2973806605 > Interesting. I don't believe that being able to use `Arrays#fill` helps much, but maybe the fact that this change helps reduce polymorphism does? @jpountz Thanks for your reply! (apologies for late reply). Actually I'm not very sure what's the root cause of this performance gain, My previous thought is that this change can co-operate with other query which implemnts the `nextDocsAndScores` and reduce the `score` function calls. Anyway, I did another luceneutil `wikimediumall` and `taskCountPerCat=5` based on `3064f4b2aac3526f5f5fe37a8798395511aabd46` (which is this pr checked out from) to confirm the result again: ``` TaskQPS baseline StdDevQPS my_modified_version StdDevPct diff p-value CombinedOrHighHigh6.46 (2.9%)6.35 (4.0%) -1.7% ( -8% -5%) 0.124 CombinedOrHighMed 24.82 (4.6%) 24.42 (7.2%) -1.6% ( -12% - 10%) 0.405 Prefix3 94.43 (2.8%) 93.11 (3.9%) -1.4% ( -7% -5%) 0.195 IntervalsOrdered2.98 (2.7%)2.94 (2.3%) -1.4% ( -6% -3%) 0.085 TermMonthSort 2333.34 (3.4%) 2303.15 (3.4%) -1.3% ( -7% -5%) 0.233 FilteredPrefix3 88.42 (3.0%) 87.33 (2.9%) -1.2% ( -6% -4%) 0.184 IntSet 389.99 (5.2%) 385.58 (4.7%) -1.1% ( -10% -9%) 0.470 TermDayOfYearSort 343.29 (3.4%) 339.52 (3.6%) -1.1% ( -7% -6%) 0.321 TermDTSort 189.75 (4.9%) 187.77 (4.8%) -1.0% ( -10% -9%) 0.494 CountTerm 6236.56 (5.6%) 6180.21 (4.8%) -0.9% ( -10% - 10%) 0.584 AndHighOrMedMed 17.22 (3.6%) 17.07 (3.3%) -0.9% ( -7% -6%) 0.421 IntNRQ 48.24 (2.4%) 47.83 (2.8%) -0.8% ( -5% -4%) 0.307 FilteredIntNRQ 47.76 (2.5%) 47.48 (2.7%) -0.6% ( -5% -4%) 0.467 Wildcard 56.24 (1.8%) 55.94 (2.9%) -0.5% ( -5% -4%) 0.480 CombinedTerm 13.58 (4.2%) 13.51 (4.2%) -0.5% ( -8% -8%) 0.721 OrMany5.44 (4.9%)5.42 (4.7%) -0.3% ( -9% -9%) 0.826 CombinedAndHighHigh6.40 (3.0%)6.39 (3.6%) -0.2% ( -6% -6%) 0.834 Respell 43.41 (2.6%) 43.32 (3.0%) -0.2% ( -5% -5%) 0.817 FilteredTerm 84.14 (2.3%) 83.97 (2.7%) -0.2% ( -5% -4%) 0.802 CountFilteredIntNRQ 21.90 (1.7%) 21.86 (2.2%) -0.2% ( -4% -3%) 0.781 CountPhrase3.22 (2.9%)3.22 (3.8%) -0.1% ( -6% -6%) 0.909 TermTitleSort 63.89 (6.2%) 63.85 (6.8%) -0.1% ( -12% - 13%) 0.977 OrHighHigh 25.06 (2.4%) 25.05 (2.3%) -0.0% ( -4% -4%) 0.964 OrStopWords9.83 (6.1%)9.84 (5.6%)0.1% ( -11% - 12%) 0.969 CountOrHighHigh 62.03 (2.2%) 62.08 (2.3%)0.1% ( -4% -4%) 0.907 CountOrHighMed 93.40 (2.4%) 93.54 (2.5%)0.2% ( -4% -5%) 0.845 DismaxOrHighMed 63.11 (2.0%) 63.21 (2.7%)0.2% ( -4% -4%) 0.820 Fuzzy1 49.35 (3.2%) 49.43 (3.9%)0.2% ( -6% -7%) 0.881 CountFilteredOrMany5.94 (2.3%)5.95 (2.4%)0.2% ( -4% -4%) 0.799 SpanNear3.05 (4.8%)3.06 (4.7%)0.2% ( -8% - 10%) 0.896 DismaxOrHighHigh 44.54 (2.8%) 44.64 (2.5%)0.2% ( -4% -5%) 0.794 Term1M 564.76 (3.8%) 566.06 (3.2%)0.2% ( -6% -7%) 0.835 OrHighMed 86.90 (2.3%) 87.10 (2.2%)0.2% ( -4% -4%) 0.743 CountFilteredOrHighHigh 24.82 (1.4%) 24.88 (1.2%)0.2% ( -2% -2%) 0.549 Term 564.57 (3.8%) 566.04 (3.2%)0.3% ( -6% -7%) 0.816 AndHighMed 66.11 (1.5%) 66.28 (1.6%)0
Re: [PR] Build refactoring and cleanups (moving from build scripts to convention plugins) [lucene]
uschindler commented on PR #14764: URL: https://github.com/apache/lucene/pull/14764#issuecomment-2973613662 > * `runtime.java.home` is a build option now but the support for > `RUNTIME_JAVA_HOME` env. variable has been implemented for backward > compatibility. Please keep this for longer time, as the Jenkins build randomization can only work on environment variables. There maybe tweaks to pass this on command line in Jenkins's gradle options, but I don't want to touch that now. In addition I have this locally with my shell customization. To test other Java versions, I can quickly open a shell window with all environment variables including RUNTIME_JAVA_HOME. Loosing that is a big desaster to me! Uwe -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Fix usage of deprecated Gradle APIs scheduled to be removed in Gradle 9.0 [lucene]
breskeby commented on PR #14781: URL: https://github.com/apache/lucene/pull/14781#issuecomment-2973619493 > Right... This is among those things I mentioned that I don't understand - perhaps there are benefits to configuration caching or other advanced features... but overall it's a lot more boilerplate for something that is conceptually dead simple and that should remain simple. Eh. One problem that gradle is suffering from is, all the freedom it had given in the (groovy) DSL implementation in its early days. which makes it hard to move forward with making substantial progress on optimizing the gradle configuration phase. In this example just everything was kind of slammed into the project object (type Project) which is mutable by contract which makes optimizations way harder. Since ~2 major releases, Gradle keeps slowly deprecating and cutting back on this. Furthermore some of this "magic" like the way Conventions had been implemented back then makes IDE support way harder. Currently almost all of the build logic is jammed into the gradle files. The approach Gradle recommends usually is to keep convention plugins and build scripts small and only contain conventions and a few configurations and keep more complex implementation logic in testable binary plugin and task implementation. "Weired" boilerplate like the "InjectedExec" class I added as part of this PR I consider workarounds to achieve stuff in in build scripts that should probably better live in this binary (plain java?) implementation. There the boilerplate is usually minimal and not as bad as when staying with gradle files only. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
