[GRADLE-1969] Crossed runtime/compile dependencies between projects cause circular dependencies between compile and JAR tasks Created: 28/Nov/11  Updated: 24/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-6
Fix Version/s: None

Type: Bug
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Fixed Votes: 7

Attachments: Zip Archive GRADLE-1969.zip    

 Description   

Consider the attached multiproject.

Project A has a compile dependency on B. B has no compile dependencies. That is, A and B can be compiled together on their own.
C has a compile dependency on A: that is, after A (and B) are compiled, C can be compiled, too.

Then, B has a runtime dependency on C. So, at runtime, B needs C to work, C needs A and A needs B. Yes, there's a circular dependency here, but it's a runtime circular dependency that shouldn't be a problem at build time and Java can handle it.

However, at build time Gradle says that these dependencies cause a circular dependency between :A:compileJava task and :A:jar task.

While I know that it's not ideal to have such a runtime circular dependency, I think that there shouldn't be any problem at build time and that Gradle could at most print a warning, but go ahead and build.

 Comments   
Comment by Mauro Molinari [ 20/Jul/12 ]

Any news on this?

Comment by Mathias Birkkjær Nielsen [ 28/May/15 ]

Is this somehow solved another place, or is it obvious to everyone else that this should never happen.

In my end-to-end tests I have abstracted my drivers into guiDrivers and programmaticDrivers. I therefore have the following modules:

':drivers'
':gui-drivers'
':programmatic-drivers'

':drivers' has a static method that instanciate the main gui- or programmatic driver.
Therefore

':gui-drivers' has: compile project(':drivers')
':programmatic-drivers' has: compile project(':drivers')
':drivers' has: runtime project(':gui-drivers'); runtime project(':programmatic-drivers')

Ofcause I could make a fourth module with only the static method. But that seems kind of overkill?

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 Mauro Molinari [ 15/Nov/16 ]

This is still reproducible in recent Gradle.

Comment by Benjamin Muschko [ 24/Jan/17 ]

This use case should be solvable with the upcoming feature "Java Library Plugin" in Gradle 3.4-RC1. Please try that as soon as we release the version. This should happen by the end of the week. Please open a new issue on GitHub if the functionality doesn't solve your use case.

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