>>I don't know that we have ever checked in IDE settings

GWT development is much easier with the IDE and there is a fair amount of 
manual setup required without the settings to run the "hosted" development 
environment. Hosted development is the key productivity benefit and allows 
debugging in Java (rather than building, deploying then having to debug 
Javascript). GWT provides Eclipse project generators to get started and they do 
not target other IDEs e.g. NetBeans because they claim those IDEs  typically do 
a good job of importing eclipse project settings (can't vouch for this myself, 
not having tried).  

>>Aren't they user specific at some point
No, I have taken care to ensure these IDE setting files have all directory 
names etc replaced with variables -  in the same way ANT build files use 
properties to avoid machine-specifics. 

>> In that case, then, maybe jetty should be  packaged somewhere else outside 
>> of WebLuke?

Yes, I thought that. I tried putting the only other current webapp, 
"luceneweb.war" under Jetty but it failed to do anything of interest "out of 
the box" because it requires an index to be built first. We could extend that 
app to include web-based screens to create and populate an index but I suspect 
that rapidly puts us on a development path heading towards Solr or SearchBlox.

>>Also, should this be in 2.3? 
Might be an idea to let it bed-down a little first. I'm not happy with the 
(lack of) security at present and wouldn't want naive users complaining of 
vulnerabilities introduced by its deployment.

Cheers
Mark



----- Original Message ----
From: Grant Ingersoll <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Monday, 10 December, 2007 4:59:43 PM
Subject: Re: WebLuke - include Jetty in Lucene binary distribution?

Looks good!  I especially like the visualizations and can see people  
adding more visualization capabilities as it gets used more.

I don't know that we have ever checked in IDE settings (Eclipse  
settings).  In fact, I think we have svn:ignore setup in most places  
for them.  Aren't they user specific at some point (I'm not an Eclipse
  
user, so forgive my naivete)

As for bundling Jetty, I don't have a problem with it.  Might be nice  
if the demo just fired really easily like Solr's does just by saying  
jetty -jar start.jar.  In that case, then, maybe jetty should be  
packaged somewhere else outside of WebLuke?

Also, should this be in 2.3?  Or should we wait for the next release  
so that it has a little more dev. running time?

-Grant

On Dec 9, 2007, at 4:03 PM, markharw00d wrote:

> I've got a web-based version of Luke I'm happy to commit to contrib  
> now.
> This version includes some tidy up for developers working on Luke.  
> Eclipse .project and .classpath files have build path variables  
> defined to cater for different install locations for GWT in  
> development environments.
>
> Full code is currently here:
 http://www.inperspective.com/lucene/webluke.zip 
>   (17 mb)
> Unzip to "contrib" directory and run the usual ant build or import  
> project into Eclipse, set build path variables, clean project, and  
> run from there.
>
> The only open question is if we should bundle Jetty in the Lucene  
> binary distribution as part of the build packaging. This could be  
> used to launch both WebLuke and the existing luceneweb.war but adds  
> about 6 or 7 meg to the overall zipped download size.
>
> Thoughts?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to