[
https://issues.apache.org/jira/browse/LUCENE-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049383#comment-14049383
]
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: https://issues.apache.org/jira/browse/LUCENE-5755
> 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 experiments.
> An example of a complex (?) gradle build is javafx, for example.
> http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc932af/build.gradle
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
