[
https://issues.apache.org/jira/browse/LUCENE-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030291#comment-14030291
]
Dawid Weiss commented on LUCENE-5755:
-------------------------------------
[~rcmuir] Robert, what I meant by test collection is not what Mike does. The
runner would collect all parameters for all tests (including classpath) and
it'd have to respect classpath differences. It would still help with
load-balancing because you wouldn't have to wait for all forked JVMs of a
single module to finish -- once you have fewer tests than workers you could
fork another JVM (to run another module's tests) without waiting.
I am aware of classpath/ JVM parameters differences and I will definitely not
go in the direction Mike already explored (partly because that already works so
there's no need to duplicate).
[~thetaphi] Uwe, gradle supports ant tasks "almost natively", there is no need
for any special groovy constructs. See here, for example:
http://www.gradle.org/docs/current/userguide/ant.html
I also agree with Uwe that currently ant is doing things over and over which is
slowing builds down significantly. Gradle has a downside in that it takes a
longer time to run the first time, but it comes with a daemon that runs in the
background and speeds things up significantly. My impressions so far from using
gradle far outweight its deficiencies. I hope others will share my feelings
here. We'll see.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
