[jira] [Commented] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[
https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462096#comment-17462096
]
ASF subversion and git services commented on LUCENE-10327:
--
Commit 5512786dd9679fd3322850fcda63795be8f2c21d in lucene's branch
refs/heads/main from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=5512786 ]
LUCENE-10327: workaround for gradle emitting empty sourcepath.
> gradle emits an empty sourcepath for forked javac and breaks compilation
>
>
> Key: LUCENE-10327
> URL: https://issues.apache.org/jira/browse/LUCENE-10327
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Blocker
>
> {code}
> gradlew -p lucene/core compileJava -Pruntime.java.home=...
> cat lucene/core/build/tmp/compileJava/java-compiler-args.txt
> ...
> -sourcepath
> ""
> ...
> {code}
> We have to get rid of sourcepath here. I don't know how. Looks like a gradle
> bug - it would work with gradle's "module support" enabled because I see
> switches in the code that set the sourcepath correctly but doesn't work
> otherwise.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[
https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-10327.
--
Resolution: Staged
The workaround on jms2 seems to work.
> gradle emits an empty sourcepath for forked javac and breaks compilation
>
>
> Key: LUCENE-10327
> URL: https://issues.apache.org/jira/browse/LUCENE-10327
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Blocker
>
> {code}
> gradlew -p lucene/core compileJava -Pruntime.java.home=...
> cat lucene/core/build/tmp/compileJava/java-compiler-args.txt
> ...
> -sourcepath
> ""
> ...
> {code}
> We have to get rid of sourcepath here. I don't know how. Looks like a gradle
> bug - it would work with gradle's "module support" enabled because I see
> switches in the code that set the sourcepath correctly but doesn't work
> otherwise.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dsmiley commented on a change in pull request #412: LUCENE-10197: UnifiedHighlighter should use builders for thread-safety
dsmiley commented on a change in pull request #412:
URL: https://github.com/apache/lucene/pull/412#discussion_r771899727
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
##
@@ -383,6 +564,15 @@ public UnifiedHighlighter(Builder builder) {
}
}
+ /** Returns the {@link HighlightFlag}s applicable for the current UH
instance. */
+ protected Set getFlags(String field) {
+if (initByBuilder) {
Review comment:
instead of having `initByBuilder`, can we just have a null-able flags
field that can only be non-null if the builder was used?
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
##
@@ -97,6 +97,23 @@
public static final int DEFAULT_CACHE_CHARS_THRESHOLD = 524288; // ~ 1 MB (2
byte chars)
+ public static final boolean DEFAULT_ENABLE_MULTI_TERM_QUERY = true;
Review comment:
Let's make these private so that we needn't keep them longer term. They
are only useful for this period of time in which we have both a setter &
builder. A little comment here stating this would be useful so we know to
remove them eventually.
##
File path:
lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
##
@@ -360,14 +451,104 @@ public UnifiedHighlighter(Builder builder) {
Objects.requireNonNull(
builder.indexAnalyzer,
"indexAnalyzer is required (even if in some circumstances it isn't
used)");
-this.flags = builder.evaluateFlags();
+this.flags = evaluateFlags(builder);
this.maxLength = builder.maxLength;
this.breakIterator = builder.breakIterator;
this.fieldMatcher = builder.fieldMatcher;
this.scorer = builder.scorer;
this.formatter = builder.formatter;
this.maxNoHighlightPassages = builder.maxNoHighlightPassages;
this.cacheFieldValCharsThreshold = builder.cacheFieldValCharsThreshold;
+this.initByBuilder = true;
+ }
+
+ /** Extracts matching terms after rewriting against an empty index */
+ protected static Set extractTerms(Query query) throws IOException {
+Set queryTerms = new HashSet<>();
+
EMPTY_INDEXSEARCHER.rewrite(query).visit(QueryVisitor.termCollector(queryTerms));
+return queryTerms;
+ }
+
+ /**
+ * This method returns the set of of {@link HighlightFlag}s, which will be
applied to the UH
+ * object. The output depends on the values provided to {@link
+ * Builder#withHandleMultiTermQuery(boolean)}, {@link
+ * Builder#withHighlightPhrasesStrictly(boolean)}, {@link
+ * Builder#withPassageRelevancyOverSpeed(boolean)} and {@link
Builder#withWeightMatches(boolean)}
+ * OR {@link #setHandleMultiTermQuery(boolean)}, {@link
#setHighlightPhrasesStrictly(boolean)},
+ * {@link #setPassageRelevancyOverSpeed(boolean)} and {@link
#setWeightMatches(boolean)}
+ *
+ * @param shouldHandleMultiTermQuery - flag for adding Multi-term query
+ * @param shouldHighlightPhrasesStrictly - flag for adding phrase
highlighting
+ * @param shouldPassageRelevancyOverSpeed - flag for adding passage relevancy
+ * @param shouldEnableWeightMatches - flag for enabling weight matches
+ * @return a set of {@link HighlightFlag}s.
+ */
+ protected Set evaluateFlags(
+ final boolean shouldHandleMultiTermQuery,
+ final boolean shouldHighlightPhrasesStrictly,
+ final boolean shouldPassageRelevancyOverSpeed,
+ final boolean shouldEnableWeightMatches) {
+Set highlightFlags = EnumSet.noneOf(HighlightFlag.class);
+if (shouldHandleMultiTermQuery) {
+ highlightFlags.add(HighlightFlag.MULTI_TERM_QUERY);
+}
+if (shouldHighlightPhrasesStrictly) {
+ highlightFlags.add(HighlightFlag.PHRASES);
+}
+if (shouldPassageRelevancyOverSpeed) {
+ highlightFlags.add(HighlightFlag.PASSAGE_RELEVANCY_OVER_SPEED);
+}
+
+// Evaluate if WEIGHT_MATCHES can be added as a flag.
+final boolean applyWeightMatches =
+highlightFlags.contains(HighlightFlag.MULTI_TERM_QUERY)
+&& highlightFlags.contains(HighlightFlag.PHRASES)
+&&
highlightFlags.contains(HighlightFlag.PASSAGE_RELEVANCY_OVER_SPEED)
+// User can also opt-out of WEIGHT_MATCHES.
+&& shouldEnableWeightMatches;
+
+if (applyWeightMatches) {
+ highlightFlags.add(HighlightFlag.WEIGHT_MATCHES);
+}
+return highlightFlags;
+ }
+
+ /**
+ * Evaluate the highlight flags and set the {@link #flags} variable. This is
called only once when
+ * the Builder object is used to create a UH object.
+ *
+ * @param uhBuilder - {@link Builder} object.
+ * @return {@link HighlightFlag}s.
+ */
+ protected Set evaluateFlags(Builder uhBuilder) {
+if (Objects.nonNull(flags)) {
Review comment:
Objects.nonNull is useful when needing to reference as a lambda but
otherwise is an awkward way to simply say != null
--
This is an
[jira] [Commented] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[
https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462025#comment-17462025
]
Dawid Weiss commented on LUCENE-10327:
--
It's this thing:
https://github.com/gradle/gradle/blob/master/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java#L239-L245
I think it may be possible to just provide javac with a valid source path
pointing at the top of the sourceset. Or with a fake module path so that gradle
doesn't add its own. I'll retry tomorrow.
> gradle emits an empty sourcepath for forked javac and breaks compilation
>
>
> Key: LUCENE-10327
> URL: https://issues.apache.org/jira/browse/LUCENE-10327
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Blocker
>
> {code}
> gradlew -p lucene/core compileJava -Pruntime.java.home=...
> cat lucene/core/build/tmp/compileJava/java-compiler-args.txt
> ...
> -sourcepath
> ""
> ...
> {code}
> We have to get rid of sourcepath here. I don't know how. Looks like a gradle
> bug - it would work with gradle's "module support" enabled because I see
> switches in the code that set the sourcepath correctly but doesn't work
> otherwise.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[
https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-10327:
-
Description:
{code}
gradlew -p lucene/core compileJava -Pruntime.java.home=...
cat lucene/core/build/tmp/compileJava/java-compiler-args.txt
...
-sourcepath
""
...
{code}
We have to get rid of sourcepath here. I don't know how. Looks like a gradle
bug - it would work with gradle's "module support" enabled because I see
switches in the code that set the sourcepath correctly but doesn't work
otherwise.
was:
{code}
gradlew -p lucene/core compileJava -Pruntime.java.home=...
{code}
> gradle emits an empty sourcepath for forked javac and breaks compilation
>
>
> Key: LUCENE-10327
> URL: https://issues.apache.org/jira/browse/LUCENE-10327
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Blocker
>
> {code}
> gradlew -p lucene/core compileJava -Pruntime.java.home=...
> cat lucene/core/build/tmp/compileJava/java-compiler-args.txt
> ...
> -sourcepath
> ""
> ...
> {code}
> We have to get rid of sourcepath here. I don't know how. Looks like a gradle
> bug - it would work with gradle's "module support" enabled because I see
> switches in the code that set the sourcepath correctly but doesn't work
> otherwise.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[
https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-10327:
-
Description:
{code}
gradlew -p lucene/core compileJava -Pruntime.java.home=...
{code}
> gradle emits an empty sourcepath for forked javac and breaks compilation
>
>
> Key: LUCENE-10327
> URL: https://issues.apache.org/jira/browse/LUCENE-10327
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Blocker
>
> {code}
> gradlew -p lucene/core compileJava -Pruntime.java.home=...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
[ https://issues.apache.org/jira/browse/LUCENE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-10327: - Priority: Blocker (was: Major) > gradle emits an empty sourcepath for forked javac and breaks compilation > > > Key: LUCENE-10327 > URL: https://issues.apache.org/jira/browse/LUCENE-10327 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-10327) gradle emits an empty sourcepath for forked javac and breaks compilation
Dawid Weiss created LUCENE-10327: Summary: gradle emits an empty sourcepath for forked javac and breaks compilation Key: LUCENE-10327 URL: https://issues.apache.org/jira/browse/LUCENE-10327 Project: Lucene - Core Issue Type: Sub-task Reporter: Dawid Weiss -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8930) Integrate Luke app health check to nightly tests (CI)
[ https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461997#comment-17461997 ] Dawid Weiss commented on LUCENE-8930: - I added a rough sketch of a more realistic test for distribution scripts - https://github.com/apache/lucene/pull/550/files this actually runs Luke and simulates odd paths occasionally (with a space inside). I didn't check the Unix script but a change is required to pass arguments to Luke. The Windows script requires a subtle change too since we have to run integration tests with blocking/ exit code. It's a draft, but should give you an idea of what this can look like. > Integrate Luke app health check to nightly tests (CI) > - > > Key: LUCENE-8930 > URL: https://issues.apache.org/jira/browse/LUCENE-8930 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Minor > > Would it be possible to add some release smoke tests for Luke? > https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] apanimesh061 commented on pull request #412: LUCENE-10197: UnifiedHighlighter should use builders for thread-safety
apanimesh061 commented on pull request #412: URL: https://github.com/apache/lucene/pull/412#issuecomment-997280739 @dsmiley I've made an attempt at making this back-portable as suggested. - `@Deprecated` the setters and constructor - Have not added any tests for the non-builder case - Existing tests are working -- 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
[jira] [Commented] (LUCENE-10308) Make ecj and javadoc run with modular paths
[ https://issues.apache.org/jira/browse/LUCENE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461975#comment-17461975 ] ASF subversion and git services commented on LUCENE-10308: -- Commit 2a44ff532ee715349523355eda97bd1ed589d11f in lucene's branch refs/heads/main from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=2a44ff5 ] LUCENE-10308: sort input files for ecj so that module-info.java comes first. > Make ecj and javadoc run with modular paths > --- > > Key: LUCENE-10308 > URL: https://issues.apache.org/jira/browse/LUCENE-10308 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: repro.zip > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10308) Make ecj and javadoc run with modular paths
[ https://issues.apache.org/jira/browse/LUCENE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461976#comment-17461976 ] ASF subversion and git services commented on LUCENE-10308: -- Commit 1114cf2c2505b6417729d3dea2847650fa9557d3 in lucene's branch refs/heads/branch_9x from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=1114cf2 ] LUCENE-10308: sort input files for ecj so that module-info.java comes first. > Make ecj and javadoc run with modular paths > --- > > Key: LUCENE-10308 > URL: https://issues.apache.org/jira/browse/LUCENE-10308 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: repro.zip > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-10308) Make ecj and javadoc run with modular paths
[ https://issues.apache.org/jira/browse/LUCENE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-10308. -- Resolution: Fixed I sorted all source files for ecj so that their order is predictable and a side-effect of this is module-info comes as first. > Make ecj and javadoc run with modular paths > --- > > Key: LUCENE-10308 > URL: https://issues.apache.org/jira/browse/LUCENE-10308 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: repro.zip > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-10308) Make ecj and javadoc run with modular paths
[ https://issues.apache.org/jira/browse/LUCENE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss reopened LUCENE-10308: -- We're hitting this one on jenkins: https://bugs.eclipse.org/bugs/show_bug.cgi?id=569833 > Make ecj and javadoc run with modular paths > --- > > Key: LUCENE-10308 > URL: https://issues.apache.org/jira/browse/LUCENE-10308 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: repro.zip > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8930) Integrate Luke app health check to nightly tests (CI)
[ https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461973#comment-17461973 ] Dawid Weiss commented on LUCENE-8930: - Hi Tomoko. Let me add a scaffolding for such a test I already have elsewhere - maybe it'll be helpful as a starter. > Integrate Luke app health check to nightly tests (CI) > - > > Key: LUCENE-8930 > URL: https://issues.apache.org/jira/browse/LUCENE-8930 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Minor > > Would it be possible to add some release smoke tests for Luke? > https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10255) Fully embrace the java module system
[ https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461972#comment-17461972 ] ASF subversion and git services commented on LUCENE-10255: -- Commit 7e1f3fef699376cc6069a31a5498670080741e98 in lucene's branch refs/heads/branch_9x from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=7e1f3fe ] LUCENE-10255: add unsynced providers to the module. > Fully embrace the java module system > > > Key: LUCENE-10255 > URL: https://issues.apache.org/jira/browse/LUCENE-10255 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 36h 10m > Remaining Estimate: 0h > > I've experimented a bit trying to move the code to the JMS. It is > _surprisingly difficult_... A PoC that almost passes all checks is here: > -https://github.com/dweiss/lucene/tree/jms- > https://github.com/dweiss/lucene/tree/jms2 > Here are my conclusions so far: > * The JMS and gradle add a lot of complexity (this applies to any > higher-level tooling, including IDEs, I think). For starters, -modules have > to be JARs. The effect of this is that what was previously a set of > directories from dependencies now has to be a JAR. What was previously an > incremental update of a single .class file now ripples throughout the build > recreating module JARs (ZIPs!)... I didn't realize it at first, but it's a > costly thing to do. I'm not even sure how IDEs handle this issue.- (not true) > * A Java module contains metadata (such as the module version or main class) > that is completely detached from any source file. These things live in a > class bytecode of the compiled module-info; interestingly, there is no > source-level way to specify it - these class attributes are injected by the > 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that > injects it. > * Dependencies between modules will effectively live in two places: in gradle > build files and in module-info files. -And they can go out of sync, although > it's probably easy to catch (since javac would complain about missing classes > during compilation, even if they're in module path).- (with separate module > and classpath configurations there is a possibility to verify the > consistency). > * Probably the biggest challenge (not covered in the PoC) are with our custom > javadoc and ecj linter tasks - they see the module-info.java and can't cope > with it. At the same time, there is no easy way to exclude that one > particular file: ecj would have to accept a full set of sources (command > argument limit will be a problem), javac can accept a full set of java > sources (external file) but then it doesn't copy doc-files properly anymore > (this is probably easier to fix). > * There are differences at runtime that are hard to anticipate - for example > resource lookups via class loader no longer work (I fixed this in Luke). > * We will have to rethink the long-term strategy of how white-box tests work. > There are some guidelines here but all of them have some cons (IDEs being > confused). > https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular > * it's pretty much impossible to exclude transitive dependencies from modules > we depend on - if they're not compile-time only (static) requirements, they > will have to be present on module path. > * supporting modules may or may not work in your IDE. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10255) Fully embrace the java module system
[ https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461970#comment-17461970 ] ASF subversion and git services commented on LUCENE-10255: -- Commit c1c27d4ff409ee514f1681207c2fec0dacd54c3c in lucene's branch refs/heads/branch_9x from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=c1c27d4 ] LUCENE-10255: initial support for Java Modules (squashed). > Fully embrace the java module system > > > Key: LUCENE-10255 > URL: https://issues.apache.org/jira/browse/LUCENE-10255 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 36h 10m > Remaining Estimate: 0h > > I've experimented a bit trying to move the code to the JMS. It is > _surprisingly difficult_... A PoC that almost passes all checks is here: > -https://github.com/dweiss/lucene/tree/jms- > https://github.com/dweiss/lucene/tree/jms2 > Here are my conclusions so far: > * The JMS and gradle add a lot of complexity (this applies to any > higher-level tooling, including IDEs, I think). For starters, -modules have > to be JARs. The effect of this is that what was previously a set of > directories from dependencies now has to be a JAR. What was previously an > incremental update of a single .class file now ripples throughout the build > recreating module JARs (ZIPs!)... I didn't realize it at first, but it's a > costly thing to do. I'm not even sure how IDEs handle this issue.- (not true) > * A Java module contains metadata (such as the module version or main class) > that is completely detached from any source file. These things live in a > class bytecode of the compiled module-info; interestingly, there is no > source-level way to specify it - these class attributes are injected by the > 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that > injects it. > * Dependencies between modules will effectively live in two places: in gradle > build files and in module-info files. -And they can go out of sync, although > it's probably easy to catch (since javac would complain about missing classes > during compilation, even if they're in module path).- (with separate module > and classpath configurations there is a possibility to verify the > consistency). > * Probably the biggest challenge (not covered in the PoC) are with our custom > javadoc and ecj linter tasks - they see the module-info.java and can't cope > with it. At the same time, there is no easy way to exclude that one > particular file: ecj would have to accept a full set of sources (command > argument limit will be a problem), javac can accept a full set of java > sources (external file) but then it doesn't copy doc-files properly anymore > (this is probably easier to fix). > * There are differences at runtime that are hard to anticipate - for example > resource lookups via class loader no longer work (I fixed this in Luke). > * We will have to rethink the long-term strategy of how white-box tests work. > There are some guidelines here but all of them have some cons (IDEs being > confused). > https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular > * it's pretty much impossible to exclude transitive dependencies from modules > we depend on - if they're not compile-time only (static) requirements, they > will have to be present on module path. > * supporting modules may or may not work in your IDE. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10255) Fully embrace the java module system
[ https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461967#comment-17461967 ] ASF subversion and git services commented on LUCENE-10255: -- Commit d42db56babfe1bb93a5f34b064bfa11056716812 in lucene's branch refs/heads/main from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=d42db56 ] LUCENE-10255: initial support for Java Modules. > Fully embrace the java module system > > > Key: LUCENE-10255 > URL: https://issues.apache.org/jira/browse/LUCENE-10255 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 36h > Remaining Estimate: 0h > > I've experimented a bit trying to move the code to the JMS. It is > _surprisingly difficult_... A PoC that almost passes all checks is here: > -https://github.com/dweiss/lucene/tree/jms- > https://github.com/dweiss/lucene/tree/jms2 > Here are my conclusions so far: > * The JMS and gradle add a lot of complexity (this applies to any > higher-level tooling, including IDEs, I think). For starters, -modules have > to be JARs. The effect of this is that what was previously a set of > directories from dependencies now has to be a JAR. What was previously an > incremental update of a single .class file now ripples throughout the build > recreating module JARs (ZIPs!)... I didn't realize it at first, but it's a > costly thing to do. I'm not even sure how IDEs handle this issue.- (not true) > * A Java module contains metadata (such as the module version or main class) > that is completely detached from any source file. These things live in a > class bytecode of the compiled module-info; interestingly, there is no > source-level way to specify it - these class attributes are injected by the > 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that > injects it. > * Dependencies between modules will effectively live in two places: in gradle > build files and in module-info files. -And they can go out of sync, although > it's probably easy to catch (since javac would complain about missing classes > during compilation, even if they're in module path).- (with separate module > and classpath configurations there is a possibility to verify the > consistency). > * Probably the biggest challenge (not covered in the PoC) are with our custom > javadoc and ecj linter tasks - they see the module-info.java and can't cope > with it. At the same time, there is no easy way to exclude that one > particular file: ecj would have to accept a full set of sources (command > argument limit will be a problem), javac can accept a full set of java > sources (external file) but then it doesn't copy doc-files properly anymore > (this is probably easier to fix). > * There are differences at runtime that are hard to anticipate - for example > resource lookups via class loader no longer work (I fixed this in Luke). > * We will have to rethink the long-term strategy of how white-box tests work. > There are some guidelines here but all of them have some cons (IDEs being > confused). > https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular > * it's pretty much impossible to exclude transitive dependencies from modules > we depend on - if they're not compile-time only (static) requirements, they > will have to be present on module path. > * supporting modules may or may not work in your IDE. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10255) Fully embrace the java module system
[ https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461966#comment-17461966 ] ASF subversion and git services commented on LUCENE-10255: -- Commit e0745c7b24b392f2657e207c45031238e2f5289a in lucene's branch refs/heads/main from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=e0745c7 ] LUCENE-10255: re-add utilities for debugging packages and services. These are not included by default to avoid unnecessary compilation overhead. > Fully embrace the java module system > > > Key: LUCENE-10255 > URL: https://issues.apache.org/jira/browse/LUCENE-10255 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 36h > Remaining Estimate: 0h > > I've experimented a bit trying to move the code to the JMS. It is > _surprisingly difficult_... A PoC that almost passes all checks is here: > -https://github.com/dweiss/lucene/tree/jms- > https://github.com/dweiss/lucene/tree/jms2 > Here are my conclusions so far: > * The JMS and gradle add a lot of complexity (this applies to any > higher-level tooling, including IDEs, I think). For starters, -modules have > to be JARs. The effect of this is that what was previously a set of > directories from dependencies now has to be a JAR. What was previously an > incremental update of a single .class file now ripples throughout the build > recreating module JARs (ZIPs!)... I didn't realize it at first, but it's a > costly thing to do. I'm not even sure how IDEs handle this issue.- (not true) > * A Java module contains metadata (such as the module version or main class) > that is completely detached from any source file. These things live in a > class bytecode of the compiled module-info; interestingly, there is no > source-level way to specify it - these class attributes are injected by the > 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that > injects it. > * Dependencies between modules will effectively live in two places: in gradle > build files and in module-info files. -And they can go out of sync, although > it's probably easy to catch (since javac would complain about missing classes > during compilation, even if they're in module path).- (with separate module > and classpath configurations there is a possibility to verify the > consistency). > * Probably the biggest challenge (not covered in the PoC) are with our custom > javadoc and ecj linter tasks - they see the module-info.java and can't cope > with it. At the same time, there is no easy way to exclude that one > particular file: ecj would have to accept a full set of sources (command > argument limit will be a problem), javac can accept a full set of java > sources (external file) but then it doesn't copy doc-files properly anymore > (this is probably easier to fix). > * There are differences at runtime that are hard to anticipate - for example > resource lookups via class loader no longer work (I fixed this in Luke). > * We will have to rethink the long-term strategy of how white-box tests work. > There are some guidelines here but all of them have some cons (IDEs being > confused). > https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular > * it's pretty much impossible to exclude transitive dependencies from modules > we depend on - if they're not compile-time only (static) requirements, they > will have to be present on module path. > * supporting modules may or may not work in your IDE. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-10308) Make ecj and javadoc run with modular paths
[ https://issues.apache.org/jira/browse/LUCENE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461965#comment-17461965 ] ASF subversion and git services commented on LUCENE-10308: -- Commit 5b3b75efd80e027bfbe9640b4cde5bd77360c513 in lucene's branch refs/heads/main from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene.git;h=5b3b75e ] LUCENE-10308: Make ecj and javadoc run with modular paths > Make ecj and javadoc run with modular paths > --- > > Key: LUCENE-10308 > URL: https://issues.apache.org/jira/browse/LUCENE-10308 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: repro.zip > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] dweiss merged pull request #533: LUCENE-10255: cleaned up module system support and other sub-issues
dweiss merged pull request #533: URL: https://github.com/apache/lucene/pull/533 -- 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
[jira] [Closed] (LUCENE-9360) might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed LUCENE-9360.
> might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
> --
>
> Key: LUCENE-9360
> URL: https://issues.apache.org/jira/browse/LUCENE-9360
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Currently {{ToParentDocvalues.advanceExact()}} propagates it to
> {{DocValues.advance()}} as advised at LUCENE-7871. It causes some problem at
> LUCENE-9328 and seems not really reasonable. The later jira has patch
> attached which resolves this. The questions is why(not)?
> cc [~jpountz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9360) might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
[
https://issues.apache.org/jira/browse/LUCENE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved LUCENE-9360.
--
Resolution: Won't Fix
will be addressed under enclosing issue
> might be NEEDED. ToParentDocValues uses advanceExact() of underneath DocValues
> --
>
> Key: LUCENE-9360
> URL: https://issues.apache.org/jira/browse/LUCENE-9360
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Currently {{ToParentDocvalues.advanceExact()}} propagates it to
> {{DocValues.advance()}} as advised at LUCENE-7871. It causes some problem at
> LUCENE-9328 and seems not really reasonable. The later jira has patch
> attached which resolves this. The questions is why(not)?
> cc [~jpountz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Closed] (LUCENE-9357) AssertingSorted(Set|Numeric)DocValues should be unwrappable
[
https://issues.apache.org/jira/browse/LUCENE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed LUCENE-9357.
> AssertingSorted(Set|Numeric)DocValues should be unwrappable
> ---
>
> Key: LUCENE-9357
> URL: https://issues.apache.org/jira/browse/LUCENE-9357
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/test-framework
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> # Obviously singular docValues might mimic multivalued ones via
> {{DocValues.singleton()}}. However, some algorithms prefers to
> {{DocValues.unwrap()}} them if possible.
> # AssertingDocValues blocks this unwrapping slightly changing codepath for
> singular DVs.
> h3. AS IS
> {{AssertingDV -> Singleton -> SingularDV}}
> h3. TODO
> {{Singleton -> AssertingDV -> SingularDV}}
> I think it's trivial, worthwhile and 0% risk. Are there any concerns?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9357) AssertingSorted(Set|Numeric)DocValues should be unwrappable
[
https://issues.apache.org/jira/browse/LUCENE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved LUCENE-9357.
--
Resolution: Won't Fix
will be addressed in enclosing issue
> AssertingSorted(Set|Numeric)DocValues should be unwrappable
> ---
>
> Key: LUCENE-9357
> URL: https://issues.apache.org/jira/browse/LUCENE-9357
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/test-framework
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> # Obviously singular docValues might mimic multivalued ones via
> {{DocValues.singleton()}}. However, some algorithms prefers to
> {{DocValues.unwrap()}} them if possible.
> # AssertingDocValues blocks this unwrapping slightly changing codepath for
> singular DVs.
> h3. AS IS
> {{AssertingDV -> Singleton -> SingularDV}}
> h3. TODO
> {{Singleton -> AssertingDV -> SingularDV}}
> I think it's trivial, worthwhile and 0% risk. Are there any concerns?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] msokolov commented on pull request #416: LUCENE-10054 Make HnswGraph hierarchical
msokolov commented on pull request #416: URL: https://github.com/apache/lucene/pull/416#issuecomment-997209709 @mayya-sharipova I don't have strong feelings about the file structure; either way seems OK to me. I guess if pressed I would probably choose to keep a smaller number of files since it will reduce the amount of managing/opening/closing files, and the directory will be less cluttered (most of the formats have one or two files?). I don't see any particular downside to having different kinds of information in a file, although then I guess the file parsing code can be a little more complicated, so it's a tradeoff without a clear deciding factor for me? -- 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
[GitHub] [lucene-solr] uschindler commented on pull request #2631: SOLR-15843 Upgrade log4j from 2.15 to 2.16
uschindler commented on pull request #2631: URL: https://github.com/apache/lucene-solr/pull/2631#issuecomment-997208157 > Thank you for the fix. We need now a fix for 2.17.0 https://search.maven.org/search?q=g:org.apache.logging.log4j%20AND%20a:log4j-core Also, please a new solr-core@8.11.2 > > https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.0 Hi, Solr is not affected by this vulnerability, so no urgent release needed. We will update it on the next regular release. See Solr security page: https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 -- 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
[GitHub] [lucene-solr] mkurde edited a comment on pull request #2631: SOLR-15843 Upgrade log4j from 2.15 to 2.16
mkurde edited a comment on pull request #2631: URL: https://github.com/apache/lucene-solr/pull/2631#issuecomment-997206959 Thank you for the fix. We need now a fix for 2.17.0 https://search.maven.org/search?q=g:org.apache.logging.log4j%20AND%20a:log4j-core Also, please a new solr-core@8.11.2 https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.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
[GitHub] [lucene-solr] mkurde edited a comment on pull request #2631: SOLR-15843 Upgrade log4j from 2.15 to 2.16
mkurde edited a comment on pull request #2631: URL: https://github.com/apache/lucene-solr/pull/2631#issuecomment-997206959 We need now a fix for 2.17.0 https://search.maven.org/search?q=g:org.apache.logging.log4j%20AND%20a:log4j-core Also, please a new solr-core@8.11.2 https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.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
[GitHub] [lucene-solr] mkurde commented on pull request #2631: SOLR-15843 Upgrade log4j from 2.15 to 2.16
mkurde commented on pull request #2631: URL: https://github.com/apache/lucene-solr/pull/2631#issuecomment-997206959 We need now a fix for 2.17.0 https://search.maven.org/search?q=g:org.apache.logging.log4j%20AND%20a:log4j-core Also, please a new solr-core@8.11.2 -- 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
[jira] [Commented] (LUCENE-8930) Integrate Luke app health check to nightly tests (CI)
[ https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461878#comment-17461878 ] Tomoko Uchida commented on LUCENE-8930: --- I think I can start this once [https://github.com/apache/lucene/pull/533] is merged. > Integrate Luke app health check to nightly tests (CI) > - > > Key: LUCENE-8930 > URL: https://issues.apache.org/jira/browse/LUCENE-8930 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Minor > > Would it be possible to add some release smoke tests for Luke? > https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-10319) Make ForUtil#BLOCK_SIZE changeable
[
https://issues.apache.org/jira/browse/LUCENE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Guo updated LUCENE-10319:
--
Description:
In LUCENE-10315, I tried to generate a {{ForUtil}} whose
{{{}BLOCK_SIZE=512{}}}, I thought it could be simple since it looks like i only
need to change the {{BLOCK_SIZE}}, but it turns out that there are a lot of
values related to the {{BLOCK_SIZE}} but hard coded.
So this approach is trying to make all hard code value related to BLOCK_SIZE to
be generated from the {{BLOCK_SIZE}} in case we need a different {{BLOCK_SIZE}}
{{ForUtil}} somewhere else or want to change {{BLOCK_SIZE}} in postings in
feature.
I tried to make the {{BLOCK_SIZE = 64 / 256}} and all tests passed.
was:
In LUCENE-10315, I tried to generate a {{ForUtil}} whose
{{{}BLOCK_SIZE=512{}}}, I thought it could be simple since it looks like i only
need to change the BLOCK_SIZE, but it turns out that there are a lot of values
related to the BLOCK_SIZE but hard coded.
So this is trying to make all hard code value generated from the BLOCK_SIZE in
case we need a ForUtil somewhere else or want to change BLOCK_SIZE in postings
in feature.
I tried to make the BLOCK_SIZE = 64 / 256 and all tests passed.
> Make ForUtil#BLOCK_SIZE changeable
> --
>
> Key: LUCENE-10319
> URL: https://issues.apache.org/jira/browse/LUCENE-10319
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Feng Guo
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In LUCENE-10315, I tried to generate a {{ForUtil}} whose
> {{{}BLOCK_SIZE=512{}}}, I thought it could be simple since it looks like i
> only need to change the {{BLOCK_SIZE}}, but it turns out that there are a lot
> of values related to the {{BLOCK_SIZE}} but hard coded.
> So this approach is trying to make all hard code value related to BLOCK_SIZE
> to be generated from the {{BLOCK_SIZE}} in case we need a different
> {{BLOCK_SIZE}} {{ForUtil}} somewhere else or want to change {{BLOCK_SIZE}} in
> postings in feature.
> I tried to make the {{BLOCK_SIZE = 64 / 256}} and all tests passed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8930) Integrate Luke app health check to nightly tests (CI)
[ https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461875#comment-17461875 ] Tomoko Uchida commented on LUCENE-8930: --- The launch script for Windows uses "javaw" to spawn the luke process; this makes it difficult to check the actual return code (%errorlevel%). I think we should change it to the plain "java" command. > Integrate Luke app health check to nightly tests (CI) > - > > Key: LUCENE-8930 > URL: https://issues.apache.org/jira/browse/LUCENE-8930 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Minor > > Would it be possible to add some release smoke tests for Luke? > https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8930) Integrate Luke app health check to nightly tests (CI)
[ https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-8930: -- Summary: Integrate Luke app health check to nightly tests (CI) (was: Add smoke tests for Luke) > Integrate Luke app health check to nightly tests (CI) > - > > Key: LUCENE-8930 > URL: https://issues.apache.org/jira/browse/LUCENE-8930 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/luke >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Minor > > Would it be possible to add some release smoke tests for Luke? > https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-8930) Add smoke tests for Luke
[
https://issues.apache.org/jira/browse/LUCENE-8930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida reopened LUCENE-8930:
---
I'd reopen this to allow to make sure that Luke app and its launch scripts are
not broken by any future changes.
A sanity check could be integrated into the nightly tests via the distribution
tests.
- Add "health check" or "test" mode to Luke's main class. For example, if
{{luke.runmode}} system property is set to "health", it would output some
status message to the stdout, and immediately exit with exit code 0.
- Add a command-line argument to Luke launch scripts (both for Unix-like and
Windows OS) to switch the running mode.
- Add a health check task that runs Luke in "health check" mode and checks its
status on the binary distribution to {{:lucene:distribution.test}} project
> Add smoke tests for Luke
>
>
> Key: LUCENE-8930
> URL: https://issues.apache.org/jira/browse/LUCENE-8930
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/luke
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
>
> Would it be possible to add some release smoke tests for Luke?
> https://stackoverflow.com/questions/79891/what-is-the-best-testing-tool-for-swing-based-applications
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene] mocobeta edited a comment on pull request #533: LUCENE-10255: cleaned up module system support and other sub-issues
mocobeta edited a comment on pull request #533: URL: https://github.com/apache/lucene/pull/533#issuecomment-997141676 I did some sanity checks on this branch. Looks everything is fine. https://gist.github.com/mocobeta/387585d846714aab86205ab92bc0beba I'm on IntelliJ IDEA - browsing and autocompletion work fine (as before) for me. -- 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
