[ 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