Announcement Announcement Module
No announcement yet.
Any plans for an enhanced Gradle Dependency Tree View? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Any plans for an enhanced Gradle Dependency Tree View?

    Maven Eclipse integration has an excellent "Dependency Hierarchy" view that I've used again and again. It would be great if a similar view could be provided for Gradle projects.

    Here are the features I really appreciate:

    * Instantly see the exact jars that will appear in your archive.
    * Clicking on a jar in the right-hand pane shows you all the declarations that caused the jar to be there. (Double-clicking actually goes to the Jar's pom)
    * Click in a jar in left page shows all the dependencies (including transitive) and what effect it has on the right hand side.
    * Remove a dependency in the pom, refresh the view and you can see exactly the result.
    * Where there are multiple conflicting definitions of dependencies, see how the version number was determined.

    The view is really useful for cleaning up dependencies, its a real time saver as there's no build cycle. It's also a lot simpler/interactive than generating dependency trees using the command line.

    This would be a great feature for Gradle/STS to have and could really drive better adoption.

  • #2
    I'm not familiar with the Maven Dependency Hierarchy view, but it sounds very useful to extend to the Gradle support in this direction. Ideally this view would also handle Ivy repos as well.


    • #3
      I agree, it seems like a useful feature. With the current Gradle tooling API however it can't be implemented. The API only provides a list of resolved jars, but no further information about those jars. So the info to display in that view isn't easy/possible to obtain right now.

      That doesn't mean we can't push for an extension of the Gradle tooling API in this direction, which would enable STS to provide the functionality you are asking for.

      I suggest you raise an issue on the STS issue tracker, and I will then distill out some requirements for the Gradle tooling API and raise a request against Gradle to extend their APIs.

      The issue tracker is here:

      Coincidence? Someone just raised another issue that needs more info on the gradle dependencies than we can currently obtain:

      So perhaps the time is right to ask for this kind of extension to the API :-)
      Last edited by Kris De Volder; Jan 24th, 2012, 11:38 AM.