[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
