[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975354#action_12975354
]
Steven Rowe edited comment on LUCENE-2611 at 12/27/10 5:13 PM:
---------------------------------------------------------------
bq. True, but so can ant right? For example in eclipse i know there is a way to
say 'from existing ant build file' (I have done this on accident and it setup
all the classpaths etc by somehow examining our ant build)
I don't have any experience with Eclipse, but I've read that Eclipse lacks
hierarchical project layout, so although you could get a single build.xml to
work, I don't think the multilayered Lucene/Solr build would work. Have you
specifically tried with Lucene/Solr?
And AFAIK, IntelliJ can't bootstrap from an Ant build, though IntelliJ *can*
call tasks from an Ant build (the attached patch sets up this form of Ant
integration).
bq. My question about LUCENE-2657 is I don't understand its relationship to
this patch. Are you saying, if we had LUCENE-2657, then we do not need this
patch at all?
IntelliJ 9.0.4 doesn't understand all Maven build concepts. I haven't tried
with IntelliJ 10.0.1 (the most recent version). I think we need this patch if
we want full build and test functionality from IntelliJ. My concept of the
relationship between the two is that this issue hosts the ideal IntelliJ
configuration, and LUCENE-2657 hosts a Maven build which would ideally be
usable by IntelliJ (and Eclipse) to bootstrap configuration, but it's not there
(yet, and maybe never will be, not sure).
bq. Not understanding the syntax to either (they are both huge gobs of xml to
me), this one appears much easier to maintain, because the LUCENE-2657 seems to
have a lot of redundant/duplicated stuff such as system properties for running
tests in every contrib module... or is it still very much a work in progress?
I think the two issues are not mutually exclusive, at least not right now.
LUCENE-2657 is very much a work in progress. My goals with LUCENE-2657 are (in
order of importance):
# Enable people to build artifacts which can be used as dependencies in their
projects, from non-released code: trunk and branch_3x.
# Provide a replacement for the current {{ant generate-maven-artifacts}}, for
use in releases, or maybe just post-release maven repository population (I'm
not sure how it's used right now).
# Allow Solr to be started from Maven using {{jetty-maven-plugin}}: SOLR-1218
# Provide an IDE configuration bootstrap source.
Right now I'm working on building the Solr war, adding source and javadoc jar
creation, and reducing configuration duplication, e.g. the system properties
for running tests.
was (Author: steve_rowe):
bq. True, but so can ant right? For example in eclipse i know there is a
way to say 'from existing ant build file'
(I have done this on accident and it setup all the classpaths etc by somehow
examining our ant build)
I don't have any experience with Eclipse, but I've read that Eclipse lacks
hierarchical project layout, so although you could get a single build.xml to
work, I don't think the multilayered Lucene/Solr build would work. Have you
specifically tried with Lucene/Solr?
And AFAIK, IntelliJ can't bootstrap from an Ant build, though IntelliJ *can*
call tasks from an Ant build (the attached patch sets up this form of Ant
integration).
bq. My question about LUCENE-2657 is I don't understand its relationship to
this patch. Are you saying, if
we had LUCENE-2657, then we do not need this patch at all?
IntelliJ 9.0.4 doesn't understand all Maven build concepts. I haven't tried
with IntelliJ 10.0.1 (the most recent version). I think we need this patch if
we want full build and test functionality from IntelliJ. My concept of the
relationship between the two is that this issue hosts the ideal IntelliJ
configuration, and LUCENE-2657 hosts a Maven build which would ideally be
usable by IntelliJ (and Eclipse) to bootstrap configuration, but it's not there
(yet, and maybe never will be, not sure).
bq. Not understanding the syntax to either (they are both huge gobs of xml to
me), this one appears much
easier to maintain, because the LUCENE-2657 seems to have a lot of
redundant/duplicated stuff such
as system properties for running tests in every contrib module... or is it
still very much a work in progress?
I think the two issues are not mutually exclusive, at least not right now.
LUCENE-2657 is very much a work in progress. My goals with LUCENE-2657 are (in
order of importance):
# Enable people to build artifacts which can be used as dependencies in their
projects, from non-released code: trunk and branch_3x.
# Provide a replacement for the current {{ant generate-maven-artifacts}}, for
use in releases, or maybe just post-release maven repository population (I'm
not sure how it's used right now).
# Allow Solr to be started from Maven using {{jetty-maven-plugin}}: SOLR-1218
# Provide an IDE configuration bootstrap source.
Right now I'm working on building the Solr war, adding source and javadoc jar
creation, and reducing configuration duplication, e.g. the system properties
for running tests.
> 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
