[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=16819550#comment-16819550
]
Tomoko Uchida edited comment on LUCENE-2562 at 4/16/19 10:22 PM:
-
Thanks for the comment, [~thetaphi].
I would like to add a notice, "For HiDPI graphics on Windows/Linux, Java 11 or
grater is recommended to run the bundled GUI application Luke." to right after
the first line ("Apache Lucene runs on Java 8 or greater.") in
SYSTEM_REQUIREMENTS.txt.
{quote}You can print a warning (using the Constants.JDK_IS_MINIMUM_JAVA11
field) in the log file.
{quote}
OK, I will print some message in the footer bar or log file, if there are APIs
to detect the display resolution.
Why I thought of adding notes to the user interface, users are not necessarily
realize that the graphical problem relates to Java version they use. (Not long
ago a user opened an issue titled "UI problem" in the github repo, even though
I mentioned about this in the download page :) )
was (Author: tomoko uchida):
Thanks for the comment, [~thetaphi].
I would like to add a notice "For HiDPI graphics on Windows/Linux, Java 11 or
grater is required to run the bundled GUI application Luke." to right after the
first line ("Apache Lucene runs on Java 8 or greater.") in
SYSTEM_REQUIREMENTS.txt.
> You can print a warning (using the Constants.JDK_IS_MINIMUM_JAVA11 field) in
> the log file.
OK, I will print some message in the footer bar or log file, if there are APIs
to detect the display resolution.
Why I thought of adding notes to the user interface, users are not necessarily
realize that the graphical problem relates to Java version they use. (Not long
ago a user opened an issue titled "UI problem" in the github repo, even though
I mentioned about this in the download page :) )
> Make Luke a Lucene/Solr Module
> --
>
> Key: LUCENE-2562
> URL: https://issues.apache.org/jira/browse/LUCENE-2562
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/luke
>Reporter: Mark Miller
>Assignee: Tomoko Uchida
>Priority: Major
> Labels: gsoc2014
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.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, screenshot-1.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=16816300#comment-16816300
]
Tomoko Uchida edited comment on LUCENE-2562 at 4/12/19 2:17 PM:
{quote}Tomoko Uchida: can you just fix the above code and commit that, too. You
just need to add "luke".
{quote}
I added 'luke' to the line:
[https://github.com/apache/lucene-solr/commit/f85819985b5a9c0c10c0e810c1826cd40be735d2]
(did not do any confirmation, just fixed the python code...)
was (Author: tomoko uchida):
bq. Tomoko Uchida: can you just fix the above code and commit that, too. You
just need to add "luke".
I added 'luke' to the line:
https://github.com/apache/lucene-solr/commit/f85819985b5a9c0c10c0e810c1826cd40be735d2
(did not do any confirmation, just fix the python code...)
> 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
>Assignee: Tomoko Uchida
>Priority: Major
> Labels: gsoc2014
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch,
> LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.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, screenshot-1.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=16816269#comment-16816269
]
Steve Rowe edited comment on LUCENE-2562 at 4/12/19 1:36 PM:
-
The smoke tester failed for a non-Maven-related reason:
{noformat}
[smoker] Test Lucene...
[smoker] verify sha512 digest
[smoker] unpack lucene-9.0.0.tgz...
[smoker] Traceback (most recent call last):
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1518, in
[smoker] main()
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1448, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, c.local_keys, ' '.join(c.test_args))
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1499, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, artifact, gitRevision,
version, testArgs, baseURL)
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line 604,
in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
gitRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line 679,
in verifyUnpacked
[smoker] raise RuntimeError('%s: unexpected files/dirs in artifact %s:
%s' % (project, artifact, l))
[smoker] RuntimeError: lucene: unexpected files/dirs in artifact
lucene-9.0.0.tgz: ['luke']
{noformat}
Sorry, I don't have time right now to work on it, but I will have time this
weekend if nobody beats me to it.
FYI, I expect there will be a Maven-related problem with the smoke tester -
here's what I think will be the problem (from {{smokeTestRelease.py}}) -
probably just need to introduce an exception list:
{noformat}
def verifyPOMperBinaryArtifact(artifacts, version):
print('verify that each binary artifact has a deployed POM...')
reBinaryJarWar = re.compile(r'%s\.[jw]ar$' % re.escape(version))
for project in ('lucene', 'solr'):
for artifact in [a for a in artifacts[project] if reBinaryJarWar.search(a)]:
POM = artifact[:-4] + '.pom'
if POM not in artifacts[project]:
raise RuntimeError('missing: POM for %s' % artifact)
{noformat}
was (Author: steve_rowe):
The smoke tester failed for a non-Maven-related reason:
{noformat}
[smoker] Test Lucene...
[smoker] verify sha512 digest
[smoker] unpack lucene-9.0.0.tgz...
[smoker] Traceback (most recent call last):
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1518, in
[smoker] main()
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1448, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
c.is_signed, c.local_keys, ' '.join(c.test_args))
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line
1499, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, artifact, gitRevision,
version, testArgs, baseURL)
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line 604,
in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath,
gitRevision, version, testArgs, tmpDir, baseURL)
[smoker] File
"/home/sarowe/git/lucene-solr/dev-tools/scripts/smokeTestRelease.py", line 679,
in verifyUnpacked
[smoker] raise RuntimeError('%s: unexpected files/dirs in artifact %s:
%s' % (project, artifact, l))
[smoker] RuntimeError: lucene: unexpected files/dirs in artifact
lucene-9.0.0.tgz: ['luke']
{noformat}
Sorry, I don't have time right now to work on it, but I will have time this
weekend if nobody beats me to it.
FYI, I expect there will be a Maven-related problem with the smoke tester -
here's what I think will be the problem (from {{smokeTestRelease.py}} -
probably just need to introduce an exception list:
{noformat}
def verifyPOMperBinaryArtifact(artifacts, version):
print('verify that each binary artifact has a deployed POM...')
reBinaryJarWar = re.compile(r'%s\.[jw]ar$' % re.escape(version))
for project in ('lucene', 'solr'):
for artifact in [a for a in artifacts[project] if reBinaryJarWar.search(a)]:
POM = artifact[:-4] + '.pom'
if POM not in artifacts[project]:
raise RuntimeError('missing: POM for %s' % artifact)
{noformat}
> 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
>Assignee: Tomoko Uchida
>Priority: Major
>
[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=16816261#comment-16816261 ] Uwe Schindler edited comment on LUCENE-2562 at 4/12/19 1:30 PM: bq. and a 301 HTTP code (permanently relocated), That's a bug in Java, which wont be fixed. The Java HTTP as shipped with JDK behind the URL class does not follow redirects between different HTTP protocols, so it won't move from http to https. Thats a known issue: [https://bugs.openjdk.java.net/browse/JDK-4620571?focusedCommentId=12159233=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12159233] This makes me really angry as its against HTTP spec, but Oracle/SUN never implemented it for some fake security reasons. In fact HTTP->HTTPS is legit, just the other way round is not. Not sure we need a workaround for that, but that's a separate issue. was (Author: thetaphi): bq. and a 301 HTTP code (permanently relocated), That's a bug in Java, which wont be fixed. The Java HTTP as shipped with JDK behind the URL class does not follow redirects between different HTTP protocols, so it won't move from http to https. Thats a known issue: [https://bugs.openjdk.java.net/browse/JDK-4620571?focusedCommentId=12159233=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12159233] This makes me angry as its against HTTP spec, but Oracle/SUn never implemented it for some fake security reasons. In fact HTTP->HTTPS is legt, just the otehr way round is not. > 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 >Assignee: Tomoko Uchida >Priority: Major > Labels: gsoc2014 > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-2562-Ivy.patch, LUCENE-2562-Ivy.patch, > LUCENE-2562-Ivy.patch, LUCENE-2562-ivy.patch, LUCENE-2562.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, screenshot-1.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=16816237#comment-16816237
]
Steve Rowe edited comment on LUCENE-2562 at 4/12/19 1:06 PM:
-
[~thetaphi]: I didn't think of running the smoke tester; I'm not sure
whether/how Maven artifact validation checks artifact correspondence, I'll run
it locally on the branch now that Tomoko has updated it.
[~Tomoko Uchida]: I saw that same problem, as did Kevin Risden [over on
SOLR-9515|https://jira.apache.org/jira/browse/SOLR-9515?focusedCommentId=16762835=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16762835].
AFAICT this happens when you have a local maven repo that you haven't used the
Lucene/Solr Maven build with, but which is populated by the Lucene/Solr Ant
build via the Maven Ant Tasks plugin. Earlier in the log I see:
{noformat}
[artifact:dependencies] Downloading:
com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom from
repository taglets at http://maven.geotoolkit.org/
[artifact:dependencies] Transferring 0K from taglets
[artifact:dependencies] [WARNING] *** CHECKSUM FAILED - Checksum failed on
download: local = 'c53d5de1975ce58462f226d7ed126e02d8f1f58b'; remote = '
[artifact:dependencies] 301' - RETRYING
{noformat}
So (for me anyway) what happened was that a Maven repository we don't specify
(probably specified in the jackcess POM hierarchy) returned an HTML page and a
301 HTTP code (permanently relocated), which is improperly interpreted by Maven
Ant Tasks as the appropriate artifact and saved as if it were the jackcess
parent POM. I worked around this by deleting the local repo's bad file, then
installing the correct POM manually:
{noformat}
rm
~/.m2/repository/com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom
curl -O
https://repo1.maven.org/maven2/com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom
mvn install:install-file -Dfile=openhms-parent-1.1.8.pom
-DgroupId=com.healthmarketscience -DartifactId=openhms-parent -Dversion=1.1.8
-Dpackaging=pom
{noformat}
Maybe there's a better way? (E.g. running the Maven build in this context?)
The above fixed the problem for me. (Maven Ant Tasks have been EOL'd for a few
years, so there will be no fix for this problem in that project.)
was (Author: steve_rowe):
[~thetaphi]: I didn't think of running the smoke tester; I'm not sure
whether/how Maven artifact validation looks at , I'll run it locally on the
branch now that Tomoko has updated it.
[~Tomoko Uchida]: I saw that same problem, as did Kevin Risden [over on
SOLR-9515|https://jira.apache.org/jira/browse/SOLR-9515?focusedCommentId=16762835=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16762835].
AFAICT this happens when you have a local maven repo that you haven't used the
Lucene/Solr Maven build with, but which is populated by the Lucene/Solr Ant
build via the Maven Ant Tasks plugin. Earlier in the log I see:
{noformat}
[artifact:dependencies] Downloading:
com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom from
repository taglets at http://maven.geotoolkit.org/
[artifact:dependencies] Transferring 0K from taglets
[artifact:dependencies] [WARNING] *** CHECKSUM FAILED - Checksum failed on
download: local = 'c53d5de1975ce58462f226d7ed126e02d8f1f58b'; remote = '
[artifact:dependencies] 301' - RETRYING
{noformat}
So (for me anyway) what happened was that a Maven repository we don't specify
(probably specified in the jackcess POM hierarchy) returned an HTML page and a
301 HTTP code (permanently relocated), which is improperly interpreted by Maven
Ant Tasks as the appropriate artifact and saved as if it were the jackcess
parent POM. I worked around this by deleting the local repo's bad file, then
installing the correct POM manually:
{noformat}
rm
~/.m2/repository/com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom
curl -O
https://repo1.maven.org/maven2/com/healthmarketscience/openhms-parent/1.1.8/openhms-parent-1.1.8.pom
mvn install:install-file -Dfile=openhms-parent-1.1.8.pom
-DgroupId=com.healthmarketscience -DartifactId=openhms-parent -Dversion=1.1.8
-Dpackaging=pom
{noformat}
Maybe there's a better way? (E.g. running the Maven build in this context?)
The above fixed the problem for me. (Maven Ant Tasks have been EOL'd for a few
years, so there will be no fix for this problem in that 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
>Assignee: Tomoko Uchida
>Priority: Major
> Labels: gsoc2014
> Fix For: 8.1, master (9.0)
>
>
[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=16813296#comment-16813296
]
Uwe Schindler edited comment on LUCENE-2562 at 4/9/19 11:50 AM:
Hi [~Tomoko Uchida],
I prepared the branch to be squash-merged. Once you have your ASF account, I
would propose that you do the last step on your own. Here is the steps to do it:
- Checkout the branch from ASF gitbox (or use your own one from Github), does
not matter. Be sure to pull latest updates!!!
- Make sure to configure the GIT checkout to use your {{@apache) mail address
for commits (it's also wise to add it as an alias to github, so Github and ASF
bots can identify you as the same person). It may be wise to make the mail
address the default for all Lucene checkouts you maintain. Also it's wise to
have "origin" set to ASF gitbox and Github as alternative remote (e.g.,
"mocobeta")
- Switch back to master. Be sure to pull latest updatesfrom ASF gitbox!!!
- Run: {{git merge --squash jira/lucene-2562-luke-swing-3}}
- Commit the stuff with a useful commit message: {{git commit -m 'LUCENE-2562:
Add Luke as a Lucene module'}}
- Push changes
- Switch to branch "branch_8x" (the 8.x development branch)
- Cherry-pick the previous commit from master branch, or alternatively do the
same squashing merge.
- Push changes
Good luck - I am here for help.
Uwe
was (Author: thetaphi):
Hi [~Tomoko Uchida],
I prepared the branch to be squash-merged. Once you have your ASF account, I
would propose that you do the last step on your own. Here is the steps to do it:
- Checkout the branch from ASF gitbox (or use your own one from Github), does
not matter. Be sure to pull latest updates!!!
- Make sure to configure the GIT checkout to use your {{@apache) mail address
for commits (it's also wise to add it as an alias to github, so Github and ASF
bots can identify you as the same person). It may be wise to make the mail
address the default for all Lucene checkouts you maintain. Also it's wise to
have "origin" set to ASF gitbox and Github as alternative remote (e.g.,
"mocobeta")
- Switch back to master
- Run: {{git merge --squash jira/lucene-2562-luke-swing-3}}
- Commit the stuff with a useful commit message: {{git commit -m 'LUCENE-2562:
Add Luke as a Lucene module'}}
- Push changes
- Switch to branch "branch_8x" (the 8.x development branch)
- Cherry-pick the previous commit from master branch, or alternatively do the
same squashing merge.
- Push changes
Good luck - I am here for help.
Uwe
> 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
>Assignee: Tomoko Uchida
>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, 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, screenshot-1.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=16813296#comment-16813296
]
Uwe Schindler edited comment on LUCENE-2562 at 4/9/19 11:49 AM:
Hi [~Tomoko Uchida],
I prepared the branch to be squash-merged. Once you have your ASF account, I
would propose that you do the last step on your own. Here is the steps to do it:
- Checkout the branch from ASF gitbox (or use your own one from Github), does
not matter. Be sure to pull latest updates!!!
- Make sure to configure the GIT checkout to use your {{@apache) mail address
for commits (it's also wise to add it as an alias to github, so Github and ASF
bots can identify you as the same person). It may be wise to make the mail
address the default for all Lucene checkouts you maintain. Also it's wise to
have "origin" set to ASF gitbox and Github as alternative remote (e.g.,
"mocobeta")
- Switch back to master
- Run: {{git merge --squash jira/lucene-2562-luke-swing-3}}
- Commit the stuff with a useful commit message: {{git commit -m 'LUCENE-2562:
Add Luke as a Lucene module'}}
- Push changes
- Switch to branch "branch_8x" (the 8.x development branch)
- Cherry-pick the previous commit from master branch, or alternatively do the
same squashing merge.
- Push changes
Good luck - I am here for help.
Uwe
was (Author: thetaphi):
Hi [~Tomoko Uchida],
I prepared the branch to be squash-merged. Once you have your ASF account, I
would propose that you do the last step on your own. Here is the steps to do it:
- Checkout the branch from ASF gitbox (or use your own one from Github), does
not matter.
- Make sure to configure the GIT checkout to use your {{@apache) mail address
for commits (it's also wise to add it as an alias to github, so Github and ASF
bots can identify you as the same person). It may be wise to make the mail
address the default for all Lucene checkouts you maintain. Also it's wise to
have "origin" set to ASF gitbox and Github as alternative remote (e.g.,
"mocobeta")
- Switch back to master
- Run: {{git merge --squash jira/lucene-2562-luke-swing-3}}
- Commit the stuff with a useful commit message: {{git commit -m 'LUCENE-2562:
Add Luke as a Lucene module'}}
- Push changes
- Switch to branch "branch_8x" (the 8.x development branch)
- Cherry-pick the previous commit from master branch, or alternatively do the
same squashing merge.
- Push changes
Good luck - I am here for help.
Uwe
> 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
>Assignee: Tomoko Uchida
>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, 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, screenshot-1.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=16810126#comment-16810126
]
Uwe Schindler edited comment on LUCENE-2562 at 4/4/19 5:23 PM:
---
The SecuirtyException is a bug in Log4J: I have whitespace in my path name and
when loading the file it incorrectly gets the url-encoded path. It would fail
anyways later (with a FileNotFoundError)! The bug is in
{{org.apache.logging.log4j.core.util.FileUtils.fileFromUri}}:
https://logging.apache.org/log4j/2.0/log4j-core/apidocs/src-html/org/apache/logging/log4j/core/util/FileUtils.html#line.62
That's brokenness as mentioned in the comment above the method! God damn...
Keep in mind that our Jenkins servers are partially also using whitespace in
path names exactly to test those issues.
was (Author: thetaphi):
The SecuirtyException is a bug in Log4J: I have whitespace in my path name and
when loading the file it incorrectly gets the path. It would fail anyways later
(with a FileNotFoundError)! The bug is in
{{org.apache.logging.log4j.core.util.FileUtils.fileFromUri}}:
https://logging.apache.org/log4j/2.0/log4j-core/apidocs/src-html/org/apache/logging/log4j/core/util/FileUtils.html#line.62
That's brokenness as mentioned in the comment above the method! God damn...
Keep in mind that our Jenkins servers are partially also using whitespace in
path names exactly to test those issues.
> 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
>Assignee: Uwe Schindler
>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,
> screenshot-1.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=16810041#comment-16810041
]
Uwe Schindler edited comment on LUCENE-2562 at 4/4/19 4:51 PM:
---
When running tests, I get:
{noformat}
[junit4]> Caused by: java.security.AccessControlException: access denied
("java.io.FilePermission"
"C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\lucene\build\luke\classes\test\log4j2-test.xml"
"read")
[junit4]>at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
[junit4]>at
java.security.AccessController.checkPermission(AccessController.java:884)
[junit4]>at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
[junit4]>at
java.lang.SecurityManager.checkRead(SecurityManager.java:888)
[junit4]>at java.io.File.exists(File.java:814)
[junit4]>at
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
[junit4]>at
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
[junit4]>at
org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
[junit4]>at
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
[junit4]>at
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:382)
[junit4]>at
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
[junit4]>at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
[junit4]>at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
[junit4]>at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
[junit4]>at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
[junit4]>at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
[junit4]>at
org.apache.logging.log4j.LogManager.getContext(LogManager.java:155)
[junit4]>at
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
[junit4]>at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
[junit4]>at
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
[junit4]>at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
[junit4]>at
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
[junit4]>at
org.apache.lucene.luke.models.commits.CommitsImpl.(CommitsImpl.java:44)
[junit4]>... 37 more
{noformat}
was (Author: thetaphi):
When running tests, I get:
{noformat}
[junit4]> Caused by: java.security.AccessControlException: access denied
("java.io.FilePermission"
"C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\lucene\build\luke\classes\test\log4j2-test.xml"
"read")
[junit4]>at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
[junit4]>at
java.security.AccessController.checkPermission(AccessController.java:884)
[junit4]>at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
[junit4]>at
java.lang.SecurityManager.checkRead(SecurityManager.java:888)
[junit4]>at java.io.File.exists(File.java:814)
[junit4]>at
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
{noformat}
> 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
>Assignee: Uwe Schindler
>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,
> screenshot-1.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
[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=16810032#comment-16810032 ] Uwe Schindler edited comment on LUCENE-2562 at 4/4/19 4:23 PM: --- The start files in bin are intended to only work in the binary release ZIP, right? I have another suggestion, but we can delay that to later: We should not ship the resources directories "img" and "font" and the messages files in the root folder of the JAR file and instead move them to "org.apache.lucene.luke.(img|font|messages)", also load them using a relative path instead of a full path in the code (use Class.getResource with a relative path). And I'd also suggest to not put the log4j2.xml file with its default name into the JAR file. If some user adds all jar files from the Lucene ZIP file to his classpath (some users do this, I see it every day), he will import that log4j config file and break his project. As the logging is handled inside the app, I'd suggest to move the config file also to Luke's package and load it explicitely with Log4J bootstrapping in the main() method. Otherwise I am happy now :-) was (Author: thetaphi): The start files in bin are intended to only work in the binary release ZIP, right? I have another suggestion, but we can delay that to later: We should not ship the resources directories "img" and "font" in the root folder of the JAR file and instead move them to "org.apache.lucene.luke.(img|font)", also load them using a relative path instead of a full path in the code (use Class.getResource with a relative path). And I'd also suggest to not put the log4j2.xml file with its default name into the JAR file. If some user adds all jar files from the Lucene ZIP file to his classpath (some users do this, I see it every day), he will import that log4j config file and break his project. As the logging is handled inside the app, I'd suggest to move the config file also to Luke's package and load it explicitely with Log4J bootstrapping in the main() method. Otherwise I am happy now :-) > 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 >Assignee: Uwe Schindler >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, > screenshot-1.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=16809979#comment-16809979 ] Uwe Schindler edited comment on LUCENE-2562 at 4/4/19 3:33 PM: --- One small thing: why do you compare the "class names" near isAssignableFrom(). I think it's enough to use Objects.equals(class1, class2) - because 2 classes with same name can still be different (not in this case, but in general, e.g. for compiled expressions in Lucene). I can't really review the GUI code as I have no idea about Swing and AWT, I just trust you that it confirms to standards. :-) was (Author: thetaphi): One small thing: why do you compare the "class names" near isAssignableFrom(). I think it's enough to use Objects.equals(class1, class2) - because 2 classes with same name can still be different (not in this case, but in general, e.g. for compiled expressions in Lucene). I can really review the GUI code as I have no idea about Swing and AWT, I just trust you that it confirms to standards. :-) > 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 >Assignee: Uwe Schindler >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, > screenshot-1.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=16809979#comment-16809979 ] Uwe Schindler edited comment on LUCENE-2562 at 4/4/19 3:32 PM: --- One small thing: why do you compare the "class names" near isAssignableFrom(). I think it's enough to use Objects.equals(class1, class2) - because 2 classes with same name can still be different (not in this case, but in general, e.g. for compiled expressions in Lucene). I can really review the GUI code as I have no idea about Swing and AWT, I just trust you that it confirms to standards. :-) was (Author: thetaphi): One small thing: why do you compare the "class names" near isAssignableFrom(). I think it's enough to use Objects.euals(class1, class2) - because 2 classes with same name can still be different (not in this case, but in general, e.g. for compiled expressions in Lucene) > 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 >Assignee: Uwe Schindler >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, > screenshot-1.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=16741609#comment-16741609
]
Tomoko Uchida edited comment on LUCENE-2562 at 1/13/19 4:49 PM:
I will remove the dependency to Guice so that the {{--add-opens}} option can be
removed.
(I might be wrong..., but in my understanding Luke can safely use the
dependency injection framework without this special option if we modularize
Lucene in the Jigsaw's way and open only luke module to Guice, but it should
not be a viable option for now.)
If there are any other obstacles to merge the patch please point them out to
me. I will fix it following your review.
was (Author: tomoko uchida):
I will remove the dependency to Guice so that the {{--add-options}} option can
be removed.
(I might be wrong..., but in my understanding Luke can safely use the
dependency injection framework without this special option if we modularize
Lucene in the Jigsaw's way and open only luke module to Guice, but it should
not be a viable option for now.)
If there are any other obstacles to merge the patch please point them out to
me. I will fix it following your review.
> 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] [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] [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] [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] [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] [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] [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] [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=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] [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=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] [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] [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=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=16547192#comment-16547192 ] Uwe Schindler edited comment on LUCENE-2562 at 7/17/18 11:02 PM: - On top of that: Starting with Java 11, JavaFX is no longer shipped with the JDK, so forbiddenapis is correct: it's not portable. See https://www.infoworld.com/article/3261066/java/javafx-will-be-removed-from-the-java-jdk.html was (Author: thetaphi): On top of that: Starting with Java 11, JavaFX is no longer shipped with the JDK, so forbiddenapis is correct: it's not portable. > 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=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] [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] [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] [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=13750277#comment-13750277 ] Ajay Bhat edited comment on LUCENE-2562 at 8/26/13 5:31 PM: Re:[~markrmil...@gmail.com] and everyone else, I've done a very small patch, but I'm still facing some problems. I've checked the Analyzers in the tool manually, and these Analyzers give the java.lang.InstantiationException when used. org.apache.lucene.analysis.miscellaneous.LimitTokenCountAnalyzer org.apache.lucene.analysis.miscellaneous.PatternAnalyzer org.apache.lucene.analysis.query.QueryAutoStopWordAnalyzer org.apache.lucene.analysis.snowball.SnowballAnalyzer org.apache.lucene.collation.CollationKeyAnalyzer org.apache.lucene.solr.analysis.TokenizerChain I'm a bit confused because as of Lucene 4.0alpha, the PatternAnalyzer is deprecated from misc package, but it's still present here in miscellaneous package in Lucene 4.4 release. was (Author: ajay bhat): I've done a very small patch, but I'm still facing some problems. I've checked the Analyzers in the tool manually, and these Analyzers give the java.lang.InstantiationException when used. org.apache.lucene.analysis.miscellaneous.LimitTokenCountAnalyzer org.apache.lucene.analysis.miscellaneous.PatternAnalyzer org.apache.lucene.analysis.query.QueryAutoStopWordAnalyzer org.apache.lucene.analysis.snowball.SnowballAnalyzer org.apache.lucene.collation.CollationKeyAnalyzer org.apache.lucene.solr.analysis.TokenizerChain I'm a bit confused because as of Lucene 4.0alpha, the PatternAnalyzer is deprecated, but it's still present here in miscellaneous package in Lucene 4.4. 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: gsoc2013 Attachments: LUCENE-2562.patch, luke1.jpg, luke2.jpg, luke3.jpg, Luke-ALE-1.png, Luke-ALE-2.png, Luke-ALE-3.png, Luke-ALE-4.png, Luke-ALE-5.png see http://search.lucidimagination.com/search/document/ee0e048c6b56ee2/luke_in_need_of_maintainer http://search.lucidimagination.com/search/document/5e53136b7dcb609b/web_based_luke 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
