[GRADLE-733] Allow better control of depencies Created: 10/Nov/09  Updated: 24/Jan/17  Resolved: 24/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Steve Ebersole Assignee: Unassigned
Resolution: Duplicate Votes: 0

Issue Links:
Related
Related to GRADLE-244 dependencyMechanism for a better cont... Resolved

 Description   

Specific use cases:
1) Support for what Maven does with <dependencyManagement/>. Consider I depend on slf4j-api:1.5.8 and some other artifact that in turn has a depenency on slf4j-api:1.5.6. <dependencyManagement/> would allow me to force all dependencies from that groupId/artifactId to my version.
2) Support for "remapping" dependencies. The ubiquitous example here is javax.transaction:jta. The sun specs are gnerally published under a license which does not really allow publishing them into maven repositories (not to mention that they are not OSS licenses, which matters to some folks). So what ends up happening is that every tom-dick-and-harry publishes their own "bundle" of the jta apis under a different license to various repositories. What would be nice is a way to say that "javax.transaction:jta:1.1" should really be resolved as "org.jboss.javaee:jboss-transaction-api:1.0.2-SNAPSHOT" or some other one.
3) An interesting one Adam brought up on IRC is the ability to say that project() dependencies should be resolved against that project's sourceSets.main.runtimeClasspath. I personally have adopted the approach of defining all my inter-project dependencies within a given root project this way, so I think this would be fantastic to be able to say something like "map all project() dependencies as project().sourceSets.main.runtimeClasspath"

 Comments   
Comment by Steve Ebersole [ 10/Nov/09 ]

Ideally allowing recursion back into the "remapping" process after a remapping occurs. Dangerous for sure do to potential infinite recursions. Perhaps in conjunction with setting a "depth limit"?

Use case? Consider a "replacement" remapping that says "javax.transaction:jta:1.1" should be remapped to "org.jboss.javaee:jboss-transaction-api:1.0.2-SNAPSHOT" along with a <dependencyManagement/>-style remapping that says 1.0.3 should always be used for "org.jboss.javaee:jboss-transaction-api".

Probably not critical for local builds, but if/when this "remapping info" is ever written to a repo it becomes so imho.

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 Steve Ebersole [ 15/Nov/16 ]

Again, personally something I find worthwhile but that has gotten zero Gradle-team love. Please either reject it and do not migrate or do it

Comment by Benjamin Muschko [ 24/Jan/17 ]

1) is now tracked by https://github.com/gradle/gradle/issues/1162.
2) can be fulfilled via module replacement rules or dependency resolve rules.
3) I don't quite understand the the description of this point. Please open a new issue on GitHub if you'd like to follow up.

Generated at Wed Jun 30 11:37:27 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.