[ 
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975301#action_12975301
 ] 

Robert Muir commented on LUCENE-2611:
-------------------------------------

Just a few thoughts/general questions:
# First of all, I think we really need to pursue making it easier to setup your 
development environment to attract more contributors. I personally find it 
difficult to use an IDE (at the moment I use 'ant test' but edit code with 
eclipse's editor, so that i get syntax completion etc). But at the moment 
setting up something that works is too high of a barrier to entry, it might 
sound extreme to say this, but I think we are basically discouraging 
contributors with the complexity.
# As far as making it easier for any particular IDE, my opinion is: as long as 
someone maintains it. But If i (or someone else) want to go re-organize the 
whole build and the consensus is that its a good change, I think the only thing 
that must work is the ant build. So the danger is that we will only have 
non-functional out-of-date IDE support... we don't want to slow down 
development either by requiring someone to fix ant, maven, eclipse, intellij, 
netbeans emacs, make, .vimrc, whatever. But on the other hand, what we have now 
is 'not working' in my opinion. 
# I think (just off the top of my head) that a lot of new contributors will 
likely be using intellij or eclipse, and that these are the two big ones. I 
know uwe uses notepad and mike uses emacs, but i think these seem to be the 
most popular. I'm not trying to say we have to show bias/preference towards 
these two, but I think we need to address the reality and lower the barrier to 
entry. Can we figure out some plan to make it really easy to get going in these 
two IDEs, with minimal maintenance? I don't think we should necessarily exclude 
checking in the project files into svn either, if thats what it takes. it seems 
this would be lesser than the evil we have now. And of course, an alternative 
might be to do what this patch does, and also make a similar patch for eclipse 
too.
# For intellij, how hard would be it to maintain this support if its committed? 
As a theoretical example, what would need to be done if we were to factor out 
the function queries from lucene and solr and combine them into a new module 
that solr depends on (and perhaps the lucene queryparsers contrib would depend 
on it two with some parsing support) ? 
# I guess with the concerns about maintenance, if nobody maintains the files 
then they arent using those IDEs and perhaps we could agree that if stuff like 
this got really out of date we would just delete it.

Anyway, I just wanted to voice my support for the idea and get some discussion 
going as I would really like to see this situation simplified sooner than later.


> IntelliJ IDEA setup
> -------------------
>
>                 Key: LUCENE-2611
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2611
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Build
>    Affects Versions: 3.1, 4.0
>            Reporter: Steven Rowe
>            Priority: Minor
>             Fix For: 3.1, 4.0
>
>         Attachments: LUCENE-2611-branch-3x.patch, 
> LUCENE-2611-branch-3x.patch, LUCENE-2611-branch-3x.patch, 
> LUCENE-2611-branch-3x.patch, LUCENE-2611.patch, LUCENE-2611.patch, 
> LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, LUCENE-2611.patch, 
> LUCENE-2611.patch, LUCENE-2611_mkdir.patch, LUCENE-2611_test.patch, 
> LUCENE-2611_test.patch, LUCENE-2611_test.patch, LUCENE-2611_test.patch, 
> LUCENE-2611_test_2.patch
>
>
> Setting up Lucene/Solr in IntelliJ IDEA can be time-consuming.
> The attached patch adds a new top level directory {{dev-tools/}} with sub-dir 
> {{idea/}} containing basic setup files for trunk, as well as a top-level ant 
> target named "idea" that copies these files into the proper locations.  This 
> arrangement avoids the messiness attendant to in-place project configuration 
> files directly checked into source control.
> The IDEA configuration includes modules for Lucene and Solr, each Lucene and 
> Solr contrib, and each analysis module.  A JUnit test run per module is 
> included.
> Once {{ant idea}} has been run, the only configuration that must be performed 
> manually is configuring the project-level JDK.
> If this patch is committed, Subversion svn:ignore properties should be 
> added/modified to ignore the destination module files (*.iml) in each 
> module's directory.
> Iam Jambour has written up on the Lucene wiki a detailed set of instructions 
> for applying the 3.X branch patch: 
> http://wiki.apache.org/lucene-java/HowtoConfigureIntelliJ

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to