[jira] [Created] (LUCENE-6112) Compile error with FST package example code
Tomoko Uchida created LUCENE-6112:
-
Summary: Compile error with FST package example code
Key: LUCENE-6112
URL: https://issues.apache.org/jira/browse/LUCENE-6112
Project: Lucene - Core
Issue Type: Task
Components: core/FSTs
Affects Versions: 4.10.2
Reporter: Tomoko Uchida
Priority: Minor
I run the FST construction example guided package.html with lucene 4.10, and
found a compile error.
http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
javac claimed as below.
FSTTest is my test class, just copied from javadoc's example.
{code}
$ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
given types;
builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
^
required: BytesRef,IntsRefBuilder
found: BytesRef,IntsRef
reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
method invocation conversion
Note: FSTTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
{code}
I modified scratchInts variable type from IntsRef to IntsRefBuilder, it worked
fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my modification seems
to be correct.)
Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of IntsRef
since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6112) Compile error with FST package example code
[
https://issues.apache.org/jira/browse/LUCENE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-6112:
--
Attachment: LUCENE-6112.patch
Fix for FSTs package.html
Compile error with FST package example code
---
Key: LUCENE-6112
URL: https://issues.apache.org/jira/browse/LUCENE-6112
Project: Lucene - Core
Issue Type: Task
Components: core/FSTs
Affects Versions: 4.10.2
Reporter: Tomoko Uchida
Priority: Minor
Attachments: LUCENE-6112.patch
I run the FST construction example guided package.html with lucene 4.10, and
found a compile error.
http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
javac claimed as below.
FSTTest is my test class, just copied from javadoc's example.
{code}
$ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
given types;
builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
^
required: BytesRef,IntsRefBuilder
found: BytesRef,IntsRef
reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
method invocation conversion
Note: FSTTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
{code}
I modified scratchInts variable type from IntsRef to IntsRefBuilder, it
worked fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my
modification seems to be correct.)
Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of
IntsRef since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6112) Compile error with FST package example code
[
https://issues.apache.org/jira/browse/LUCENE-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245844#comment-14245844
]
Tomoko Uchida edited comment on LUCENE-6112 at 12/14/14 6:37 AM:
-
I attached a fix for FSTs package.html
was (Author: tomoko uchida):
Fix for FSTs package.html
Compile error with FST package example code
---
Key: LUCENE-6112
URL: https://issues.apache.org/jira/browse/LUCENE-6112
Project: Lucene - Core
Issue Type: Task
Components: core/FSTs
Affects Versions: 4.10.2
Reporter: Tomoko Uchida
Priority: Minor
Attachments: LUCENE-6112.patch
I run the FST construction example guided package.html with lucene 4.10, and
found a compile error.
http://lucene.apache.org/core/4_10_2/core/index.html?org/apache/lucene/util/fst/package-summary.html
javac claimed as below.
FSTTest is my test class, just copied from javadoc's example.
{code}
$ javac -cp /opt/lucene-4.10.2/core/lucene-core-4.10.2.jar FSTTest.java
FSTTest.java:28: error: method toIntsRef in class Util cannot be applied to
given types;
builder.add(Util.toIntsRef(scratchBytes, scratchInts), outputValues[i]);
^
required: BytesRef,IntsRefBuilder
found: BytesRef,IntsRef
reason: actual argument IntsRef cannot be converted to IntsRefBuilder by
method invocation conversion
Note: FSTTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
{code}
I modified scratchInts variable type from IntsRef to IntsRefBuilder, it
worked fine. (I checked o.a.l.u.fst.TestFSTs.java TestCase and my
modification seems to be correct.)
Util.toIntsRef() method takes IntsRefBuilder as 2nd argument instead of
IntsRef since 4.10, so Javadocs also should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14255790#comment-14255790 ] Tomoko Uchida commented on SOLR-3055: - Hi, It seems not active for 3 years... I would like to rework this issue. I think this should be integrated to Lucene because, - NGramPhraseQuery is tightly related to NGramTokenizer, and it seems to be natural that coupling them at Lucene layer. - It would be also good for all Lucene based search engines to gain performance improvement. https://issues.apache.org/jira/browse/LUCENE-3426 So the patch (adding new attribute to Lucene) looks good for me at first glance... more discussion is needed of course. Would anyone approve me? if so, I'd like to move the discussion to (new) LUCENE issue. Or any suggestions are appreciated. Thanks. Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055.patch Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-3055: Attachment: SOLR-3055-2.patch SOLR-3055-1.patch Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259343#comment-14259343 ] Tomoko Uchida commented on SOLR-3055: - Again, I think there are three strategies for implementation. 1. embed gram size information in TokenStraem by adding new attribute (taken by first patch) - Pros: fully integrated with Lucene, so any application have not to write additional codes to optimize n-gram based phrase query - Pros: no configuration is needed because query parser create NGramPhraseQuery automatically - Pros: maybe most simple to implement - Cons: there might be some kind of conflicts with other attributes? 2. NGramTokenizer expose gramSize for later use, and Solr's QueryParser create NGramPhraseQuery - Pros: no effect to Lucene's default behavior - Pros: no configuration is needed because query parser create NGramPhraseQuery automatically - Cons: extra codes are needed to use NGramPhraseQuery per each query parser 3. add gramSize (or something like) attribute to schema.xml, and Solr's query parser create NGramPhraseQuery using given gramSize by user - Pros: no effect to Lucene's and Solr's default behavior - Cons: new configuration attribute will be introduced - Cons: what's happen if user give gramSize value inconsistent with minGramSize or maxGramSize given to NGramTokenizer? maybe it's problematic. I attach two patches, one (SOLR-3055-1.patch) for strategy 1 and other (SOLR-3055-2.patch) for strategy 2. Reviews / suggestions will be appreciated. Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-3055: Attachment: schema.xml Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch, schema.xml Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259351#comment-14259351 ] Tomoko Uchida commented on SOLR-3055: - I performed brief benchmark by JMeter for Solr 5.0.0 trunk and strategy 1. There seems to be significant performance gain for n-gram based phrase query. - Hardware : MacBook Pro, 2.8GHz Intel Core i5 - Java version : 1.7.0_71 - Solr version : 5.0.0 SNAPSHOT / 5.0.0 SNAPSHOT with SOLR-3055-1.patch - Java heap : 500MB - Documents : Wikipedia (Japanese) 10 docs - Solr config : attached solrconfig.xml (query result cache disabled) - Schema : attached schema.xml (NGramTokenizer's maxGramSize=3, minGramSIze=2) - Queries : python, javascript, windows, プログラミング, インターネット, スマートフォン (japanese) - JMeter scenario : execute each 6 queries above 1000 times (i.e. perform 6000 queries) - JMeter Threads : 1 To warm up, I performed 2 times JMeter scinario for both settings. 2nd round results are: || Solr || Avg. response time || Throughput || | 5.0.0-SNAPSHOT | 7msec | 137.8/sec | | 5.0.0-SNAPSHOT with patch-1 | 4msec | 201.3/sec | Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch, schema.xml Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-3055: Attachment: solrconfig.xml Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch, schema.xml, solrconfig.xml Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259560#comment-14259560 ] Tomoko Uchida commented on SOLR-3055: - Thank you for your response. I will add test codes and updated patch to consider other Tokenizers / TokenFilters. My patch seems to work well for both case, minGramSize == maxGramSize and minGramSize != maxGramSize. But not optimized for maxGramSize. In the case of minGramSize != maxGramSize, using maxGramSize for optimization derives the best performance improvement. We can examine about that (maybe need another issue.) In practice, we often set fixed gram size for CJK words as you pointed, so I think it is beneficial even if it is not optimized for maxGramSize. Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch, schema.xml, solrconfig.xml Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6893) DIH doen't work using URL and wget
[
https://issues.apache.org/jira/browse/SOLR-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259713#comment-14259713
]
Tomoko Uchida commented on SOLR-6893:
-
Hi,
At my environment (Mac OS), DIH works well with wget command.
Maybe you should remove '/#/' from request url.
I have tested two patterns with /#/ and without /#/
It works.
{code}
$ wget -O response
http://localhost:8983/solr/wikipedia/dataimport?command=full-importindent=true;
$ wget -O response
http://localhost:8983/solr/wikipedia/dataimport?command=statusindent=true;
$ cat response
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime0/int
/lst
lst name=initArgs
lst name=defaults
str name=configdb-data-config.xml/str
/lst
/lst
str name=commandstatus/str
str name=statusbusy/str
str name=importResponseA command is still running.../str
lst name=statusMessages
str name=Time Elapsed0:6:59.792/str
str name=Total Requests made to DataSource1/str
str name=Total Rows Fetched121772/str
str name=Total Documents Processed60885/str
str name=Total Documents Skipped0/str
str name=Full Dump Started2014-12-28 19:38:24/str
/lst
/response
{code}
It does not work.
{code}
$ wget -O response
http://localhost:8983/solr/#/wikipedia/dataimport?command=full-importindent=true;
{code}
Please try again after removing '#' character (this character has special
meaning in URI specification.)
DIH doen't work using URL and wget
--
Key: SOLR-6893
URL: https://issues.apache.org/jira/browse/SOLR-6893
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.8.1, 4.10.2
Environment: Linux (Ubuntu, CentOS)
Reporter: Dani
Priority: Minor
I put this URL on browser and import correctly starts:
http://localhost:8983/solr/#/sintesicontratti/dataimport//importazione?command=full-importentity=fileImportclean=truecommit=true
But if I use wget it doens't work:
wget
http://localhost:8983/solr/#/sintesicontratti/dataimport//importazione?command=full-importentity=fileImportclean=truecommit=true;
nor also using escape:
wget
http://localhost:8983/solr/#/sintesicontratti/dataimport//importazione?command=full-import\entity=fileImport\clean=true\commit=true;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281269#comment-14281269 ] Tomoko Uchida commented on LUCENE-2562: --- Hi, is this issue still active? I've attached a patch (LUCENE-2562-ivy.patch) to follow latest Lucene updates. This patche does - add ant task ivy-resolve and ivy-clean to resolve dependencies using Ivy ivy-resolve task creates lib-ivy directory and download necessary libraries from maven repository. - modify compile, dist, and other related tasks use libraries downloaded by ivy-resolve - make small source code changes to go with Lucene 4.10.3 lib/\*.jar, lib/solr/\*.jar, lib/hadopp/\*.jar are no longer used for compile and distribute, so they can be removed from the repository later, except for lib/js.jar (I could not identify this.) Note: Eclipse's .classpath file is not changed. Compiled o.a.l.luke.ui.LukeApplication can browse indices generated by Lucene 4.10.3. If you're interested, I hope to take more time for the project. Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: LUCENE-2562-ivy.patch Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292730#comment-14292730 ] Tomoko Uchida commented on LUCENE-2562: --- Thanks everyone for all comments, I recognize that the goal of this project is making Luke a Lucene module. I think it will be nice if there is a REST API server for Admin UIs, and have some kind of pluggable architecture for external modules (like custom analyzers provided by Solr, Elsticsearch, etc.) But at first, I'd like to make it cover standalone Luke application features under Apache license. Dear Uwe and all, We already use IVY in Lucene/Solr. Please use the framework that is already there through common-build.xml / module-build.xml. It is enough to place ivy.xml in the module directory and make the module include the module-build.xml file. I wanted to use the Lucene's framework, but currently, this module is placed under http://svn.apache.org/repos/asf/lucene/sandbox/ , not http://svn.apache.org/repos/asf/lucene/dev/trunk ivy.xml and ant tasks in my patch should be only temporary (for convenience in development,) until this module will be merged to trunk. So what can I do to smoothly integrate this module into Lucene trunk in the future. If there are better ways, please let me know... Thanks Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293926#comment-14293926 ] Tomoko Uchida edited comment on LUCENE-2562 at 1/27/15 6:32 PM: Patch updated. I've modified Overview tab only. Progress and Status : - Missing values in upper panel (index info) were all filled. - Fields table are now sortable by field name and term counts. Pending tasks to be done: - Decoders (last pending task for Overview tab) I'm trying for decoders. It might need some sort of pluggable design (I believe Solr's decoders should be plugged, not built-in feature.) Suggestions / ideas welcome. was (Author: tomoko uchida): Patch updated. I've modified Overview tab only. Progress and Status : - Missing values in upper panel (index info) were all filled. - Fields table are now sortable by field name and term counts. Pending tasks to be done: - Decoders (last pending task for Overview tab) I'm trying for decoders. It might need some sort of pluggable design (I believe Solr's decoders should be plugged, not built-in feature.) Suggestions / ideas welcome. Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293926#comment-14293926 ] Tomoko Uchida commented on LUCENE-2562: --- Patch updated. I've modified Overview tab only. Progress and Status : - Missing values in upper panel (index info) were all filled. - Fields table are now sortable by field name and term counts. Pending tasks to be done: - Decoders (last pending task for Overview tab) I'm trying for decoders. It might need some sort of pluggable design (I believe Solr's decoders should be plugged, not built-in feature.) Suggestions / ideas welcome. Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14291506#comment-14291506 ] Tomoko Uchida commented on LUCENE-2562: --- Hi Mark, Thank you for the response! My patch needs ivy jar in lib/tools directory. (I've forgot to note that.) That does not introduce additional Java codes, but brings dependency resolution. I've slowly started to catch up and play with (and modify) the codes... so I would like to create another patches to make progress. Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: LUCENE-2562-Ivy.patch Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300183#comment-14300183
]
Tomoko Uchida commented on LUCENE-2562:
---
Patch updated. I've modified Overview and Documents tab.
Progress and Status:
- (Overview tab) Decoders support in fields table. They are now selectable.
- (Overview tab) 'more options' support in top ranking terms table except for
'Show all term docs' (That will be supported after Search tab is completed.)
- (Documents tab) Layouts arrange. (I hope that's OK.)
- (Documents tab) 'Browse by term' (upper center pane) fixed.
- (Documents tab) Documents viewer (lower pane) fixed and support DocValues
info (original Luke does not support this because docvalues are new, of
course).
- Decoders are now pluggable. DecoderLoader interface added.
- Some fixes, refactoring
Pending tasks to be done:
- (Documents tab) 'Browse documents with this term' (upper right pane) is not
yet fixed. It works but be buggy.
I've added DecoderLoader interface and implemented SolrDecoderLoader class to
make Luke work with or without Solr jars. I think we will be able to completely
separate SolrDecoderLoader class from Luke's package later (or integrate this
in Luke again if that is proper way.)
With this patch, if you want to use Luke with Solr's Decoder (wrapper for
schema.FieldType,) you need to add a JVM option luke.ext.decoder.loader as
below when start Luke.
{code}
$ java -cp build
-Dluke.ext.decoder.loader=org.apache.lucene.luke.ext.SolrDecoderLoader
org.apache.lucene.luke.ui.LukeApplication
{code}
My approach is not good, please let me know.
For SolrDecoder, need to modify ivy.xml as follows. (I could not include this
modification in my patch, because 'svn diff' complains 'Cannot display: file
marked as a binary type.')
{code:xml}
!-- apache solr --
dependency org=org.apache.solr name=solr-core rev=4.10.3
transitive=false // remove this line
conf=solr-*,!sources,!javadoc/
{code}
I add some resources to 'LukeApplication_en.json', but I'm not a fluent English
speaker, so please check and correct if there's any mistakes...
Make Luke a Lucene/Solr Module
--
Key: LUCENE-2562
URL: https://issues.apache.org/jira/browse/LUCENE-2562
Project: Lucene - Core
Issue Type: Task
Reporter: Mark Miller
Labels: gsoc2014
Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png,
Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg,
luke2.jpg, luke3.jpg
see
RE: Luke - in need of maintainer:
http://markmail.org/message/m4gsto7giltvrpuf
Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q
I think it would be great if there was a version of Luke that always worked
with trunk - and it would also be great if it was easier to match Luke jars
with Lucene versions.
While I'd like to get GWT Luke into the mix as well, I think the easiest
starting point is to straight port Luke to another UI toolkit before
abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
I've started slowly converting Luke's use of thinlet to Apache Pivot. I
haven't/don't have a lot of time for this at the moment, but I've plugged
away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: LUCENE-2562-Ivy.patch Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3055) Use NGramPhraseQuery in Solr
[ https://issues.apache.org/jira/browse/SOLR-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264605#comment-14264605 ] Tomoko Uchida commented on SOLR-3055: - I've created LUCENE-6163 and added a patch (because this patch affects lucene-core and lucene-analysis, does not solr.) I hope to keep working there. Use NGramPhraseQuery in Solr Key: SOLR-3055 URL: https://issues.apache.org/jira/browse/SOLR-3055 Project: Solr Issue Type: New Feature Components: Schema and Analysis, search Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-3055-1.patch, SOLR-3055-2.patch, SOLR-3055.patch, schema.xml, solrconfig.xml Solr should use NGramPhraseQuery when searching with default slop on n-gram field. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6163) Use NGramPhraseQuery via QueryBuilder
Tomoko Uchida created LUCENE-6163: - Summary: Use NGramPhraseQuery via QueryBuilder Key: LUCENE-6163 URL: https://issues.apache.org/jira/browse/LUCENE-6163 Project: Lucene - Core Issue Type: New Feature Components: core/other, modules/analysis Reporter: Tomoko Uchida Priority: Minor This is derived from SOLR-3055. To gain performance improvement of LUCENE-3426, QueryBuilder should generate NGramPhraseQuery to optimize n-gram based phrase query. (especially good for CJK languages, but the benefit is not limited to those.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6163) Use NGramPhraseQuery via QueryBuilder
[ https://issues.apache.org/jira/browse/LUCENE-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-6163: -- Affects Version/s: 5.0 Use NGramPhraseQuery via QueryBuilder - Key: LUCENE-6163 URL: https://issues.apache.org/jira/browse/LUCENE-6163 Project: Lucene - Core Issue Type: New Feature Components: core/other, modules/analysis Affects Versions: 5.0 Reporter: Tomoko Uchida Priority: Minor Attachments: LUCENE-6163.patch This is derived from SOLR-3055. To gain performance improvement of LUCENE-3426, QueryBuilder should generate NGramPhraseQuery to optimize n-gram based phrase query. (especially good for CJK languages, but the benefit is not limited to those.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6163) Use NGramPhraseQuery via QueryBuilder
[ https://issues.apache.org/jira/browse/LUCENE-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-6163: -- Attachment: LUCENE-6163.patch I've added a patch for NGramTokenizer. Other n-gram based tokenizer/filters like CJKBigramFilter could be modified in a similar way. (another issue is needed?) Use NGramPhraseQuery via QueryBuilder - Key: LUCENE-6163 URL: https://issues.apache.org/jira/browse/LUCENE-6163 Project: Lucene - Core Issue Type: New Feature Components: core/other, modules/analysis Reporter: Tomoko Uchida Priority: Minor Attachments: LUCENE-6163.patch This is derived from SOLR-3055. To gain performance improvement of LUCENE-3426, QueryBuilder should generate NGramPhraseQuery to optimize n-gram based phrase query. (especially good for CJK languages, but the benefit is not limited to those.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6940) Query UI in admin should support other facet options
[ https://issues.apache.org/jira/browse/SOLR-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275243#comment-14275243 ] Tomoko Uchida commented on SOLR-6940: - It would be nice to have easy to use options for pivots, ranges, etc. Nice improvement! I'll add a very simple patch supporting more facet options listed in wiki (except for advanced options.) A screen shot will be also attached. https://cwiki.apache.org/confluence/display/solr/Faceting - facet.sort, facet.limit, facet.offset, facet.mincount, facet.missing - facet.pivot, facet.pivot.mincount - facet.range, facet.range.start, facet.range.end, facet.range.gap, facet.range.hardend, facet.range.include, facet.range.other and, multiple facet.field and facet.pivot options are allowed in this patch. (I've also tried per field options like f.fieldname.facet.sort, but that could bring complexity in the html / JS ...) Your feedback is welcome. If you're interested, I would like to catch up and work for SOLR-5507, of course. Query UI in admin should support other facet options Key: SOLR-6940 URL: https://issues.apache.org/jira/browse/SOLR-6940 Project: Solr Issue Type: Improvement Components: web gui Reporter: Grant Ingersoll As of right now in the Admin Query UI, you can only easily provide facet options for field, query and prefix. It would be nice to have easy to use options for pivots, ranges, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6940) Query UI in admin should support other facet options
[ https://issues.apache.org/jira/browse/SOLR-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-6940: Attachment: query_ui_facet_options.png SOLR-6940.patch Query UI in admin should support other facet options Key: SOLR-6940 URL: https://issues.apache.org/jira/browse/SOLR-6940 Project: Solr Issue Type: Improvement Components: web gui Reporter: Grant Ingersoll Attachments: SOLR-6940.patch, query_ui_facet_options.png As of right now in the Admin Query UI, you can only easily provide facet options for field, query and prefix. It would be nice to have easy to use options for pivots, ranges, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6940) Query UI in admin should support other facet options
[ https://issues.apache.org/jira/browse/SOLR-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275447#comment-14275447 ] Tomoko Uchida commented on SOLR-6940: - I've make a pull request, that is identical to the patch I attached here, to the repository https://github.com/upayavira/solr-angular-ui Please guide me if I've done something wrong. Query UI in admin should support other facet options Key: SOLR-6940 URL: https://issues.apache.org/jira/browse/SOLR-6940 Project: Solr Issue Type: Improvement Components: web gui Reporter: Grant Ingersoll Attachments: SOLR-6940.patch, query_ui_facet_options.png As of right now in the Admin Query UI, you can only easily provide facet options for field, query and prefix. It would be nice to have easy to use options for pivots, ranges, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14320413#comment-14320413 ] Tomoko Uchida commented on LUCENE-2562: --- Patch updated. Ive modified Documents tab. (A screen shot, lukeALE-documents.png is attached.) Status and progress: * support 'Browse documents with this term' and 'Show positions and Offsets' * support right click options for document's fields (Show term vector, Full text, Set norm, Save field data) Pending tasks to be done (I'm going to implement them): * 'Add','Edit','Delete' operations for documents * 'Show all docs','More like this' (will be supported when Search tab completed) I understand this is not a rush job, many tasks still remain... I'd like to keep going and log updates here. Because components are well separated, I think anyone can join. :) Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: lukeALE-documents.png LUCENE-2562-Ivy.patch Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6163) Use NGramPhraseQuery via QueryBuilder
[ https://issues.apache.org/jira/browse/LUCENE-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264677#comment-14264677 ] Tomoko Uchida commented on LUCENE-6163: --- Thanks for the response. I don't think the optimization is safe if any tokenfilter modifies the tokens after ngram, it will give the wrong results. I understand your indication. Your point is about my patch, not about NGramPhraseQuery itself? If my approach is bad, another way, as noted in the past comment of SOLR-3055, could still be possible. any suggestions will be appreciated. Use NGramPhraseQuery via QueryBuilder - Key: LUCENE-6163 URL: https://issues.apache.org/jira/browse/LUCENE-6163 Project: Lucene - Core Issue Type: New Feature Components: core/other, modules/analysis Affects Versions: 5.0 Reporter: Tomoko Uchida Priority: Minor Attachments: LUCENE-6163.patch This is derived from SOLR-3055. To gain performance improvement of LUCENE-3426, QueryBuilder should generate NGramPhraseQuery to optimize n-gram based phrase query. (especially good for CJK languages, but the benefit is not limited to those.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14344292#comment-14344292 ] Tomoko Uchida commented on LUCENE-2562: --- Progress and status: Honestly there are no progress in development, I'd like to suggest about merge of this Jira issue and the Luke project now on Github. The (one of) Luke project's goal, To port the thinlet UI to an ASL compliant license framework so that it can be contributed back to Apache Lucene., is perfectly match the goal of this issue, I hope it would be desirable way. https://github.com/DmitryKey/luke/tree/master After a short discussion at solr mailing list, Dmitry Kan, the maintainer of Luke, has created pivot-luke branch in luke repository. And I have merged all the latest pivot's version codes plugged in SVN to the branch. The discussion is here: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201502.mbox/%3CCAHpHuj%3DZArPSbSLp2_d1X7OD_2V0NeBsDSRVizgTDTnBiAZPMQ%40mail.gmail.com%3E The branch for pivot's version is here: https://github.com/DmitryKey/luke/tree/pivot-luke It now can be built by maven, you can check out and test it. We'll contribute back to Lucene it, I hope this is in not so distant future. Of course, developers are welcome. I know it's homage to the original Luke default color, but we should really change the default background color I promise that, gray theme is also my favorite one! :) I'll keep watching this ticket, any comments and suggestions are welcome. Thanks. Make Luke a Lucene/Solr Module -- Key: LUCENE-2562 URL: https://issues.apache.org/jira/browse/LUCENE-2562 Project: Lucene - Core Issue Type: Task Reporter: Mark Miller Labels: gsoc2014 Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png see RE: Luke - in need of maintainer: http://markmail.org/message/m4gsto7giltvrpuf Web-based Luke: http://markmail.org/message/4xwps7p7ifltme5q I think it would be great if there was a version of Luke that always worked with trunk - and it would also be great if it was easier to match Luke jars with Lucene versions. While I'd like to get GWT Luke into the mix as well, I think the easiest starting point is to straight port Luke to another UI toolkit before abstracting out DTO objects that both GWT Luke and Pivot Luke could share. I've started slowly converting Luke's use of thinlet to Apache Pivot. I haven't/don't have a lot of time for this at the moment, but I've plugged away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7273) New kuromoji TokenFilter to keep tokens by part-of-speech tags
Tomoko Uchida created LUCENE-7273:
-
Summary: New kuromoji TokenFilter to keep tokens by part-of-speech
tags
Key: LUCENE-7273
URL: https://issues.apache.org/jira/browse/LUCENE-7273
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Tomoko Uchida
Priority: Minor
Kuromoji has JapanesePartOfSpeechStopFilter to drop tokens by their
part-of-speech tags. In some cases, it would be convenient to keep tokens
according to "keep" POS tags list.
Example usage:
{code:java}
// keeps proper nouns - location names only
String[] tags = new String[]{"名詞-固有名詞-地域-一般"};
Set keeptags = new HashSet<>();
for (String tag: tags) {
keeptags.add(tag);
}
JapaneseTokenizer tokenizer = new JapaneseTokenizer(null, false,
JapaneseTokenizer.Mode.SEARCH);
JapanesePartOfSpeechKeepFilter stream = new
JapanesePartOfSpeechKeepFilter(tokenizer, keeptags);
{code}
{code:xml}
{code}
Of course it can be achieved by using JapanesePartOfSpeechStopFilter, however
because there are about 70 part-of-speeches, it can be cumbersome to list all
stop tags to keep tokens with few POS tags of interest.
I'll add a patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7273) New kuromoji TokenFilter to keep tokens by part-of-speech tags
[
https://issues.apache.org/jira/browse/LUCENE-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-7273:
--
Attachment: LUCENE-analysis-kuromoji-poskeep.patch
> New kuromoji TokenFilter to keep tokens by part-of-speech tags
> --
>
> Key: LUCENE-7273
> URL: https://issues.apache.org/jira/browse/LUCENE-7273
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-analysis-kuromoji-poskeep.patch
>
>
> Kuromoji has JapanesePartOfSpeechStopFilter to drop tokens by their
> part-of-speech tags. In some cases, it would be convenient to keep tokens
> according to "keep" POS tags list.
> Example usage:
> {code:java}
> // keeps proper nouns - location names only
> String[] tags = new String[]{"名詞-固有名詞-地域-一般"};
> Set keeptags = new HashSet<>();
> for (String tag: tags) {
> keeptags.add(tag);
> }
> JapaneseTokenizer tokenizer = new JapaneseTokenizer(null, false,
> JapaneseTokenizer.Mode.SEARCH);
> JapanesePartOfSpeechKeepFilter stream = new
> JapanesePartOfSpeechKeepFilter(tokenizer, keeptags);
> {code}
> {code:xml}
>
> positionIncrementGap="100"
>autoGeneratePhraseQueries="false">
>
>
>
> tags="lang/keeptags_ja.txt" />
> minimumLength="4"/>
>
>
>
> {code}
> Of course it can be achieved by using JapanesePartOfSpeechStopFilter, however
> because there are about 70 part-of-speeches, it can be cumbersome to list all
> stop tags to keep tokens with few POS tags of interest.
> I'll add a patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: (was: luke-javafx1.png) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx2.png, luke-javafx3.png, > luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: luke-javafx3.png luke-javafx2.png luke-javafx1.png > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477189#comment-16477189 ] Tomoko Uchida edited comment on LUCENE-2562 at 5/16/18 10:04 AM: - I'll attach some screen shots to share what new UI looks like. was (Author: tomoko uchida): I'll attach some screen shots to share what new UI looks like. !luke-javafx1.png! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477185#comment-16477185 ] Tomoko Uchida commented on LUCENE-2562: --- It's been a while... but I have ported Luke UI from Thinlet to JavaFX (I feel JavaFX is now better choice than other 3rd party Frameworks, what do you think?) JavaFX version can be downloaded here: [https://github.com/DmitryKey/luke/releases/tag/luke-7.3.1] * Licensed under ALv2 * Ported major luke functionalities (browsing index, searching docs, optimizing/checking index, etc) * Supports recent Lucene features (DocValues, PointValues, CustomAnalyzers, etc.) * Almost full scratched to utilize modern Java syntax/features and unit tested with Lucene Test Framework The GitHub repository earns close to 900 stargagers! It's good time to contribute back to Lucene project but I am not sure what is the proper way. Let me know where should I start. Anyway, please check it out and I want to hear your feedback! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477189#comment-16477189 ] Tomoko Uchida commented on LUCENE-2562: --- I'll attach some screen shots to share what new UI looks like. !luke-javafx1.png! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: luke-javafx3.png luke-javafx2.png luke-javafx1.png > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477189#comment-16477189 ] Tomoko Uchida edited comment on LUCENE-2562 at 5/16/18 10:08 AM: - I'll attach some screen shots to share what new UI looks like. !luke-javafx1.png|width=50%, height=50%! !luke-javafx2.png|width=50%, height=50%! !luke-javafx3.png|width=50%, height=50%! was (Author: tomoko uchida): I'll attach some screen shots to share what new UI looks like. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16480467#comment-16480467 ] Tomoko Uchida commented on LUCENE-2562: --- Thank you [~markrmil...@gmail.com] for response. First I need some research for Lucene build system and try to fit the Github repository (built by maven) to it... any advise is welcome. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: (was: luke-javafx3.png) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: (was: luke-javafx2.png) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke1.jpg, luke2.jpg, luke3.jpg, > lukeALE-documents.png > > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16566477#comment-16566477 ] Tomoko Uchida edited comment on LUCENE-2562 at 8/2/18 8:09 AM: --- Well..., I am now working for completing a java desktop Luke, in any case. If someone is strongly interested in a http server & web app version, feel free to fork the github repository ( https://github.com/DmitryKey/luke ) and develop it. I am the one long for a web version Luke that can access indexes in remote server, and will glad to cooperate. was (Author: tomoko uchida): Well..., I am now working for completing a java desktop Luke, in any case. If someone is strongly interested in a http server & web app version, feel free to fork the github repository ([https://github.com/DmitryKey/luke)] and develop it. I am the one long for a web version Luke that can access indexes in remote server, and will glad to cooperate. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16566477#comment-16566477 ] Tomoko Uchida commented on LUCENE-2562: --- Well..., I am now working for completing a java desktop Luke, in any case. If someone is strongly interested in a http server & web app version, feel free to fork the github repository ([https://github.com/DmitryKey/luke)] and develop it. I am the one long for a web version Luke that can access indexes in remote server, and will glad to cooperate. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576915#comment-16576915 ] Tomoko Uchida commented on LUCENE-8453: --- KoreanAnalyzer discards some parameters (for example, KoreanTokenizerFactory has additional parameters "userDictionary" and "userDictionaryEncoding") I think Javadoc examples should include all available parameters so my example settings include all parameters TokenizerFactory/TokenFilterFactoys accept. About LowerCaseFilterFactory, of course it is needed in complete Analyzer settings, I "feel" Javadoc example should focus on the targeted component only (like Kuromoji example settings below.) https://lucene.apache.org/core/7_4_0/analyzers-kuromoji/org/apache/lucene/analysis/ja/JapanesePartOfSpeechStopFilterFactory.html > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576941#comment-16576941
]
Tomoko Uchida edited comment on LUCENE-8453 at 8/10/18 10:50 PM:
-
So here are my proposal for javadoc's example settings (my pull request) :)
For KoreanTokenizerFactory:
{code:xml}
{code}
For KoreanPartOfSpeechStopFilterFactory:
{code:xml}
{code}
For KoreanReadingFormFilterFactory:
{code:xml}
{code}
was (Author: tomoko uchida):
So my proposal for javadoc's example settings (my pull request) is here :)
For KoreanTokenizerFactory:
{code:xml}
{code}
For KoreanPartOfSpeechStopFilterFactory:
{code:xml}
{code}
For KoreanReadingFormFilterFactory:
{code:xml}
{code}
> Add example settings to Korean analyzer components' javadocs
>
>
> Key: LUCENE-8453
> URL: https://issues.apache.org/jira/browse/LUCENE-8453
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Reporter: Tomoko Uchida
>Priority: Minor
>
> Korean analyzer (nori) javadoc needs example schema settings.
> I'll create a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576915#comment-16576915 ] Tomoko Uchida edited comment on LUCENE-8453 at 8/10/18 10:16 PM: - KoreanAnalyzer discards some parameters (for example, KoreanTokenizerFactory has additional parameters "userDictionary" and "userDictionaryEncoding".) I think Javadoc examples should include all available parameters so my example settings include all parameters which are accepted by TokenizerFactory/TokenFilterFactoys. About LowerCaseFilterFactory, of course it is needed in complete Analyzer settings, I "feel" Javadoc example should focus on the targeted component only (like Kuromoji example settings below.) [https://lucene.apache.org/core/7_4_0/analyzers-kuromoji/org/apache/lucene/analysis/ja/JapanesePartOfSpeechStopFilterFactory.html] was (Author: tomoko uchida): KoreanAnalyzer discards some parameters (for example, KoreanTokenizerFactory has additional parameters "userDictionary" and "userDictionaryEncoding") I think Javadoc examples should include all available parameters so my example settings include all parameters TokenizerFactory/TokenFilterFactoys accept. About LowerCaseFilterFactory, of course it is needed in complete Analyzer settings, I "feel" Javadoc example should focus on the targeted component only (like Kuromoji example settings below.) https://lucene.apache.org/core/7_4_0/analyzers-kuromoji/org/apache/lucene/analysis/ja/JapanesePartOfSpeechStopFilterFactory.html > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577014#comment-16577014 ] Tomoko Uchida edited comment on LUCENE-8453 at 8/11/18 2:20 AM: Slightly off topic, feel free to ignore, but I think Solr example settings should be removed from TokenizerFactory/TokenFilterFactory/CharFilterFactory documentation. I suppose there may be historical reasons, so I followed the convention, but it is not reasonable to add Solr schema examples here. Not XML schema examples, but parameter descriptions are needed to each Factory documentation. was (Author: tomoko uchida): Slightly off topic, feel free to ignore, but I think Solr example settings should be removed from Tokenizer/TokenFilter/CharFilter documentation. I suppose there may be historical reasons, so I followed the convention, but it is not reasonable to add Solr schema examples here. Not XML schema examples, but parameter descriptions are needed to each Factory documentation. > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577014#comment-16577014 ] Tomoko Uchida commented on LUCENE-8453: --- Slightly off topic, feel free to ignore, but I think Solr example settings should be removed from Tokenizer/TokenFilter/CharFilter documentation. I suppose there may be historical reasons, so I followed the convention, but it is not reasonable to add Solr schema examples here. Not XML schema examples, but parameter descriptions are needed to each Factory documentation. > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577100#comment-16577100 ] Tomoko Uchida commented on LUCENE-8453: --- I've tested those three settings with Solr 7.4.0, works for me. (I copied `lucene-analyzers-nori-7.4.0.jar` and user dictionary file from lucene distribution package to solr lib directory.) > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576941#comment-16576941
]
Tomoko Uchida edited comment on LUCENE-8453 at 8/11/18 1:42 AM:
So here are my proposal for javadoc's example settings (my pull request) :)
For KoreanTokenizerFactory:
{code:xml}
{code}
For KoreanPartOfSpeechStopFilterFactory:
{code:xml}
{code}
For KoreanReadingFormFilterFactory:
{code:xml}
{code}
Update:
Added brief descriptions for each parameter (please see the pull request,)
though unfortunately, Kuromoji's documentation lacks those.
was (Author: tomoko uchida):
So here are my proposal for javadoc's example settings (my pull request) :)
For KoreanTokenizerFactory:
{code:xml}
{code}
For KoreanPartOfSpeechStopFilterFactory:
{code:xml}
{code}
For KoreanReadingFormFilterFactory:
{code:xml}
{code}
> Add example settings to Korean analyzer components' javadocs
>
>
> Key: LUCENE-8453
> URL: https://issues.apache.org/jira/browse/LUCENE-8453
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Reporter: Tomoko Uchida
>Priority: Minor
>
> Korean analyzer (nori) javadoc needs example schema settings.
> I'll create a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576941#comment-16576941
]
Tomoko Uchida commented on LUCENE-8453:
---
So my proposal for javadoc's example settings (my pull request) is here :)
For KoreanTokenizerFactory:
{code:xml}
{code}
For KoreanPartOfSpeechStopFilterFactory:
{code:xml}
{code}
For KoreanReadingFormFilterFactory:
{code:xml}
{code}
> Add example settings to Korean analyzer components' javadocs
>
>
> Key: LUCENE-8453
> URL: https://issues.apache.org/jira/browse/LUCENE-8453
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Reporter: Tomoko Uchida
>Priority: Minor
>
> Korean analyzer (nori) javadoc needs example schema settings.
> I'll create a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577106#comment-16577106 ] Tomoko Uchida commented on LUCENE-8453: --- I think this pull request is almost ready to merge. Could anyone take care this? I believe documentation for analyzer components is very important & a good starting point to newbies. :) > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577130#comment-16577130
]
Tomoko Uchida commented on LUCENE-8453:
---
Thank you [~thetaphi] !
and, thanks for your explanation.
{quote}There is an issue open already (I think, can't find it now). I agree,
the XML snippets should go away. Instead we can add some Javadoc tag for this
like @factoryProp name description. This is much better. We should also
document the SPI name of each factory.
{quote}
> Add example settings to Korean analyzer components' javadocs
>
>
> Key: LUCENE-8453
> URL: https://issues.apache.org/jira/browse/LUCENE-8453
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 7.4
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: master (8.0), 7.5
>
>
> Korean analyzer (nori) javadoc needs example schema settings.
> I'll create a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582610#comment-16582610 ] Tomoko Uchida commented on LUCENE-2562: --- [~sokolov] hi, I found a web based Luke project, with a rest api server and modern js technologies. This might be what you are wanting? [http://www.flax.co.uk/blog/2017/02/24/release-1-0-marple-lucene-index-detective/] I've not tried this yet, for your information. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[
https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577604#comment-16577604
]
Tomoko Uchida commented on LUCENE-8453:
---
It may not be good manners to add comments to closed issue, but I'd like to
leave a reminder for myself.
{quote}Another idea: To make the propertie sof all analyzers easily available
for inspection by the APIs in Solr, we may add runtime annotations to those
classes, describing the properties. Just an idea.
{quote}
I like the idea, it would be nice that some kind of properties
management/discovery mechanism (I have no concrete implementation image, just a
vague concept) is equipped in \{Tokenizer|CharFilter|TokenFilter}Factorys.
It will be handy for documentation and Solr, and also for CustomAnalyser (I
sometimes use it for my nlp projects.)
I'll try it, not soon, after I'll have finished current ongoing projects.
> Add example settings to Korean analyzer components' javadocs
>
>
> Key: LUCENE-8453
> URL: https://issues.apache.org/jira/browse/LUCENE-8453
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 7.4
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: master (8.0), 7.5
>
>
> Korean analyzer (nori) javadoc needs example schema settings.
> I'll create a patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
Tomoko Uchida created LUCENE-8453: - Summary: Add example settings to Korean analyzer components' javadocs Key: LUCENE-8453 URL: https://issues.apache.org/jira/browse/LUCENE-8453 Project: Lucene - Core Issue Type: Improvement Components: general/javadocs Reporter: Tomoko Uchida Korean analyzer (nori) javadoc needs example schema settings. I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576242#comment-16576242 ] Tomoko Uchida commented on LUCENE-8453: --- Created a PR. It is based on Kuromoji's examples. [https://github.com/apache/lucene-solr/pull/434] Note: I've tested all parameters in this example schemas with CustomAnalyzer, but not yet tested with Solr. Check the XML settings with Solr, please. > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576242#comment-16576242 ] Tomoko Uchida edited comment on LUCENE-8453 at 8/10/18 1:23 PM: Created a PR. It is based on Kuromoji's examples. [https://github.com/apache/lucene-solr/pull/434] Note: I've tested all parameters in this example schemas with CustomAnalyzer, but not tested with Solr yet. Check the XML settings with Solr, please. was (Author: tomoko uchida): Created a PR. It is based on Kuromoji's examples. [https://github.com/apache/lucene-solr/pull/434] Note: I've tested all parameters in this example schemas with CustomAnalyzer, but not yet tested with Solr. Check the XML settings with Solr, please. > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8453) Add example settings to Korean analyzer components' javadocs
[ https://issues.apache.org/jira/browse/LUCENE-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576321#comment-16576321 ] Tomoko Uchida commented on LUCENE-8453: --- And, I think it would be better if Korean natives check that example values are good as default :) > Add example settings to Korean analyzer components' javadocs > > > Key: LUCENE-8453 > URL: https://issues.apache.org/jira/browse/LUCENE-8453 > Project: Lucene - Core > Issue Type: Improvement > Components: general/javadocs >Reporter: Tomoko Uchida >Priority: Minor > > Korean analyzer (nori) javadoc needs example schema settings. > I'll create a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550630#comment-16550630 ] Tomoko Uchida commented on LUCENE-2562: --- Let me add one more thing, I'm afraid that I cannot ask to and negotiate with ASF on my own about complicated matters with my limited knowledge about licensing and English vocabulary. But if you think there are chances to proceed, please guide me :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550243#comment-16550243 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/20/18 5:06 AM: As you know, in the ASF legal page, GNU GPL including GNU Classpath exceptions is listed in the Category X list (honestly, I read this terms yesterday and not prepared to handle such legal matters.) [https://www.apache.org/legal/resolved.html#category-x] To not to complicate matters I'd like to withdraw the merge request for now. (Thanks for all your comments so far!) While contributing back Luke to Apache Lucene project is the our long-term goal, we can continually deliver Luke via current GitHub project. For keeping Luke source codes compatible with ALv2, Self-contained application package is the one of feasible options for users they do not (or cannot) install JavaFX, in my first impression. [https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html] Of course discussions and suggestions are appreciated! was (Author: tomoko uchida): As you know, in the ASF legal page, GNU GPL (including GNU Classpath exceptions) is listed in the Category X list (honestly, I read this terms yesterday and not prepared to handle such legal matters.) [https://www.apache.org/legal/resolved.html#category-x] To not to complicate matters I'd like to withdraw the merge request for now (thanks for all your comments so far!) While contributing back Luke to Apache Lucene project is our the long-term goal, we can continually deliver Luke via current GitHub project. For keeping Luke source codes compatible with ALv2, Self-contained application package is the one of feasible options for users they do not (or cannot) install JavaFX in my first impression. [https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html] Of course discussions and suggestions are appreciated! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550243#comment-16550243 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/20/18 4:55 AM: As you know, in the ASF legal page, GNU GPL (including GNU Classpath exceptions) is listed in the Category X list (honestly, I read this terms yesterday and not prepared to handle such legal matters.) [https://www.apache.org/legal/resolved.html#category-x] To not to complicate matters I'd like to withdraw the merge request for now (thanks for all your comments so far!) While contributing back Luke to Apache Lucene project is our the long-term goal, we can continually deliver Luke via current GitHub project. For keeping Luke source codes compatible with ALv2, Self-contained application package is the one of feasible options for users they do not (or cannot) install JavaFX in my first impression. [https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html] Of course discussions and suggestions are appreciated! was (Author: tomoko uchida): As you know, in the ASF legal page, GNU GPL (including GNU Classpath exceptions) is listed in the Category X list (honestly, I read this terms yesterday and not prepared to handle such legal matters.) https://www.apache.org/legal/resolved.html#category-x To not to complicated matters I'd like to withdraw the merge request for now (thanks for all your comments so far!) While contributing back Luke to Apache Lucene project is our the long-term goal, we can continually deliver Luke via current GitHub project. For keeping Luke source codes compatible with ALv2, Self-contained application package is the one of feasible options for users they do not (or cannot) install JavaFX in my first impression. https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html Of course discussions and suggestions are appreciated! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550243#comment-16550243 ] Tomoko Uchida commented on LUCENE-2562: --- As you know, in the ASF legal page, GNU GPL (including GNU Classpath exceptions) is listed in the Category X list (honestly, I read this terms yesterday and not prepared to handle such legal matters.) https://www.apache.org/legal/resolved.html#category-x To not to complicated matters I'd like to withdraw the merge request for now (thanks for all your comments so far!) While contributing back Luke to Apache Lucene project is our the long-term goal, we can continually deliver Luke via current GitHub project. For keeping Luke source codes compatible with ALv2, Self-contained application package is the one of feasible options for users they do not (or cannot) install JavaFX in my first impression. https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html Of course discussions and suggestions are appreciated! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550895#comment-16550895 ] Tomoko Uchida commented on LUCENE-2562: --- [~steve_rowe] Thank you! Hope there will be good news. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544401#comment-16544401 ] Tomoko Uchida commented on LUCENE-2562: --- Created a pull request on GitHub. Could you check it or is it better if I add a patch to the issue? https://github.com/apache/lucene-solr/pull/420 > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547494#comment-16547494 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/18/18 7:47 AM: Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I have not caught up with it. I cannot find out better solutions yet, but I'll try to look for alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functionalities and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) was (Author: tomoko uchida): Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I have not caught up with it. I cannot find out better solutions yet, but I'll try to look for alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547494#comment-16547494 ] Tomoko Uchida commented on LUCENE-2562: --- Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I did not caught up with it. I cannot find better solutions yet, but I'll try to find out alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547494#comment-16547494 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/18/18 7:44 AM: Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I did not caught up with it. I cannot find out better solutions yet, but I'll try to look for alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) was (Author: tomoko uchida): Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I did not caught up with it. I cannot find better solutions yet, but I'll try to find out alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547494#comment-16547494 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/18/18 7:46 AM: Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I have not caught up with it. I cannot find out better solutions yet, but I'll try to look for alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) was (Author: tomoko uchida): Thank you for the comments and detailed explanation. > On top of that: Starting with Java 11, JavaFX is no longer shipped with the >JDK, so forbiddenapis is correct: it's not portable. I did not caught up with it. I cannot find out better solutions yet, but I'll try to look for alternative UI framework that can go with future JDK updates. Replacing UIs should be possible because core luke functions and UI components are well separated (I hope that,) though some extra work is needed. If you have any suggestions, please let me know. :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555479#comment-16555479 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 12:14 PM: - Hi, I found a similar issue in ASF LEGAL. "Should GPL+CPE move to Cat B?" [https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-336] Seems the answer is definitely NO. When sticking to JavaFX we probably cannot donate Luke to Apache products, though I like sophisticated JavaFX API and beautiful components. I'm now planning to port the UI layer from JavaFX to Swing. Luke is getting more and more popular in GitHub users (dear committers, how many of you use Luke now?) I'm not sure why a desktop application gains popularity in the web browser era. But if many users need Luke, I think it should become an official member of Lucene in any form... was (Author: tomoko uchida): Hi, I found a similar issue in ASF LEGAL. "Should GPL+CPE move to Cat B?" [https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-336] Seems the answer is definitely NO. When sticking to JavaFX we probably cannot donate Luke to Apache products, though I like sophisticated JavaFX API and beautiful components. I'm now planning to port the UI layer from JavaFX to Swing. Luke is getting more and more popular in GitHub users (dear committers, how many of you use Luke now?) I don't know why a desktop application gains popularity in the web browser era. But if many users need Luke, I think it should become an official member of Lucene in any form... > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555479#comment-16555479 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 10:13 AM: - Hi, I found a similar issue in ASF LEGAL. "Should GPL+CPE move to Cat B?" [https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-336] Seems the answer is definitely NO. When sticking to JavaFX we probably cannot donate Luke to Apache products, though I like sophisticated JavaFX API and beautiful components. I'm now planning to port the UI layer from JavaFX to Swing. Luke is getting more and more popular in GitHub users (dear committers, how many of you use Luke now?) I don't know why a desktop application gains popularity in the web browser era. But if many users need Luke, I think it should become an official member of Lucene in any form... was (Author: tomoko uchida): Hi, I found a similar issue in ASF LEGAL. "Should GPL+CPE move to Cat B?" https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-336 Seems the answer is definitely NO. When sticking to JavaFX we probably cannot donate Luke to Apache products, though I like sophisticated JavaFX API and beautiful components. I'm now planning to port the UI layer from JavaFX to Swing. Luke is getting more and more popular in GitHub users (dear committers, how many of you use Luke now?) I don't know why a desktop application gains popularity in the web browser era. But if many users need Luke, I think it should become an official company of Lucene in any form... > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555798#comment-16555798 ] Tomoko Uchida commented on LUCENE-2562: --- [~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I am a just another web engineer, I know there are plenty of nice & light webapp frameworks...) However, I'm not sure that adding web assets (html, css, js) to Lucene, pure Java library, is acceptable. May be server side rendering (JavaScript free) is ok? I have no idea... > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555881#comment-16555881 ] Tomoko Uchida commented on LUCENE-2562: --- Sorry for unfocused comment, I have no idea about what's the best. So Swing based UI (plus web one, if someone can work for this) could be the starting point because it is not likely to obsoleted or removed from JDK at least in a while :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555881#comment-16555881 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 4:04 PM: Sorry for unfocused comment, I have no idea about what's the best. So Swing based UI (plus web one, if someone can work for this) could be the starting point because it is not likely to obsoleted or removed from JDK in a while :) was (Author: tomoko uchida): Sorry for unfocused comment, I have no idea about what's the best. So Swing based UI (plus web one, if someone can work for this) could be the starting point because it is not likely to obsoleted or removed from JDK at least in a while :) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16555798#comment-16555798 ] Tomoko Uchida edited comment on LUCENE-2562 at 7/25/18 3:34 PM: [~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I am a just another web engineer, I know there are plenty of nice & light webapp frameworks...) However, I'm not sure that adding web assets (html, css, js) to Lucene, pure Java library, is acceptable. May be server side rendering (JavaScript free) is ok? I have no idea. But web GUI perhaps get the point, when we are in a little bit dark period for client applications now. Apache Pivot, first Mark Miller introduced here, has not been updated for one year. So I've switched to JavaFX as a promising framework, this is decoupled from JDK and blocked for Apache projects (at least for now.) was (Author: tomoko uchida): [~sokolov] Thanks comments, sure, a tiny http server is always on my mind. (I am a just another web engineer, I know there are plenty of nice & light webapp frameworks...) However, I'm not sure that adding web assets (html, css, js) to Lucene, pure Java library, is acceptable. May be server side rendering (JavaScript free) is ok? I have no idea... > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556000#comment-16556000 ] Tomoko Uchida commented on LUCENE-2562: --- Sure, this is LUCENE's issue ;) > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 10m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659008#comment-16659008 ] Tomoko Uchida edited comment on LUCENE-2562 at 10/22/18 2:13 PM: - Hi, as we announced in the Lucene/Solr mailing lists, Luke was re-implemented on top of Swing. [https://github.com/DmitryKey/luke|https://github.com/DmitryKey/luke] The code is licensed under ALv2 and Swing is the part of JDK, so I think there is no obstacle to make it a Lucene submodule. I would like to create another patch and restart this issue, after just fixing styles and colors. The draft patch will be ready for review in the next few weeks or so but I am not sure about when I should cut the feature branch for it. (Seems like Lucene 8.0 release workflow will be kicked off soon.) Don't I have to care about the major version release procedure? Can you please give me some advice? Thanks. was (Author: tomoko uchida): Hi, as we announced in the Lucene/Solr mailing lists, Luke was re-implemented on top of Swing. [https://github.com/DmitryKey/luke|https://github.com/DmitryKey/luke] The code is licensed under ALv2 and Swing is the part of JDK, so I think there is no obstacle to make it a Lucene submodule. I would like to create another patch and restart this issue, after just fixing styles and colors. The draft patch will be ready for review in the next few weeks or so but I am not sure about when I should cut the feature branch for it. (Seems like Lucene 8.0 release workflow will be kicked off soon.) Can you please give me some advice? Thanks. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659056#comment-16659056
]
Tomoko Uchida commented on LUCENE-2562:
---
Hi Steve,
thank you for the quick response.
{quote}Is there something specific you're concerned about?
{quote}
No, I am just wondering that there is something I have to consider.
I will create a pull request for review after the next release, Luke 7.6.0.
(or 8.0.0?) :)
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659061#comment-16659061 ] Tomoko Uchida commented on LUCENE-2562: --- bq. Please don't wait for a release; Lucene/Solr development happens independently from release cycles. I understand, thanks! > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659008#comment-16659008 ] Tomoko Uchida edited comment on LUCENE-2562 at 10/22/18 1:51 PM: - Hi, as we announced in the Lucene/Solr mailing lists, Luke was re-implemented on top of Swing. [https://github.com/DmitryKey/luke|https://github.com/DmitryKey/luke] The code is licensed under ALv2 and Swing is the part of JDK, so I think there is no obstacle to make it a Lucene submodule. I would like to create another patch and restart this issue, after just fixing styles and colors. The draft patch will be ready for review in the next few weeks or so but I am not sure about when I should cut the feature branch for it. (Seems like Lucene 8.0 release workflow will be kicked off soon.) Can you please give me some advice? Thanks. was (Author: tomoko uchida): Hi, as we announced in the Lucene/Solr mailing lists, Luke was re-implemented on top of Swing. [https://github.com/DmitryKey/luke|http://example.com] The code is licensed under ALv2 and Swing is the part of JDK, so I think there is no obstacle to make it a Lucene submodule. I would like to create another patch and restart this issue, after just fixing styles and colors. The draft patch will be ready for review in the next few weeks or so but I am not sure about when I should cut the feature branch for it. (Seems like Lucene 8.0 release workflow will be kicked off soon.) Can you please give me some advice? Thanks. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16659008#comment-16659008 ] Tomoko Uchida commented on LUCENE-2562: --- Hi, as we announced in the Lucene/Solr mailing lists, Luke was re-implemented on top of Swing. [https://github.com/DmitryKey/luke|http://example.com] The code is licensed under ALv2 and Swing is the part of JDK, so I think there is no obstacle to make it a Lucene submodule. I would like to create another patch and restart this issue, after just fixing styles and colors. The draft patch will be ready for review in the next few weeks or so but I am not sure about when I should cut the feature branch for it. (Seems like Lucene 8.0 release workflow will be kicked off soon.) Can you please give me some advice? Thanks. > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png > > Time Spent: 20m > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674312#comment-16674312
]
Tomoko Uchida commented on LUCENE-2562:
---
I created another pull request for review, could you take a look this.
[https://github.com/apache/lucene-solr/pull/490]
I fixed the code to pass ant validation tasks, following your comments.
(This time, Luke module passes most of the validations,
validate-source-patterns, forbiddenapis, check-lib-versions and so on. Also
unit tests seem to be more stable than before.)
{quote}1. validate-source-patterns complains about non-static-final loggers:
{quote}
The code of the PR has passed {{validate-source-patterns}} on my PC (MacBook /
Java 1.8.0_181).
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
{quote}3. I think Luke should be packaged with all other artifacts in Lucene's
binary packages, but currently ant package-tgz and -zip don't include everything
{quote}
{{luke/build.xml}} in this PR creates a simple directory structure as follows
in the tgz/zip packeges.
{code:java}
$ cd lucene-8.0.0-SNAPSHOT
$ tree -L 1 luke/
luke/
├── lib
├── lucene-luke-8.0.0-SNAPSHOT.jar
├── luke.bat // this does not exist yet (TBD).
└── luke.sh
{code}
{{luke.sh}} can be launched from anywhere. The script knows classpaths
(relative paths to jars it depends on) to run. I am not sure that this launch
script is the best design choice... if there are better ways to package Luke
with Lucene, please let me know.
{code:java}
# if you are in `lucene-8.0.0` directory:
$ ./luke/luke.sh
{code}
{quote}
4. forbidden-apis is very unhappy about classes in javafx.* packages
{quote}
Besides javafx, a bunch of fixes were needed to pass the check but now it has
passed forbiddedapis check.
I have some issues to ask or consult with you.
1. Luke is a GUI tool so I think Javadoc should not be published with the
tar/zip. I have tried to disable {{javadoc}} and {{documentation-lint}} task,
but adding this lines is not working. Am I missing something?
{{documentation-lint}} is failed so it does not pass {{ant precommit}}. :/
{code:java}
{code}
2. I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
Please see [https://github.com/DmitryKey/luke/issues/125]
With the latest version of Guice (4.2.2), JDK 11 still emits the warnings.
We will be able to remove the dependency on Guice, but if possible I'd like to
use the DI framework to keep UI components and model classes loosely coupled.
(This greatly helped me when switching JavaFX to Swing, though I didn't expect
that situation.)
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679662#comment-16679662
]
Tomoko Uchida commented on LUCENE-2562:
---
{quote}I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
{quote}
Answering to myself: I looked through my code again and found that (after
dozens of refactoring,) current code of Luke does not so heavily depend on
Guice.
It's not too difficult to completely remove the dependency on Guice, if you
don't like it. :)
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679662#comment-16679662
]
Tomoko Uchida edited comment on LUCENE-2562 at 11/8/18 4:45 PM:
{quote}I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
{quote}
Answering to myself: I looked through my code again and found that (after
dozens of refactoring,) current code of Luke does not so heavily depend on
Guice.
It's not too difficult to completely remove the dependency on Guice, so let me
know if you don't like it for the project. :)
was (Author: tomoko uchida):
{quote}I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
{quote}
Answering to myself: I looked through my code again and found that (after
dozens of refactoring,) current code of Luke does not so heavily depend on
Guice.
It's not too difficult to completely remove the dependency on Guice, if you
don't like it. :)
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-2562: -- Attachment: スクリーンショット 2018-11-05 9.19.47.png > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Core > Issue Type: Task >Reporter: Mark Miller >Priority: Major > Labels: gsoc2014 > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch, > LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, > Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png, > luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png, > スクリーンショット 2018-11-05 9.19.47.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > see > "RE: Luke - in need of maintainer": > http://markmail.org/message/m4gsto7giltvrpuf > "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674565#comment-16674565
]
Tomoko Uchida commented on LUCENE-2562:
---
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
Oh, maybe I missed your intent, after compiling Luke still cannot be quickly
started from the terminal. I will deal with this (I think some ant target that
launches Luke will be needed for it.)
JFYI: For now, Luke can be launched from IDE's Run/Debug feature. I use it
when developing Luke.
!スクリーンショット 2018-11-05 9.19.47.png!
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674565#comment-16674565
]
Tomoko Uchida edited comment on LUCENE-2562 at 11/5/18 12:42 AM:
-
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
Oh, maybe I missed your intent, after compiling Luke still cannot be quickly
started from the terminal. I will deal with this (I think some ant target that
launches Luke will be needed for it.)
JFYI: For now, Luke can be launched from IDE's Run/Debug feature. I use it
when developing Luke.
!スクリーンショット 2018-11-05 9.19.47.png|width=100%!
was (Author: tomoko uchida):
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
Oh, maybe I missed your intent, after compiling Luke still cannot be quickly
started from the terminal. I will deal with this (I think some ant target that
launches Luke will be needed for it.)
JFYI: For now, Luke can be launched from IDE's Run/Debug feature. I use it
when developing Luke.
!スクリーンショット 2018-11-05 9.19.47.png!
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida commented on LUCENE-8524:
---
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary when building the dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular, individual numbers and combining diacritics are indexed
> separately (e.g., in the Cyrillic example above), which can lead to a
> performance hit on large corpora like Wiktionary or Wikipedia.
> Work around: use a character filter to get rid of combining diacritics before
> Nori processes the text. This doesn't solve the Greek, Hebrew, or English
> cases, though.
> Suggested fix: Characters in related Unicode blocks—like "Greek" and "Greek
> Extended", or "Latin" and "IPA Extensions"—should not trigger token splits.
> Combining diacritics should not trigger token splits. Non-CJK text should be
> tokenized on spaces and punctuation, not by character type shifts.
> Apostrophe-like characters should not trigger token splits (though I could
> see someone disagreeing on this one).
> B. The character "arae-a" (ㆍ, U+318D) is sometimes used instead of a middle
> dot (·, U+00B7) for
> [lists|https://en.wikipedia.org/wiki/Korean_punctuation#Differences_from_European_punctuation].
>
[jira] [Comment Edited] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida edited comment on LUCENE-8524 at 10/5/18 2:11 AM:
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file (and also unk.def if needed,) it is used for
"unknown word" handling, is sufficient, I think.
was (Author: tomoko uchida):
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular,
[jira] [Comment Edited] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida edited comment on LUCENE-8524 at 10/5/18 1:14 AM:
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
was (Author: tomoko uchida):
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary when building the dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular, individual numbers and combining diacritics are
[jira] [Updated] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8566:
--
Description:
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class factory, String... params)
- withTokenizer(Class factory, Map
params)
- addTokenFilter(Class factory, String... params)
- addTokenFilter(Class factory,
Map params)
- addCharFilter(Class factory, String... params)
- addCharFilter(Class factory, Map
params)
Since the builder also has methods which take service names, it seems like that
above methods are unnecessary and a little bit misleading. Giving symbolic
names is preferable to implementation factory classes, but for now, users can
write code depending on implementation classes.
What do you think about deprecating those methods (adding {{@Deprecated}}
annotations) and deleting them in the future releases? Those are called by only
test cases so deleting them should have no impact on current lucene/solr
codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I
missed some point. I'll close it.)
was:
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class factory, String... params)
- withTokenizer(Class factory, Map
params)
- addTokenFilter(Class factory, String... params)
- addTokenFilter(Class factory,
Map params)
- addCharFilter(Class factory, String... params)
- addCharFilter(Class factory, Map
params)
Since the builder also has methods which take service names, it seems like that
above methods are unnecessary and a little bit misleading. Giving symbolic
names is preferable to implementation factory classes, but for now, users can
write code that depending on implementation classes.
What do you think about deprecating those methods (adding {{@Deprecated}}
annotations) and deleting them in the future releases? Those are called by only
test cases so deleting them should have no impact on current lucene/solr
codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I
missed some point. I'll close it.)
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class factory, String... params)
> - withTokenizer(Class factory,
> Map params)
> - addTokenFilter(Class factory, String...
> params)
> - addTokenFilter(Class factory,
> Map params)
> - addCharFilter(Class factory, String... params)
> - addCharFilter(Class factory,
> Map params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
Tomoko Uchida created LUCENE-8566:
-
Summary: Deprecate methods in CustomAnalyzer.Builder which take
factory classes
Key: LUCENE-8566
URL: https://issues.apache.org/jira/browse/LUCENE-8566
Project: Lucene - Core
Issue Type: Improvement
Components: modules/analysis
Reporter: Tomoko Uchida
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class factory, String... params)
- withTokenizer(Class factory, Map
params)
- addTokenFilter(Class factory, String... params)
- addTokenFilter(Class factory,
Map params)
- addCharFilter(Class factory, String... params)
- addCharFilter(Class factory, Map
params)
Since the builder also has methods which take service names, it seems like that
above methods are unnecessary and a little bit misleading. Giving symbolic
names is preferable to implementation factory classes, but for now, users can
write code that depending on implementation classes.
What do you think about deprecating those methods (adding {{@Deprecated}}
annotations) and deleting them in the future releases? Those are called by only
test cases so deleting them should have no impact on current lucene/solr
codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I
missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742254#comment-16742254
]
Tomoko Uchida commented on LUCENE-2562:
---
Thank you, Uwe.
{quote}I would also favour to remove Guice, if it's easy to do.
{quote}
Yes, it should be technically easy to remove Guice though some work is needed.
Also I'd better to remove a few more libraries (ini4j and FindBugs) which are
no longer maintained.
{quote}I mentioned a small thing on the Pull Request: Please don't allow writes
to sysprops GLOBALLY!
{quote}
(If I remember right) I modified the policy file because unit tests encountered
errors come from log4j. I will try to find workarounds for it, so let me
discuss with you about the details later.
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674312#comment-16674312
]
Tomoko Uchida edited comment on LUCENE-2562 at 12/4/18 2:47 PM:
I created another pull request for review, could you take a look this.
-[https://github.com/apache/lucene-solr/pull/490]-
[https://github.com/apache/lucene-solr/pull/512]
I fixed the code to pass ant validation tasks, following your comments.
(This time, Luke module passes most of the validations,
validate-source-patterns, forbiddenapis, check-lib-versions and so on. Also
unit tests seem to be more stable than before.)
{quote}1. validate-source-patterns complains about non-static-final loggers:
{quote}
The code of the PR has passed {{validate-source-patterns}} on my PC (MacBook /
Java 1.8.0_181).
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
{quote}3. I think Luke should be packaged with all other artifacts in Lucene's
binary packages, but currently ant package-tgz and -zip don't include everything
{quote}
{{luke/build.xml}} in this PR creates a simple directory structure as follows
in the tgz/zip packeges.
{code:java}
$ cd lucene-8.0.0-SNAPSHOT
$ tree -L 1 luke/
luke/
├── lib
├── lucene-luke-8.0.0-SNAPSHOT.jar
├── luke.bat // this does not exist yet (TBD).
└── luke.sh
{code}
{{luke.sh}} can be launched from anywhere. The script knows classpaths
(relative paths to jars it depends on) to run. I am not sure that this launch
script is the best design choice... if there are better ways to package Luke
with Lucene, please let me know.
{code:java}
# if you are in `lucene-8.0.0` directory:
$ ./luke/luke.sh
{code}
{quote}4. forbidden-apis is very unhappy about classes in javafx.* packages
{quote}
Besides javafx, a bunch of fixes were needed to pass the check but now it has
passed forbiddedapis check.
I have some issues to ask or consult with you.
1. Luke is a GUI tool so I think Javadoc should not be published with the
tar/zip. I have tried to disable {{javadoc}} and {{documentation-lint}} task,
but adding this lines is not working. Am I missing something?
{{documentation-lint}} is failed so it does not pass {{ant precommit}}. :/
{code:java}
{code}
2. I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
Please see [https://github.com/DmitryKey/luke/issues/125]
With the latest version of Guice (4.2.2), JDK 11 still emits the warnings.
We will be able to remove the dependency on Guice, but if possible I'd like to
use the DI framework to keep UI components and model classes loosely coupled.
(This greatly helped me when switching JavaFX to Swing, though I didn't expect
that situation.)
was (Author: tomoko uchida):
I created another pull request for review, could you take a look this.
[https://github.com/apache/lucene-solr/pull/490]
I fixed the code to pass ant validation tasks, following your comments.
(This time, Luke module passes most of the validations,
validate-source-patterns, forbiddenapis, check-lib-versions and so on. Also
unit tests seem to be more stable than before.)
{quote}1. validate-source-patterns complains about non-static-final loggers:
{quote}
The code of the PR has passed {{validate-source-patterns}} on my PC (MacBook /
Java 1.8.0_181).
{quote}2. It should be possible to run Luke from a source checkout, but it's
not now.
{quote}
{quote}3. I think Luke should be packaged with all other artifacts in Lucene's
binary packages, but currently ant package-tgz and -zip don't include everything
{quote}
{{luke/build.xml}} in this PR creates a simple directory structure as follows
in the tgz/zip packeges.
{code:java}
$ cd lucene-8.0.0-SNAPSHOT
$ tree -L 1 luke/
luke/
├── lib
├── lucene-luke-8.0.0-SNAPSHOT.jar
├── luke.bat // this does not exist yet (TBD).
└── luke.sh
{code}
{{luke.sh}} can be launched from anywhere. The script knows classpaths
(relative paths to jars it depends on) to run. I am not sure that this launch
script is the best design choice... if there are better ways to package Luke
with Lucene, please let me know.
{code:java}
# if you are in `lucene-8.0.0` directory:
$ ./luke/luke.sh
{code}
{quote}
4. forbidden-apis is very unhappy about classes in javafx.* packages
{quote}
Besides javafx, a bunch of fixes were needed to pass the check but now it has
passed forbiddedapis check.
I have some issues to ask or consult with you.
1. Luke is a GUI tool so I think Javadoc should not be published with the
tar/zip. I have tried to disable {{javadoc}} and {{documentation-lint}} task,
but adding this lines is not working. Am I missing something?
{{documentation-lint}} is failed so it does not pass {{ant precommit}}. :/
{code:java}
{code}
2. I have noticed that Guice (cglib) has a compatibility issue with JDK9+.
Please see [https://github.com/DmitryKey/luke/issues/125]
With
[jira] [Commented] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16713006#comment-16713006
]
Tomoko Uchida commented on LUCENE-8566:
---
Thanks for the comment. I'd like to start from this,
{quote} - Add a "NAME" static public final String field to all factories{quote}
and document the SPI names in all factories' Javadoc.
Also we might need some code validator, which can be called from the
{{precommit}} build task, to make sure that each factory has the "NAME" static
field.
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class factory, String... params)
> - withTokenizer(Class factory,
> Map params)
> - addTokenFilter(Class factory, String...
> params)
> - addTokenFilter(Class factory,
> Map params)
> - addCharFilter(Class factory, String... params)
> - addCharFilter(Class factory,
> Map params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712318#comment-16712318
]
Tomoko Uchida edited comment on LUCENE-8566 at 12/7/18 4:09 AM:
[~thetaphi] I have encountered a subtle question.
{quote}Don't derive the SPI names from class name anymore (we should put them
into the classes as static final constants). By that you can add compile time
safety again (user can do FooBarFactory.NAME).
{quote}
I feel like that factory classes' static final fields are somewhat
"implementation details." (Java interfaces can have static final fields, but
current factories are not based on interfaces.) Is there a major difference
between the calls of these two builder methods.
{code:java}
// by name
CustomAnalyzer.builder().withTokenizer(FooBarFactory.NAME)
// by class
CustomAnalyzer.builder().withTokenizer(FooBarFactory.class)
{code}
Could you help me to clarify what we will achieve by this modification?
was (Author: tomoko uchida):
[~thetaphi] I have encountered a subtle question.
{quote}Don't derive the SPI names from class name anymore (we should put them
into the classes as static final constants). By that you can add compile time
safety again (user can do FooBarFactory.NAME).
{quote}
I feel like that factory classes' static final fields are somewhat
"implementation details." (Java interfaces can have static final fields, but
current factories are not based on interfaces.) Is there a major difference
between the calls of these two builder methods.
{code:java}
// by name
CustomAnalyzer.builder().withTokenizer(FooBarFactory.NAME)
// by class
CustomAnalyzer.builder().withTokenizer(FooBarFactory.class)
{code}
Could you help me to clarify what we achieve by this modification?
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class factory, String... params)
> - withTokenizer(Class factory,
> Map params)
> - addTokenFilter(Class factory, String...
> params)
> - addTokenFilter(Class factory,
> Map params)
> - addCharFilter(Class factory, String... params)
> - addCharFilter(Class factory,
> Map params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8566) Deprecate methods in CustomAnalyzer.Builder which take factory classes
[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712318#comment-16712318
]
Tomoko Uchida commented on LUCENE-8566:
---
[~thetaphi] I have encountered a subtle question.
{quote}Don't derive the SPI names from class name anymore (we should put them
into the classes as static final constants). By that you can add compile time
safety again (user can do FooBarFactory.NAME).
{quote}
I feel like that factory classes' static final fields are somewhat
"implementation details." (Java interfaces can have static final fields, but
current factories are not based on interfaces.) Is there a major difference
between the calls of these two builder methods.
{code:java}
// by name
CustomAnalyzer.builder().withTokenizer(FooBarFactory.NAME)
// by class
CustomAnalyzer.builder().withTokenizer(FooBarFactory.class)
{code}
Could you help me to clarify what we achieve by this modification?
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> --
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Assignee: Uwe Schindler
>Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class factory, String... params)
> - withTokenizer(Class factory,
> Map params)
> - addTokenFilter(Class factory, String...
> params)
> - addTokenFilter(Class factory,
> Map params)
> - addCharFilter(Class factory, String... params)
> - addCharFilter(Class factory,
> Map params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2562) Make Luke a Lucene/Solr Module
[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16697658#comment-16697658
]
Tomoko Uchida commented on LUCENE-2562:
---
Some improvements in the pull request:
1. The luke module passed ant precommit.
I examined the Javadoc linter scripts and found that excluding a specific
module when executing {{documentation-lint}} is not allowed for now. I added
missing javadocs to pass linter's check so that {{ant precommit}} is
successfully built.
2. JVM warnings when running on JDK9+ was resolved.
The warnings ("An illegal reflective access operation") was not a compatibility
issue of Guice. Guice works fine with JDK9+. I added {{--add-opens}} JVM option
in the start script to allow deep reflection. By doing so, dependency injection
works within the module system and the warnings disappears.
3. A start script for windows was added.
{{luke.bat}} was added for windows os.
Is there anything else I can do for this issue? ;D
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Mark Miller
>Priority: Major
> Labels: gsoc2014
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.patch,
> LUCENE-2562.patch, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png,
> Luke-ALE-4.png, Luke-ALE-5.png, luke-javafx1.png, luke-javafx2.png,
> luke-javafx3.png, luke1.jpg, luke2.jpg, luke3.jpg, lukeALE-documents.png,
> スクリーンショット 2018-11-05 9.19.47.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> see
> "RE: Luke - in need of maintainer":
> http://markmail.org/message/m4gsto7giltvrpuf
> "Web-based Luke": http://markmail.org/message/4xwps7p7ifltme5q
> I think it would be great if there was a version of Luke that always worked
> with trunk - and it would also be great if it was easier to match Luke jars
> with Lucene versions.
> While I'd like to get GWT Luke into the mix as well, I think the easiest
> starting point is to straight port Luke to another UI toolkit before
> abstracting out DTO objects that both GWT Luke and Pivot Luke could share.
> I've started slowly converting Luke's use of thinlet to Apache Pivot. I
> haven't/don't have a lot of time for this at the moment, but I've plugged
> away here and there over the past work or two. There is still a *lot* to do.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
