jfrog / gradle-dep-tree

Gradle plugin that reads the Gradle dependencies of a given Gradle project, and generates a dependency tree.

🐘 Gradle Dependency Tree

This Gradle plugin reads the Gradle dependencies of a given Gradle project, and generates a dependency tree. This package was developed by JFrog, and is used by the JFrog IntelliJ IDEA Plugin to generate the dependency tree for projects using Gradle dependencies. You may find this plugin useful for other purposes and applications as well, by applying it in your build.gradle file.

🖥️ Usage

Inject the plugin using the init.gradle initialization script, and run generateDepTrees in a directory containing a build.gradle file. The plugin will generate a dependency tree for each subproject that does not contain a build.gradle file. To generate a dependency tree for each subproject that contains a Gradle build file, set the -Dcom.jfrog.includeAllBuildFiles flag to true.

The command:

gradle clean generateDepTrees -I <path/to/init.gradle> -q -Dcom.jfrog.depsTreeOutputFile=<path/to/output/file>

Output:

"<path/to/dependency/tree1>"
"<path/to/dependency/tree2>"
...

🌲 Output Tree Structure

{
  "root": "org.jfrog.example.gradle:shared:1.0-SNAPSHOT",
  "nodes": {
    "junit:junit:4.7": {
      "unresolved": false,
      "configurations": ["testCompileClasspath", "testImplementation", "testRuntimeClasspath"],
      "children": []
    },
    "org.jfrog.example.gradle:shared:1.0-SNAPSHOT": {
      "unresolved": false,
      "configurations": ["compileClasspath", "runtimeClasspath", "testCompileClasspath", "testRuntimeClasspath"],
      "children": ["junit:junit:4.7"]
    }
  }
}

💻 Contributions

We welcome pull requests from the community. To help us improve this project, please read our contribution guide.

gradle-dep-tree's Issues

referenced line invariably causes java.util.ConcurrentModificationException

gradle-dep-tree/src/main/java/com/jfrog/tasks/GenerateDepTrees.java

Line 172 in 698367b

for (Configuration configuration : project.getConfigurations()) {

Gradle version: 8.2.1

I could reproduce with gradle 7.3.2 in a different project.

The only common factor: both are quarkus projects, and quarkus' gradle plugin creates configurations dynamically. Given quarkus plugin isn't the only one to create configurations dynamically, it stands to reason others would be impacted as well, hence opening the ticket here as opposed to in quarkus' repo.

Task get stuck because of transitive dependencies

Describe the bug

In an android project the generateDepTrees task get stuck or lead to java heap space error.

The behaviour seems happens only when there is conflict between dependency and transitivity dependencies.

Current behavior

When i run /gradlew clean generateDepTrees the task can be very long (more than 10 minutes) and end with this error

failed while building 'gradle' dependency tree:
error running gradle-dep-tree: exit status 1
Exception in thread "Daemon periodic checks" java.lang.OutOfMemoryError: Java heap space

The debug log shows :

[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
[DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.

Reproduction steps

Have a very simple gradle android project with gradle 8+ and the following dependencies in build.gradle :

implementation 'com.google.android.material:material:1.10.0'
implementation 'androidx.navigation:navigation-fragment:2.5.3'

Launch ./gradlew clean generateDepTrees.... command and then the problem will happen.

Notes :

• If androidx.navigation:navigation-fragment:2.5.3 dependency is removed, then then it's ok.
• If com.google.android.material:material dependency is downgrade to 1.9.0, then it's ok (because in 1.10.0 material add a dependency toward androidx.activity:1.8.0.
• if i exclude androidx.activity from material, it's ok :

implementation('com.google.android.material:material:1.10.0') {
     exclude group: 'androidx.activity', module: 'activity'
}
implementation 'androidx.navigation:navigation-fragment:2.5.3'

Expected behavior

Functionnal generateDepTrees output

Gradle Dependency Tree version

3.0.1

Operating system type and version

Ubuntu-jammy, windows 11

Change generateDependencyTree -> generateDepTrees

Java Heap Space exception

Describe the bug

I am using this plugin via the JFrog CLI, but I receive a Java Heap space exception;

The init script is as follows;

initscript {
    repositories { 
		mavenCentral()
    }
    dependencies {
        classpath 'com.jfrog:gradle-dep-tree:2.2.0'
    }
}

So I am using the latest version.

I have the following in my gradle.properties file in my repository
org.gradle.jvmargs=-Xmx4096M

Current behavior

Exception in thread "Daemon client event forwarder" java.lang.OutOfMemoryError: Java heap space
        at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter(AbstractQueuedSynchronizer.java:1896)
        at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2114)
        at java.base/java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:458)
        at org.gradle.launcher.daemon.server.exec.DaemonConnectionBackedEventConsumer$ForwardEvents.getNextEvent(DaemonConnectionBackedEventConsumer.java:72)
        at org.gradle.launcher.daemon.server.exec.DaemonConnectionBackedEventConsumer$ForwardEvents.run(DaemonConnectionBackedEventConsumer.java:59)

Reproduction steps

No response

Expected behavior

No response

Gradle Dependency Tree version

2.2.0

Operating system type and version

MacOS Ventura

Resolving rootProject.buildDir too early, should be a DirectoryProperty

gradle-dep-tree/src/main/java/com/jfrog/tasks/GenerateDepTrees.java

Line 35 in 9f4dc78

private final Path pluginOutputDir = Paths.get(getProject().getRootProject().getBuildDir().getPath(), "gradle-dep-tree");

This code seems to resolve the buildDir too early. When jf audit runs my gradle build, it resolves the build directory to <project>/build, whereas I've set it in my project to /target/build, as "build" was actually a directory created many years ago and can't be changed.

Perhaps better yet to store this variable as a DirectoryProperty as an input for the task, and let it dynamically be resolved to "target/build" as I have configured to be in my project (and run during afterEvaluate)?