[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059205#comment-17059205
]
Tomoko Uchida commented on LUCENE-9278:
---
The whole javadoc folder structure will be changed as bellow by modifications
here.
For lucene :
*Ant build*
{code:java}
https://lucene.apache.org/core/8_4_1/
├── analyzers-common
├── analyzers-icu
├── analyzers-kuromoji
├── analyzers-morfologik
├── analyzers-nori
├── analyzers-opennlp
├── analyzers-phonetic
├── analyzers-smartcn
├── analyzers-stempel
├── backward-codecs
├── benchmark
├── changes
├── classification
├── codecs
├── core
├── demo
├── expressions
├── facet
├── grouping
├── highlighter
├── join
├── luke
├── memory
├── misc
├── monitor
├── queries
├── queryparser
├── replicator
├── sandbox
├── spatial-extras
├── spatial3d
├── suggest
└── test-framework
{code}
*Gradle build*
{code:java}
https://lucene.apache.org/core/9_0_0/
├── analysis
│ ├── common
│ ├── icu
│ ├── kuromoji
│ ├── morfologik
│ ├── nori
│ ├── opennlp
│ ├── phonetic
│ ├── smartcn
│ └── stempel
├── backward-codecs
├── benchmark
├── classification
├── codecs
├── core
├── demo
├── expressions
├── facet
├── grouping
├── highlighter
├── join
├── luke
├── memory
├── misc
├── monitor
├── queries
├── queryparser
├── replicator
├── sandbox
├── spatial-extras
├── spatial3d
├── suggest
└── test-framework
{code}
For solr:
*Ant build*
{code:java}
https://lucene.apache.org/solr/8_4_1/
├── solr-analysis-extras
├── solr-analytics
├── solr-cell
├── solr-clustering
├── solr-core
├── solr-dataimporthandler
├── solr-dataimporthandler-extras
├── solr-jaegertracer-configurator
├── solr-langid
├── solr-ltr
├── solr-prometheus-exporter
├── solr-solrj
├── solr-test-framework
└── solr-velocity
{code}
*Gradle build*
{code:java}
https://lucene.apache.org/solr/9_0_0/
├── contrib
│ ├── analysis-extras
│ ├── analytics
│ ├── cell # or 'extraction'?
│ ├── clustering
│ ├── dataimporthandler
│ ├── dataimporthandler-extras
│ ├── extraction
│ ├── jaegertracer-configurator
│ ├── langid
│ ├── ltr
│ ├── prometheus-exporter
│ └── velocity
├── core
├── solrj
└── test-framework
{code}
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059206#comment-17059206 ] Tomoko Uchida commented on LUCENE-9278: --- Hi [~dweiss], could you take a look at this [https://github.com/apache/lucene-solr/pull/1352 ? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059206#comment-17059206 ] Tomoko Uchida edited comment on LUCENE-9278 at 3/14/20, 7:05 AM: - Hi [~dweiss], could you take a look at this [https://github.com/apache/lucene-solr/pull/1352] ? was (Author: tomoko uchida): Hi [~dweiss], could you take a look at this [https://github.com/apache/lucene-solr/pull/1352 ? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9077) Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059255#comment-17059255 ] Tomoko Uchida commented on LUCENE-9077: --- [ANN] Dawid Weiss and I are planning to change javadoc folder structure (hosted on lucene.apache.org site) according to gradle project structure, instead of ant. https://issues.apache.org/jira/browse/LUCENE-9278 Please leave comments if you have any concerns. > Gradle build > > > Key: LUCENE-9077 > URL: https://issues.apache.org/jira/browse/LUCENE-9077 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9077-javadoc-locale-en-US.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This task focuses on providing gradle-based build equivalent for Lucene and > Solr (on master branch). See notes below on why this respin is needed. > The code lives on *gradle-master* branch. It is kept with sync with *master*. > Try running the following to see an overview of helper guides concerning > typical workflow, testing and ant-migration helpers: > gradlew :help > A list of items that needs to be added or requires work. If you'd like to > work on any of these, please add your name to the list. Once you have a > patch/ pull request let me (dweiss) know - I'll try to coordinate the merges. > * (/) Apply forbiddenAPIs > * (/) Generate hardware-aware gradle defaults for parallelism (count of > workers and test JVMs). > * (/) Fail the build if --tests filter is applied and no tests execute > during the entire build (this allows for an empty set of filtered tests at > single project level). > * (/) Port other settings and randomizations from common-build.xml > * (/) Configure security policy/ sandboxing for tests. > * (/) test's console output on -Ptests.verbose=true > * (/) add a :helpDeps explanation to how the dependency system works > (palantir plugin, lockfile) and how to retrieve structured information about > current dependencies of a given module (in a tree-like output). > * (/) jar checksums, jar checksum computation and validation. This should be > done without intermediate folders (directly on dependency sets). > * (/) verify min. JVM version and exact gradle version on build startup to > minimize odd build side-effects > * (/) Repro-line for failed tests/ runs. > * (/) add a top-level README note about building with gradle (and the > required JVM). > * (/) add an equivalent of 'validate-source-patterns' > (check-source-patterns.groovy) to precommit. > * (/) add an equivalent of 'rat-sources' to precommit. > * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) > to precommit. > * (/) javadoc compilation > Hard-to-implement stuff already investigated: > * (/) (done) -*Printing console output of failed tests.* There doesn't seem > to be any way to do this in a reasonably efficient way. There are onOutput > listeners but they're slow to operate and solr tests emit *tons* of output so > it's an overkill.- > * (!) (LUCENE-9120) *Tests working with security-debug logs or other > JVM-early log output*. Gradle's test runner works by redirecting Java's > stdout/ syserr so this just won't work. Perhaps we can spin the ant-based > test runner for such corner-cases. > Of lesser importance: > * Add an equivalent of 'documentation-lint" to precommit. > * (/) Do not require files to be committed before running precommit. (staged > files are fine). > * (/) add rendering of javadocs (gradlew javadoc) > * Attach javadocs to maven publications. > * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid > it'll be difficult to run it sensibly because gradle doesn't offer cwd > separation for the forked test runners. > * if you diff solr packaged distribution against ant-created distribution > there are minor differences in library versions and some JARs are excluded/ > moved around. I didn't try to force these as everything seems to work (tests, > etc.) – perhaps these differences should be fixed in the ant build instead. > * (/) identify and port various "regenerate" tasks from ant builds (javacc, > precompiled automata, etc.) > * Fill in POM details in gradle/defaults-maven.gradle so that they reflect > the previous content better (dependencies aside). > * Add any IDE integration layers that should be added (I use IntelliJ and it > imports the project out of the box, without the need for any special tuning). > * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; > currently XSLT...) > * I didn't bother adding Solr dist/test-framework to packaging (who'd use it > from a binary distribution? > * There is some python executi
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392562835
##
File path: gradle/render-javadoc.gradle
##
@@ -294,35 +305,41 @@ configure(project(':solr:core')) {
plugins.withType(JavaPlugin) {
// specialized to ONLY depend on solrj
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- linkHref += [ '../solr-solrj' ]
+ [':solr:solrj'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../" + pathToDocdir(path) ]
+ }
}
}
}
configure(subprojects.findAll { it.path.startsWith(':solr:contrib') }) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- dependsOn ':solr:core:renderJavadoc'
- linkHref += [ '../solr-solrj', '../solr-core' ]
+ [':solr:solrj', ':solr:core'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
configure(project(':solr:contrib:dataimporthandler-extras')) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:contrib:dataimporthandler:renderJavadoc'
- linkHref += [ '../solr-dataimporthandler' ]
+ [':solr:contrib:dataimporthandler'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
+
configure(project(':solr:contrib:extraction')) {
plugins.withType(JavaPlugin) {
ext {
- javadocDestDir = "${javadocRoot}/solr-cell"
+ javadocDestDir = "${javadocRoot}/contrib/cell"
Review comment:
I'm not sure this tweak is needed for gradle build. Simply,
"docs/contrib/extraction" (same as other contrib modules) may be okay?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392568557
##
File path:
lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -608,22 +608,25 @@ public DoubleValues getValues(LeafReaderContext ctx,
DoubleValues scores) throws
return new DoubleValues() {
private final TwoPhaseIterator tpi = scorer.twoPhaseIterator();
private final DocIdSetIterator disi = (tpi == null) ?
scorer.iterator() : tpi.approximation();
-
-private int scorerDoc = -1;
-private boolean thisDocMatches = false;
+private Boolean thisDocMatches = false;
@Override
public double doubleValue() throws IOException {
- return thisDocMatches ? scorer.score() : Double.NaN;
+ return (thisDocMatches != null && thisDocMatches) ? scorer.score() :
Double.NaN;
}
@Override
public boolean advanceExact(int doc) throws IOException {
- if (scorerDoc < doc) {
-scorerDoc = disi.advance(doc);
-thisDocMatches = tpi==null || tpi.matches();
+ if (disi.docID() < doc) {
Review comment:
You mean something like the following?
```
assert disi.docID() < doc;
disi.advance(doc);
thisDocMatches = null;
if (disi.docID() == doc) {
[...]
```
The disi can advance potentially much further than the requested `doc`, and
that means that, for potentially many requested `doc`s afterwards
,`disi.docID() > doc` might hold. Tests fail for the edit above.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392568557
##
File path:
lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -608,22 +608,25 @@ public DoubleValues getValues(LeafReaderContext ctx,
DoubleValues scores) throws
return new DoubleValues() {
private final TwoPhaseIterator tpi = scorer.twoPhaseIterator();
private final DocIdSetIterator disi = (tpi == null) ?
scorer.iterator() : tpi.approximation();
-
-private int scorerDoc = -1;
-private boolean thisDocMatches = false;
+private Boolean thisDocMatches = false;
@Override
public double doubleValue() throws IOException {
- return thisDocMatches ? scorer.score() : Double.NaN;
+ return (thisDocMatches != null && thisDocMatches) ? scorer.score() :
Double.NaN;
}
@Override
public boolean advanceExact(int doc) throws IOException {
- if (scorerDoc < doc) {
-scorerDoc = disi.advance(doc);
-thisDocMatches = tpi==null || tpi.matches();
+ if (disi.docID() < doc) {
Review comment:
You mean something like the following?
```
public boolean advanceExact(int doc) throws IOException {
assert disi.docID() < doc;
disi.advance(doc);
thisDocMatches = null;
if (disi.docID() == doc) {
[...]
```
The disi can advance potentially much further than the requested `doc`, and
that means that, for potentially many requested `doc`s afterwards
,`disi.docID() > doc` might hold. Tests fail for the edit above.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392568557
##
File path:
lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -608,22 +608,25 @@ public DoubleValues getValues(LeafReaderContext ctx,
DoubleValues scores) throws
return new DoubleValues() {
private final TwoPhaseIterator tpi = scorer.twoPhaseIterator();
private final DocIdSetIterator disi = (tpi == null) ?
scorer.iterator() : tpi.approximation();
-
-private int scorerDoc = -1;
-private boolean thisDocMatches = false;
+private Boolean thisDocMatches = false;
@Override
public double doubleValue() throws IOException {
- return thisDocMatches ? scorer.score() : Double.NaN;
+ return (thisDocMatches != null && thisDocMatches) ? scorer.score() :
Double.NaN;
}
@Override
public boolean advanceExact(int doc) throws IOException {
- if (scorerDoc < doc) {
-scorerDoc = disi.advance(doc);
-thisDocMatches = tpi==null || tpi.matches();
+ if (disi.docID() < doc) {
Review comment:
You mean something like the following?
```
public boolean advanceExact(int doc) throws IOException {
assert disi.docID() < doc;
disi.advance(doc);
thisDocMatches = null;
if (disi.docID() == doc) {
[...]
```
The disi can advance potentially much further than the requested `doc`, and
that means that, for potentially many requested `doc`s afterwards
,`disi.docID() > doc` might hold. Tests fail for the edit above (on the
assertion specifically).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392568557
##
File path:
lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -608,22 +608,25 @@ public DoubleValues getValues(LeafReaderContext ctx,
DoubleValues scores) throws
return new DoubleValues() {
private final TwoPhaseIterator tpi = scorer.twoPhaseIterator();
private final DocIdSetIterator disi = (tpi == null) ?
scorer.iterator() : tpi.approximation();
-
-private int scorerDoc = -1;
-private boolean thisDocMatches = false;
+private Boolean thisDocMatches = false;
@Override
public double doubleValue() throws IOException {
- return thisDocMatches ? scorer.score() : Double.NaN;
+ return (thisDocMatches != null && thisDocMatches) ? scorer.score() :
Double.NaN;
}
@Override
public boolean advanceExact(int doc) throws IOException {
- if (scorerDoc < doc) {
-scorerDoc = disi.advance(doc);
-thisDocMatches = tpi==null || tpi.matches();
+ if (disi.docID() < doc) {
Review comment:
You mean something like the following?
```
public boolean advanceExact(int doc) throws IOException {
assert disi.docID() < doc;
disi.advance(doc);
thisDocMatches = null;
if (disi.docID() == doc) {
[...]
```
The disi can advance potentially much further than the requested `doc`, and
that means that, for potentially many requested `doc`s afterwards
,`disi.docID() > doc` might hold. Tests fail for the edit above (on that
assertion specifically).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392568691
##
File path: gradle/render-javadoc.gradle
##
@@ -17,11 +17,15 @@
// generate javadocs by using Ant javadoc task
+// utility function to convert project path to document output dir
+// e.g.: ':lucene:analysis:common' => 'analysis/common'
+def pathToDocdir = { path -> path.split(':').drop(2).join('/') }
Review comment:
This seems fine to 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392568764
##
File path: gradle/render-javadoc.gradle
##
@@ -294,35 +305,41 @@ configure(project(':solr:core')) {
plugins.withType(JavaPlugin) {
// specialized to ONLY depend on solrj
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- linkHref += [ '../solr-solrj' ]
+ [':solr:solrj'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../" + pathToDocdir(path) ]
+ }
}
}
}
configure(subprojects.findAll { it.path.startsWith(':solr:contrib') }) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- dependsOn ':solr:core:renderJavadoc'
- linkHref += [ '../solr-solrj', '../solr-core' ]
+ [':solr:solrj', ':solr:core'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
configure(project(':solr:contrib:dataimporthandler-extras')) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:contrib:dataimporthandler:renderJavadoc'
- linkHref += [ '../solr-dataimporthandler' ]
+ [':solr:contrib:dataimporthandler'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
+
configure(project(':solr:contrib:extraction')) {
plugins.withType(JavaPlugin) {
ext {
- javadocDestDir = "${javadocRoot}/solr-cell"
+ javadocDestDir = "${javadocRoot}/contrib/cell"
Review comment:
The "solr-cell" is what it's called in ant. I'm not sure why. I would prefer
to stick to folder/ project path naming here too (so contrib/extraction 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
dweiss commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392568830
##
File path: gradle/render-javadoc.gradle
##
@@ -17,11 +17,15 @@
// generate javadocs by using Ant javadoc task
+// utility function to convert project path to document output dir
+// e.g.: ':lucene:analysis:common' => 'analysis/common'
+def pathToDocdir = { path -> path.split(':').drop(2).join('/') }
+
allprojects {
plugins.withType(JavaPlugin) {
ext {
javadocRoot = project.path.startsWith(':lucene') ?
project(':lucene').file("build/docs") : project(':solr').file("build/docs")
- javadocDestDir = "${javadocRoot}/${project.name}"
+ javadocDestDir = "${javadocRoot}/" + pathToDocdir(project.path)
Review comment:
You can call the function inside the evaluated string too;
"${javadocRoot}/${pathToDocDir(project.path)}"
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392569098
##
File path:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java
##
@@ -156,42 +135,38 @@ public float floatVal(int doc) {
@Override
public boolean exists(int doc) {
try {
- if (doc < lastDocRequested) {
-if (noMatches) return false;
+ if (noMatches) return false;
+ if (scorer == null) {
scorer = weight.scorer(readerContext);
-scorerDoc = -1;
-if (scorer==null) {
+if (scorer == null) {
noMatches = true;
return false;
}
-it = scorer.iterator();
+tpi = scorer.twoPhaseIterator();
+disi = tpi==null ? scorer.iterator() : tpi.approximation();
+thisDocMatches = false;
Review comment:
The disi is positioned on -1, so definitely not a match, no?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on a change in pull request #1343: LUCENE-8103: Use
two-phase iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392569092
##
File path:
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java
##
@@ -156,42 +135,38 @@ public float floatVal(int doc) {
@Override
public boolean exists(int doc) {
try {
- if (doc < lastDocRequested) {
-if (noMatches) return false;
+ if (noMatches) return false;
+ if (scorer == null) {
scorer = weight.scorer(readerContext);
-scorerDoc = -1;
-if (scorer==null) {
+if (scorer == null) {
noMatches = true;
return false;
}
-it = scorer.iterator();
+tpi = scorer.twoPhaseIterator();
+disi = tpi==null ? scorer.iterator() : tpi.approximation();
+thisDocMatches = false;
}
+ assert doc >= lastDocRequested : "values requested out of order; last="
+ lastDocRequested + ", requested=" + doc;
Review comment:
I also didn't think so until your last review, but I found the following on
the docstring for `ValueSource.getValues`:
> The values must be consumed in a forward docID manner, and you must call
this method again to iterate through the values again.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059274#comment-17059274 ] Dawid Weiss commented on LUCENE-9278: - Looks good to me, Tomoko. I'm not sure whether this can go in before we remove ant though. Which also begs the question how many things are still in ant that aren't ported yet (I admit I lost track here). Perhaps some re-evaluation would be needed at LUCENE-9077. These are anxious times we currently live in but perhaps we should start thinking about slowly retiring the ant build (in fragments or in whole)? > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] micpalmia commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
micpalmia commented on issue #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource URL: https://github.com/apache/lucene-solr/pull/1343#issuecomment-599032031 > No auto-boxing concerns for Boolean :-) thanks for the reassurance :) - do you mean the performance hit is too low to be of interest, or that there's no trouble with performances at all? Do you maybe have any references on this? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392571884
##
File path: gradle/render-javadoc.gradle
##
@@ -294,35 +305,41 @@ configure(project(':solr:core')) {
plugins.withType(JavaPlugin) {
// specialized to ONLY depend on solrj
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- linkHref += [ '../solr-solrj' ]
+ [':solr:solrj'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../" + pathToDocdir(path) ]
+ }
}
}
}
configure(subprojects.findAll { it.path.startsWith(':solr:contrib') }) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:solrj:renderJavadoc'
- dependsOn ':solr:core:renderJavadoc'
- linkHref += [ '../solr-solrj', '../solr-core' ]
+ [':solr:solrj', ':solr:core'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
configure(project(':solr:contrib:dataimporthandler-extras')) {
plugins.withType(JavaPlugin) {
renderJavadoc {
- dependsOn ':solr:contrib:dataimporthandler:renderJavadoc'
- linkHref += [ '../solr-dataimporthandler' ]
+ [':solr:contrib:dataimporthandler'].collect { path ->
+dependsOn "${path}:renderJavadoc"
+linkHref += [ "../../" + pathToDocdir(path) ]
+ }
}
}
}
+
configure(project(':solr:contrib:extraction')) {
plugins.withType(JavaPlugin) {
ext {
- javadocDestDir = "${javadocRoot}/solr-cell"
+ javadocDestDir = "${javadocRoot}/contrib/cell"
Review comment:
I removed the entire configure block, so now the docs will go to
`contrib/extraction`.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc folder structure follow Gradle project path
mocobeta commented on a change in pull request #1352: LUCENE-9278: Make javadoc
folder structure follow Gradle project path
URL: https://github.com/apache/lucene-solr/pull/1352#discussion_r392571898
##
File path: gradle/render-javadoc.gradle
##
@@ -17,11 +17,15 @@
// generate javadocs by using Ant javadoc task
+// utility function to convert project path to document output dir
+// e.g.: ':lucene:analysis:common' => 'analysis/common'
+def pathToDocdir = { path -> path.split(':').drop(2).join('/') }
+
allprojects {
plugins.withType(JavaPlugin) {
ext {
javadocRoot = project.path.startsWith(':lucene') ?
project(':lucene').file("build/docs") : project(':solr').file("build/docs")
- javadocDestDir = "${javadocRoot}/${project.name}"
+ javadocDestDir = "${javadocRoot}/" + pathToDocdir(project.path)
Review comment:
Fixed, thanks.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059295#comment-17059295
]
Tomoko Uchida commented on LUCENE-9278:
---
Currently the {{renderJavadoc}} task shares the output directories
{{lucene/build/docs}} and {{solr/build/docs}} with Ant {{documentation}} task,
it may be problematic while Ant and Gradle builds co-exist on the master. If we
move the output directory to {{_project_/build/docs/javadoc}} as suggested in
https://github.com/apache/lucene-solr/pull/1304 (this would be possible by
changing all relative paths to absolute urls), I think the work can be
continued without disturbing and build?
{quote}
Which also begs the question how many things are still in ant that aren't
ported yet (I admit I lost track here).
{quote}
I believe I have ported the entire ant documentation task, except for
{{solr-invoke-javadoc}} macro which makes the external links from Solr javadocs
to Lucene javadocs (that is marked as TODO in the render-javadoc.gradle file).
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059295#comment-17059295
]
Tomoko Uchida edited comment on LUCENE-9278 at 3/14/20, 10:12 AM:
--
Currently the {{renderJavadoc}} task shares the output directories
{{lucene/build/docs}} and {{solr/build/docs}} with Ant {{documentation}} task,
it may be problematic while Ant and Gradle builds co-exist on the master. If we
move the output directory to {{_project_/build/docs/javadoc}} as suggested in
https://github.com/apache/lucene-solr/pull/1304 (this would be possible by
changing all relative paths to absolute urls), I think the work can be
continued without disturbing ant build?
{quote}
Which also begs the question how many things are still in ant that aren't
ported yet (I admit I lost track here).
{quote}
I believe I have ported the entire ant documentation task, except for
{{solr-invoke-javadoc}} macro which makes the external links from Solr javadocs
to Lucene javadocs (that is marked as TODO in the render-javadoc.gradle file).
was (Author: tomoko uchida):
Currently the {{renderJavadoc}} task shares the output directories
{{lucene/build/docs}} and {{solr/build/docs}} with Ant {{documentation}} task,
it may be problematic while Ant and Gradle builds co-exist on the master. If we
move the output directory to {{_project_/build/docs/javadoc}} as suggested in
https://github.com/apache/lucene-solr/pull/1304 (this would be possible by
changing all relative paths to absolute urls), I think the work can be
continued without disturbing and build?
{quote}
Which also begs the question how many things are still in ant that aren't
ported yet (I admit I lost track here).
{quote}
I believe I have ported the entire ant documentation task, except for
{{solr-invoke-javadoc}} macro which makes the external links from Solr javadocs
to Lucene javadocs (that is marked as TODO in the render-javadoc.gradle file).
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059296#comment-17059296 ] Dawid Weiss commented on LUCENE-9278: - I'm for moving docs under project/* but please give others a bit of time to maybe express their opinion on this. Please feel free to modify that task as completed then, thank you! > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059312#comment-17059312
]
Robert Muir commented on LUCENE-9278:
-
{quote}
I'm not sure whether this can go in before we remove ant though. Which also
begs the question how many things are still in ant that aren't ported yet (I
admit I lost track here).
{quote}
Unfortunately it is more complicated. Even if 100% of features are implemented,
how can we do EA testing without ant? The problem is groovy, it is such a
terribly implemented language. It tries to disassemble JDK classes and fails if
its included version of ASM is too low. It does not need to do this, it does
this as an "optimization".
This is 100% a losing race because openjdk is unconditionally bumping the class
file version on every new version. So groovy (and gradle) is always out of
date. This is why you can't test jdk 14 or jdk 15 builds with gradle right now,
you must use ant.
Groovy needs to stop doing such bad stuff. At least if they are going to write
such bad code, they should catch the exception and fall back to using
reflection.
So I don't see an easy way to remove ant in the near future.
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059316#comment-17059316 ] Dawid Weiss commented on LUCENE-9278: - You can separate compilation/ test execution JVM from the JVM that runs the build itself. Yes, the build JVM has to lag behind the bleeding edge but you can run and test with EA versions. Otherwise all the effort of porting to gradle is kind of pointless, isn't it. I kept the gradle build ant-compatible but it's not really an attractive perspective to keep both build systems operational for a long stretch of time. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059318#comment-17059318 ] Dawid Weiss commented on LUCENE-9278: - For what it's worth, the VM for gradle can be set in local properties as well [1]: org.gradle.java.home=(path to JDK home) Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, using a JDK is safer. A reasonable default is derived from your environment (JAVA_HOME or the path to java) if the setting is unspecified. This does not affect the version of Java used to launch the Gradle client VM (see Environment variables). So I think you could even set it once in your user's ~/gradle.properties? [1] https://docs.gradle.org/current/userguide/build_environment.html > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0
[ https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Munendra S N reassigned SOLR-8306: -- Assignee: Munendra S N > Enhance ExpandComponent to allow expand.hits=0 > -- > > Key: SOLR-8306 > URL: https://issues.apache.org/jira/browse/SOLR-8306 > Project: Solr > Issue Type: Improvement >Affects Versions: 5.3.1 >Reporter: Marshall Sanders >Assignee: Munendra S N >Priority: Minor > Labels: expand > Fix For: 5.5 > > Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, > SOLR-8306_branch_5x@1715230.patch > > Time Spent: 20m > Remaining Estimate: 0h > > This enhancement allows the ExpandComponent to allow expand.hits=0 for those > who don't want an expanded document returned and only want the numFound from > the expand section. > This is useful for "See 54 more like this" use cases, but without the > performance hit of gathering an entire expanded document. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059295#comment-17059295
]
Tomoko Uchida edited comment on LUCENE-9278 at 3/14/20, 1:46 PM:
-
Currently the {{renderJavadoc}} task shares the output directories
{{lucene/build/docs}} and {{solr/build/docs}} with Ant {{documentation}} task,
it may be problematic while Ant and Gradle builds co-exist on the master. If we
move the output directory to {{_project_/build/docs/javadoc}} as suggested in
https://github.com/apache/lucene-solr/pull/1304 (this would be possible by
changing all relative paths to absolute urls), I think the work can be
continued without disturbing ant build?
{quote}
Which also begs the question how many things are still in ant that aren't
ported yet (I admit I lost track here).
{quote}
I believe I have ported the entire ant -documentation- javadoc task, except for
{{solr-invoke-javadoc}} macro which makes the external links from Solr javadocs
to Lucene javadocs (that is marked as TODO in the render-javadoc.gradle file).
was (Author: tomoko uchida):
Currently the {{renderJavadoc}} task shares the output directories
{{lucene/build/docs}} and {{solr/build/docs}} with Ant {{documentation}} task,
it may be problematic while Ant and Gradle builds co-exist on the master. If we
move the output directory to {{_project_/build/docs/javadoc}} as suggested in
https://github.com/apache/lucene-solr/pull/1304 (this would be possible by
changing all relative paths to absolute urls), I think the work can be
continued without disturbing ant build?
{quote}
Which also begs the question how many things are still in ant that aren't
ported yet (I admit I lost track here).
{quote}
I believe I have ported the entire ant documentation task, except for
{{solr-invoke-javadoc}} macro which makes the external links from Solr javadocs
to Lucene javadocs (that is marked as TODO in the render-javadoc.gradle file).
> Make javadoc folder structure follow Gradle project path
>
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
> [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path)
> instead of ant one, to keep things simple to manage [1]. Hence, it will look
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
> [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
URL: https://github.com/apache/lucene-solr/pull/1350#discussion_r392589684
##
File path:
lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThread.java
##
@@ -318,8 +301,10 @@ private long
finishDocuments(DocumentsWriterDeleteQueue.Node deleteNode, int
// Buffer a specific docID for deletion. Currently only
// used when we hit an exception when adding a document
- void deleteDocID(int docIDUpto) {
-pendingUpdates.addDocID(docIDUpto);
+ private void deleteLastDocs(int docCount) {
Review comment:
Can you update the javadocs (it's a bit stale).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
URL: https://github.com/apache/lucene-solr/pull/1350#discussion_r392589649
##
File path:
lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThread.java
##
@@ -249,34 +247,19 @@ public long updateDocuments(Iterable endDocID) {
-deleteDocID(docID);
-docID--;
- }
+ deleteLastDocs(numDocsInRAM-docsInRamBefore);
Review comment:
nit: add spaces around `-`
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
dnhatn commented on a change in pull request #1350: Cleanup DWPT for readability
URL: https://github.com/apache/lucene-solr/pull/1350#discussion_r392589684
##
File path:
lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThread.java
##
@@ -318,8 +301,10 @@ private long
finishDocuments(DocumentsWriterDeleteQueue.Node deleteNode, int
// Buffer a specific docID for deletion. Currently only
// used when we hit an exception when adding a document
- void deleteDocID(int docIDUpto) {
-pendingUpdates.addDocID(docIDUpto);
+ private void deleteLastDocs(int docCount) {
Review comment:
Can you update the javadocs (it's a bit stale: `a specific docID`).
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1343: LUCENE-8103: Use two-phase iteration in Query- and DoubleValuesSource
dsmiley commented on a change in pull request #1343: LUCENE-8103: Use two-phase
iteration in Query- and DoubleValuesSource
URL: https://github.com/apache/lucene-solr/pull/1343#discussion_r392594785
##
File path:
lucene/core/src/java/org/apache/lucene/search/DoubleValuesSource.java
##
@@ -608,22 +608,25 @@ public DoubleValues getValues(LeafReaderContext ctx,
DoubleValues scores) throws
return new DoubleValues() {
private final TwoPhaseIterator tpi = scorer.twoPhaseIterator();
private final DocIdSetIterator disi = (tpi == null) ?
scorer.iterator() : tpi.approximation();
-
-private int scorerDoc = -1;
-private boolean thisDocMatches = false;
+private Boolean thisDocMatches = false;
@Override
public double doubleValue() throws IOException {
- return thisDocMatches ? scorer.score() : Double.NaN;
+ return (thisDocMatches != null && thisDocMatches) ? scorer.score() :
Double.NaN;
}
@Override
public boolean advanceExact(int doc) throws IOException {
- if (scorerDoc < doc) {
-scorerDoc = disi.advance(doc);
-thisDocMatches = tpi==null || tpi.matches();
+ if (disi.docID() < doc) {
Review comment:
Doh! Of course; thanks.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9077) Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059397#comment-17059397 ] David Smiley commented on LUCENE-9077: -- Please send announcements directly to the dev list. Trying to do an announcement on JIRA will not get everyone’s attention. > Gradle build > > > Key: LUCENE-9077 > URL: https://issues.apache.org/jira/browse/LUCENE-9077 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9077-javadoc-locale-en-US.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This task focuses on providing gradle-based build equivalent for Lucene and > Solr (on master branch). See notes below on why this respin is needed. > The code lives on *gradle-master* branch. It is kept with sync with *master*. > Try running the following to see an overview of helper guides concerning > typical workflow, testing and ant-migration helpers: > gradlew :help > A list of items that needs to be added or requires work. If you'd like to > work on any of these, please add your name to the list. Once you have a > patch/ pull request let me (dweiss) know - I'll try to coordinate the merges. > * (/) Apply forbiddenAPIs > * (/) Generate hardware-aware gradle defaults for parallelism (count of > workers and test JVMs). > * (/) Fail the build if --tests filter is applied and no tests execute > during the entire build (this allows for an empty set of filtered tests at > single project level). > * (/) Port other settings and randomizations from common-build.xml > * (/) Configure security policy/ sandboxing for tests. > * (/) test's console output on -Ptests.verbose=true > * (/) add a :helpDeps explanation to how the dependency system works > (palantir plugin, lockfile) and how to retrieve structured information about > current dependencies of a given module (in a tree-like output). > * (/) jar checksums, jar checksum computation and validation. This should be > done without intermediate folders (directly on dependency sets). > * (/) verify min. JVM version and exact gradle version on build startup to > minimize odd build side-effects > * (/) Repro-line for failed tests/ runs. > * (/) add a top-level README note about building with gradle (and the > required JVM). > * (/) add an equivalent of 'validate-source-patterns' > (check-source-patterns.groovy) to precommit. > * (/) add an equivalent of 'rat-sources' to precommit. > * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) > to precommit. > * (/) javadoc compilation > Hard-to-implement stuff already investigated: > * (/) (done) -*Printing console output of failed tests.* There doesn't seem > to be any way to do this in a reasonably efficient way. There are onOutput > listeners but they're slow to operate and solr tests emit *tons* of output so > it's an overkill.- > * (!) (LUCENE-9120) *Tests working with security-debug logs or other > JVM-early log output*. Gradle's test runner works by redirecting Java's > stdout/ syserr so this just won't work. Perhaps we can spin the ant-based > test runner for such corner-cases. > Of lesser importance: > * Add an equivalent of 'documentation-lint" to precommit. > * (/) Do not require files to be committed before running precommit. (staged > files are fine). > * (/) add rendering of javadocs (gradlew javadoc) > * Attach javadocs to maven publications. > * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid > it'll be difficult to run it sensibly because gradle doesn't offer cwd > separation for the forked test runners. > * if you diff solr packaged distribution against ant-created distribution > there are minor differences in library versions and some JARs are excluded/ > moved around. I didn't try to force these as everything seems to work (tests, > etc.) – perhaps these differences should be fixed in the ant build instead. > * (/) identify and port various "regenerate" tasks from ant builds (javacc, > precompiled automata, etc.) > * Fill in POM details in gradle/defaults-maven.gradle so that they reflect > the previous content better (dependencies aside). > * Add any IDE integration layers that should be added (I use IntelliJ and it > imports the project out of the box, without the need for any special tuning). > * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; > currently XSLT...) > * I didn't bother adding Solr dist/test-framework to packaging (who'd use it > from a binary distribution? > * There is some python execution in check-broken-links and > check-missing-javadocs, not sure if it's been ported > * Nightly-smoke also has some python execution, not
[jira] [Commented] (SOLR-14296) Update netty to 4.1.46
[ https://issues.apache.org/jira/browse/SOLR-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059414#comment-17059414 ] Erick Erickson commented on SOLR-14296: --- I found some weirdness between the Gradle build (versions.lock) while working on upgrading ZK, so I'll do both at once. Curiously, the gradle version was 4.1.45, not sure how it got there. Thanks [~asalamon74] for doing the work on this, I'm glad you found the issue with 1.45, that'll make things easier. > Update netty to 4.1.46 > -- > > Key: SOLR-14296 > URL: https://issues.apache.org/jira/browse/SOLR-14296 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andras Salamon >Priority: Minor > Attachments: SOLR-14296-01.patch > > > There are two CVEs against the current netty version: > [https://nvd.nist.gov/vuln/detail/CVE-2019-20444] > [https://nvd.nist.gov/vuln/detail/CVE-2019-20445] > Although solr is not affected it would be still good to update netty. > The first non-affected netty version is 4.1.45 but during the update I've > found a netty bug ( [https://github.com/netty/netty/issues/10017] ) so it's > better to update to 4.1.46 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14296) Update netty to 4.1.47
[ https://issues.apache.org/jira/browse/SOLR-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14296: -- Summary: Update netty to 4.1.47 (was: Update netty to 4.1.46) > Update netty to 4.1.47 > -- > > Key: SOLR-14296 > URL: https://issues.apache.org/jira/browse/SOLR-14296 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andras Salamon >Priority: Minor > Attachments: SOLR-14296-01.patch > > > There are two CVEs against the current netty version: > [https://nvd.nist.gov/vuln/detail/CVE-2019-20444] > [https://nvd.nist.gov/vuln/detail/CVE-2019-20445] > Although solr is not affected it would be still good to update netty. > The first non-affected netty version is 4.1.45 but during the update I've > found a netty bug ( [https://github.com/netty/netty/issues/10017] ) so it's > better to update to 4.1.46 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14296) Update netty to 4.1.47
[ https://issues.apache.org/jira/browse/SOLR-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059414#comment-17059414 ] Erick Erickson edited comment on SOLR-14296 at 3/14/20, 5:22 PM: - I found some weirdness between the Gradle build (versions.lock) while working on upgrading ZK, so I'll do both at once. Curiously, the gradle version was 4.1.45, not sure how it got there. Meanwhile, 4.1.47 came out so I'll upgrade to that. Thanks [~asalamon74] for doing the work on this, I'm glad you found the issue with 1.45, that'll make things easier. was (Author: erickerickson): I found some weirdness between the Gradle build (versions.lock) while working on upgrading ZK, so I'll do both at once. Curiously, the gradle version was 4.1.45, not sure how it got there. Thanks [~asalamon74] for doing the work on this, I'm glad you found the issue with 1.45, that'll make things easier. > Update netty to 4.1.47 > -- > > Key: SOLR-14296 > URL: https://issues.apache.org/jira/browse/SOLR-14296 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andras Salamon >Priority: Minor > Attachments: SOLR-14296-01.patch > > > There are two CVEs against the current netty version: > [https://nvd.nist.gov/vuln/detail/CVE-2019-20444] > [https://nvd.nist.gov/vuln/detail/CVE-2019-20445] > Although solr is not affected it would be still good to update netty. > The first non-affected netty version is 4.1.45 but during the update I've > found a netty bug ( [https://github.com/netty/netty/issues/10017] ) so it's > better to update to 4.1.46 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14012) Different data type for unique aggregation and countDistinct
[
https://issues.apache.org/jira/browse/SOLR-14012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17059484#comment-17059484
]
Lucene/Solr QA commented on SOLR-14012:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
8s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 7s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 47m
53s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 52m 8s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14012 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12996720/SOLR-14012.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / cbd0dcb5df6 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/712/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/712/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Different data type for unique aggregation and countDistinct
>
>
> Key: SOLR-14012
> URL: https://issues.apache.org/jira/browse/SOLR-14012
> Project: Solr
> Issue Type: Sub-task
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14012.patch, SOLR-14012.patch, SOLR-14012.patch
>
>
> countDistinct value is long but unique aggregation's value is either long or
> int depending on shard count
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0
Andriy Rysin created LUCENE-9279: Summary: Update dictionary version for Ukrainian analyzer to 4.9.0 Key: LUCENE-9279 URL: https://issues.apache.org/jira/browse/LUCENE-9279 Project: Lucene - Core Issue Type: Bug Reporter: Andriy Rysin Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer. There's about 80k of new lemmas -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arysin opened a new pull request #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer
arysin opened a new pull request #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1353 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arysin closed pull request #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer
arysin closed pull request #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1353 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arysin commented on issue #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer
arysin commented on issue #1353: LUCENE-9279: Update dictionary version for Ukrainian analyzer URL: https://github.com/apache/lucene-solr/pull/1353#issuecomment-599153969 Looks like needs a bit more work 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
