Hey Xav,

I haven't heard about this specific problem before. We have clients that
use --parallel with very big multi-project builds with tons of custom code.
Here're some things to look for:

- are you running a "clean build"? In past I've seen problems with
--parallel compilation (although different than yours) related to the
custom layout of the build directories. Basically, the individual build
dirs were configured to live in root project's build dir. This caused
trouble in parallel build when root projects 'clean' task was clashing on
the 'compile' task of one of the subproject, who already completed his
individual 'clean' task. This custom layout of build dirs is supported but
requires laying out another task relationship rule (mustRunAfter).

- do you configure the compile task in any way? If not, one thing worth
trying is using the compiler daemon:
http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.compile.JavaCompile.htmlIf
toggling the compiler daemon makes a difference in the stability of
the
build we can dig further. You might also try Luke's suggestion

- more generic suggestion: can you imagine anything in the build that could
possibly clash with compile tasks?, e.g. sharing some directories between
projects, configuration tasks that alter other tasks' during execution
time, some execution-time project couplings (e.g. one project reaching out
to other project directly, instead of using a project dependency)?

Hope that helps!


On Wed, Feb 12, 2014 at 3:25 AM, Xavier Ducrohet <x...@google.com> wrote:

> No. In case of our jsr305 project, the whole build.gradle is:
>
> apply plugin: 'java'
> sourceSets {
>     main {
>         java {
>             srcDirs = ['ri/src/main/java']
>         }
>     }
> }
>
> Other projects where I've seen issues are similarly simple. We never
> configure anything special like this. Most of the custom logic I mentioned
> about is mostly in the android projects (adding custom tasks, before or
> after the Java compile, customizing packaging etc...)
>
>
>
> On Tue, Feb 11, 2014 at 5:29 PM, Luke Daley <luke.da...@gradleware.com>wrote:
>
>> This hasn't been reported before.
>>
>> There are a few different ways that Gradle can manage the Java compiler.
>> Are there any custom settings on the JavaCompile task? like using a
>> different javac executable? setting useAnt = true?
>>
>>  Xavier Ducrohet <mailto:x...@google.com>
>>> 12 February 2014 11:01 am
>>>
>>> Hello,
>>>
>>> I have a project with 70ish projects and I'm trying to run with
>>> --parallel and I keep getting errors (this is with 1.10). A lot of those
>>> projects are android projects, there's also a lot of custom logic in some
>>> of the projects (either regular java projects or on top of the android
>>> plugin).
>>>
>>> Every time I get an error it's also during a compileJava task, either in
>>> an Android project or in a Java project.
>>>
>>> The weird part is that the error never makes sense. For example we have
>>> the source of the jsr305 lib in our tree (we're using it from source) and
>>> I'll get errors like:
>>>
>>> /path/to/src/main/java/javax/annotation/CheckForSigned.java:1: class,
>>> interface, or enum expected
>>> package javax.annotation;
>>> ^
>>>
>>> Obviously this file is correct, and compiles fine without
>>> parallelization. All breakages I've seen are always the same and always in
>>> the Java compile task on code that is not broken.
>>>
>>> Is this is a known issue? Are there specifics to projects configs and
>>> inter-projects dependencies that could trigger this?
>>>
>>> I have another projects that is about 20ish java-only projects and I
>>> don't have any issue building it in parallel but it has basically no custom
>>> logic to build it.
>>>
>>> thanks
>>> Xavier
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>


-- 
Szczepan Faber
Principal engineer@gradle; Founder@mockito

Reply via email to