lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Davis (JIRA)" <>
Subject [jira] [Commented] (LUCENE-5755) Explore alternative build systems
Date Tue, 01 Jul 2014 22:23:24 GMT


Matt Davis commented on LUCENE-5755:

 I have all Lucene test case compiling on my fork with the system out check suppressed.  
Solr is untouched and javacc.  I am using transitive dependencies but that is an easy fix.

I disagree that these features are not features that would useful for gradle to implement
natively.  The following seem pretty useful in general but I will let someone from gradle
decide that:

1)We use a special SecurityManager that also prevents to escape the test's working dir or
to prevent that a tests calls System.halt(). This security manager relies on the Junit4-Runner.
2)Also the runner not only parallelizes, it also keeps statistics about the performance of
tests to reorder them on next run, so slower tests don't leave the last JVM run longer just
because the running tests take too long
3)Another important thing is that the runner randomizes the test execution order, which is
important to prevent bugs that are caused by tests leaving state that influence others.

Things like forbidden-apis make sense to call from ant tasks but it is easy to make a gradle
plugin out of them.

As a side note, I think making eclipse projects with gradle is going to be problem unless
i am missing something.  lucene-core test depends on lucene-test-framework and lucene-test-framework
depends back on lucene-core.

I will leave this to others that are more knowledgeable about lucene to continue.

> Explore alternative build systems
> ---------------------------------
>                 Key: LUCENE-5755
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Task
>            Reporter: Dawid Weiss
>            Assignee: Dawid Weiss
>            Priority: Minor
> I am dissatisfied with how ANT and submodules currently work in Lucene/ Solr. It's not
even the tool's fault; it seems Lucene builds just hit the borders of what it can do, especially
in terms of submodule dependencies etc.
> I don't think Maven will help much too, given certain things I'd like to have in the
build (for example collect all tests globally for a single execution phase at the end of the
build, to support better load-balancing).
> I'd like to explore Gradle as an alternative. This task is a notepad for thoughts and
> An example of a complex (?) gradle build is javafx, for example.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message