[
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: [email protected]
For additional commands, e-mail: [email protected]
