[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975327#action_12975327
]
Steven Rowe edited comment on LUCENE-2611 at 12/27/10 3:28 PM:
---------------------------------------------------------------
bq. 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.
I set up this patch to copy in the IntelliJ configuration files from another
location ({{dev-tools/idea/}}), and {{svn:ignore}} the in-place config files,
because each user will add/subtract stuff to the configuration -- if the
in-place config files were committed to the Lucene repo, every {{svn update}}
would require merging with the remote version, and every {{svn commit}} would
put the current state of the committer's config files into the repo. Both of
those are bad, and both are avoided with my approach.
bq. Can we figure out some plan to make it really easy to get going in these
two IDEs, with minimal maintenance?
Maven POMs can be used by both to bootstrap projects: LUCENE-2657. I've never
tried with Eclipse, though. And IntelliJ doesn't grok everything, e.g.
multiple content roots.
bq. 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 went through the process of adding a new solr contrib module here when you
added {{analysis-extras}}. The effort was fairly small, maybe 2-3 hours,
including copy/pasting/modifying an existing contrib's configuration and adding
it to the project config in various places, then running all defined module
tests. I think most of this could be scripted, which would seriously reduce
the effort. I'll look at that the next time the code base is restructured. At
a minimum, of course, there should be documentation on how to make changes.
bq. 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.
+1. I think since my approach would have zero impact on non-users, this is the
only potentially blocking concern.
was (Author: steve_rowe):
bq. 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.
I set up this patch to copy in the IntelliJ configuration files from another
location ({{dev-tools/idea/}} (and {{svn:ignore}} the in-place config files),
because each user will add/subtract stuff to the configuration -- if the
in-place config files were committed to the Lucene repo, every {{svn update}}
would require merging with the remote version, and every {{svn commit}} would
put the current state of the committer's config files into the repo. Both of
those are bad, and both are avoided with my approach.
bq. Can we figure out some plan to make it really easy to get going in these
two IDEs, with minimal maintenance?
Maven POMs can used by both to bootstrap projects: LUCENE-2657. I've never
tried with Eclipse, though. And IntelliJ doesn't grok everything, e.g.
multiple content roots.
bq. 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 went through the process of adding a new solr contrib module here when you
added {{analysis-extras}}. The effort was fairly small, maybe 2-3 hours,
including copy/pasting/modifying an existing contrib's configuration and adding
it to the project config in various places, then running all defined module
tests. I think most of this could be scripted, which would seriously reduce
the effort. I'll look at that the next time the code base is restructured. At
a minimum, of course, there should be documentation on how to make changes.
bq. 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.
+1. I think since my approach would have zero impact on non-users, this is the
only potentially blocking concern.
> 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
