[ 
https://issues.apache.org/jira/browse/LUCENE-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Rowe updated LUCENE-5930:
-------------------------------
    Attachment: LUCENE-5930.failed.intellij.map-reduce.module.test.output.txt
                LUCENE-5930.patch

{quote}
bq. I'll go test every single module now and see how the pattern affects them, 
and then apply it. Yay.

Don't feel obligated to fix it here. If there are problems, they already exist, 
and could be handled later if/when they are found (if this were actual code I 
would care, but its just test runners). This patch already improves the 
intellij setup a lot, IMO. If you are ready to commit, go for it.
{quote}

Well, you were right, the IntelliJ build should be as close as possible to the 
Ant build, and restricting tests in the same way as the Ant build makes it more 
so.  Going through this exercise led me to find and fix a long-standing Solr 
test problem (SOLR-6508), so it wasn't a complete waste of time :).

The attached patch adds the equivalent of the Ant build test-class-matching 
patterns, shown below from {{test-macro}} in {{lucene/common-build.xml}}, to 
each pre-defined whole-module JUnit run configuration:

{code:xml}
<!-- Input test classes. -->
<junit4:duplicate times="${tests.dups}">
  <fileset dir="@{testsDir}">
    <include name="**/Test*.class" />
    <include name="**/*Test.class" />
    <include name="${tests.explicitclass}" if="tests.explicitclass" />
    <exclude name="**/*$*" />
  </fileset>
</junit4:duplicate>
{code}

The equivalent in the pattern language used by IntelliJ's run configuration 
facility is {{.\*\.Test\[\^.\]\*|.\*\.\[\^.\]*Test}}.  For reasons I don't 
understand, in addition to not matching the full-stop character, {{\[\^.\]}} 
also fails to match the {{$}} character, so nested classes are not matched, 
achieving the same effect as the Ant build's {{<exclude name="\*\*/\*$\*" />}}.

Two other changes are included in this version of the patch:

# I changed all modules' {{src/resources/}} and {{src/test-files/}} 
{{<sourceFolder>}}-s to use {{type="java-resource"}} and 
{{type="java-test-resource"}}, respectively, rather than the previous 
{{isTestSource="<false|true>"}}, to mirror what IntelliJ does when you mark 
folders as (Test) Resources.
# I added {{-Xmx512m -XX:MaxPermSize=256m}} to the Solr Core JUnit run 
configuration, to avoid PermGen OOMs.

With the exception of the {{map-reduce}} Solr contrib's tests and the single 
Solr Core failure described in SOLR-6514, all tests in all modules' pre-defined 
whole-module JUnit run configurations pass.

Three test suites in the {{map-reduce}} Solr contrib fail in ways I don't 
understand - see the attached console log for each: 
{{LUCENE-5930.failed.intellij.map-reduce.module.test.output.txt}}.  Maybe 
somebody else will know what's going on there ([[email protected]]?).

*Now* I'm committing shortly.

> IntelliJ config: drop resource-only modules, add module groups, and add 
> module for lucene/backward-codecs
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-5930
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5930
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Ryan Ernst
>         Attachments: 
> LUCENE-5930.failed.intellij.map-reduce.module.test.output.txt, 
> LUCENE-5930.patch, LUCENE-5930.patch, LUCENE-5930.patch, LUCENE-5930.patch, 
> LUCENE-5930.patch
>
>
> The number of intellij modules is getting out of hand.  Intellij supports 
> marking subdirectories within a module as 
> source/resources/tests/test-resources.  I think we should consolidate these 
> modules so we have just one per lucene module.  Is there some reason I'm 
> missing that this was not done in the first place?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to