[GRADLE-1859] overwrite of compileJava task breaks java task ordering for multi-project builds Created: 21/Oct/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-1, 1.0-milestone-2, 1.0-milestone-3
Fix Version/s: None

Type: Bug
Reporter: Scott Yancey Assignee: Unassigned
Resolution: Won't Fix Votes: 2

Attachments: Zip Archive gradle-test.zip    

 Description   

I have a reproducible test case showing that when the "compileJava" task is overwritten then the normal Java task dependencies for multi-project builds is broken. For example, if project "Child" depends on code produced by project "Parent," then project "Child" needs the jar produced by project "Parent" to be present before project "Child" is compiled. When the "compileJava" task is NOT overwritten, then you see the standard order of tasks for java-based multi-project dependencies:

:project-parent:compileJava
:project-parent:processResources
:project-parent:classes
:project-parent:jar
:project-child:compileJava

However, if you overwrite the "compileJava" task (real world use case for this is needing to use an aspectj compiler instead), then the ordering is broken as compilation of project "Child" occurs before the jar is built for project "Parent".

:project-child:processResources
:project-child:compileJava
:project-child:classes
:project-child:jar
:project-child:assemble
:project-parent:processResources
:project-parent:compileJava
:project-parent:classes
:project-parent:jar

Now obviously this will break a real compilation event when the overwritten "compileJava" task actually performs compilation instead of being stubbed out as in my test case. Regardless of what the contents of the overwritten "compileJava" task is, the order of multi-project Java dependencies should not change. I've added a zip of this test case to demonstrate. And I've pasted in the key files below...

    1. /settings.gradle

include 'project-child', 'project-parent'

    1. /build.gradle

subprojects

{ apply from: '<your_path>/override.gradle' }

dependsOnChildren()

    1. /override.gradle

apply plugin: 'java'

task compileJava(dependsOn: JavaPlugin.PROCESS_RESOURCES_TASK_NAME, overwrite: true, description: 'Compile Override') {

}

    1. /project-child/build.gradle

dependencies

{ compile project(":project-parent") }
    1. /project-parent/build.gradle

<no content>

 Comments   
Comment by Koen Ongena [ 03/May/12 ]

A workaround:

def projectDependencies = [project(':project-child')]
compileJava.dependsOn projectDependencies *.compileJava

dependencies

{ compile projectDependencies }

Let it be noted though that I don't like this

Comment by Alejandro Salas [ 18/Oct/12 ]

I ran into the same problem for a lombok+aspectj build. Don't know if it's the correct way but I solved it using:
dependsOn configurations.compile.getTaskDependencyFromProjectDependency(true, "TASK-NAME-HERE") for the custom compileJava task.

In my case this did the trick:
dependsOn configurations.compile.getTaskDependencyFromProjectDependency(true, "jar")

Hope it helps.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:06:17 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.