[GRADLE-1205] Gradle includes transitive dependencies from project(...) dependency references at compile time Created: 03/Nov/10 Updated: 02/Feb/17 Resolved: 02/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 0.9 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Sean Reilly | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 6 |
Attachments: | gradle-bug.tgz |
Description |
According to the gradle user guide, "Gradle [...] validates your dependency hierarchy against the reality of your code by using only the first level dependencies for compiling". Does this apply to local project() style dependencies as well? I assume that when a project relies on another local project in the same hierarchy via a project() dependency, the expected behaviour is:
The expected behaviour does not occur for me with gradle 0.9-rc-2. Runtime behaviour is as expected, but at compile time the referenced project and all of its dependencies are available. Test case The project should-succeed obeys this rule, and should compile. The project should-fail does not obey the transitive dependency. Instead it depends directly on joda-time. I would expect this project to fail compilation, but instead it compiles successfully. |
Comments |
Comment by Sean Reilly [ 20/Nov/10 ] |
I've developed a potential fix for this issue: https://github.com/seanjreilly/gradle/tree/GRADLE-1205 Any feedback is welcome. |
Comment by Szczepan Faber [ 26/May/11 ] |
Sean, is it a duplicate of |
Comment by Sean Reilly [ 26/May/11 ] |
No, I don't believe that it is. 1317 is about excluding transitive dependencies from a specific dependency. This bug is about automatically excluding all transitive dependencies at the compile phase, which is supposed to happen (according to documentation), but does not. FYI: The patch was rejected, and I suppose that this issue should be marked WON'T FIX. |
Comment by Gerwin Jansen [ 24/Jun/11 ] |
I'm having the same problem as Sean. According to me this is a real issue, so should be fixed. |
Comment by Russ Egan [ 15/Sep/11 ] |
Anyone have a workaround? It's definitely sub-optimal. Pretty much all the benefits of "getting your build under control" from the documentation goes out the window in a multi-project build. We have a couple dozen modules which deploy into jboss. All rely on a little utility module, which happens to rely on some jboss libraries, which pull in the world. |
Comment by Adam Murdoch [ 15/Sep/11 ] |
A workaround is to set configurations.compile.transitive = false |
Comment by Russ Egan [ 16/Sep/11 ] |
Yeah, sorry, figured that out. The workaround is so trivial, I'm thinking this isn't really a defect. It's just the way the tool works, and the user can customize as they see fit. |
Comment by Scott Stewart [ 09/Nov/11 ] |
Shouldn't the compile configuration default to transitive = false, though? I'm trying to think of a reason why I'd want to transitively reference dependencies at compile time and can't.. If someone can think of a use-case that would be interesting.. |
Comment by Mike M. [ 06/Mar/12 ] |
I totally agree: The statement "Gradle [...] validates your dependency hierarchy against the reality of your code by using only the first level dependencies for compiling", besides being a good one , implies that dependencies on a project should behave as Sean describes it. |
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:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Gerwin Jansen [ 30/Nov/16 ] |
The problem of this ticket is clear. I still would like to have this fixed. |
Comment by Benjamin Muschko [ 02/Feb/17 ] |
It's easy to make Gradle behave in the way explained by setting the transitive dependencies to false for the compile configuration. Please open an issue on GitHub if you think the documentation is not sufficient or incorrect so we address your concern separately. |