[
https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810137#comment-16810137
]
Tomoko Uchida commented on LUCENE-2562:
---------------------------------------
{quote}The start files in bin are intended to only work in the binary release
ZIP, right?
{quote}
Yes, I think it's OK because developers can launch Luke by {{ant launch}}
command. Do you have any concerns about this?
bq. 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).
bq. 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.
bq. How about the following suggestion - also related to my issue with shipping
a log4j2.xml in the root folder of the JAR file and the more or less static
config: Can we not remove the log4j config files completely and instead
hardcode the "textarea" appender in the startup code of the application. There
is no reason to have a config file, just configure log4j as part of startup.
Thanks, I will update the PR as suggested.
> 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
