dependency-analysis-gradle-plugin icon indicating copy to clipboard operation
dependency-analysis-gradle-plugin copied to clipboard

How to avoid using dependencyAnalysys lambda in each build.gradle file

Open 9tilov opened this issue 11 months ago • 1 comments

I'm actively using this plugin and we have move than 1k modules in the project. Each module has its own whitelisted dependencies which I have to add to dependencyAnalysis -> exclude block. It would be nice to have one whitelist file with all modules and all excludes and avoid using this dependencyAnalysis block in each module. What are recommendations here? Example of current usage:

module1: build.gradle.kts

dependencyAnalysis {
    val fail = "fail"
    val ignore = "ignore"
    issues {
        onUnusedDependencies {
            severity(fail)
            exclude(
                ":somemodule1:deps1",
                libs.dagger.android.support.map { it.name() }.get(),
                "",
            )
        }
        onUsedTransitiveDependencies { severity(ignore) }
        onIncorrectConfiguration { severity(ignore) }
        onCompileOnly { severity(ignore) }
        onRuntimeOnly { severity(ignore) }
        onUnusedAnnotationProcessors { severity(ignore) }
        onRedundantPlugins { severity(ignore) }
    }
}

Nice to have:

unused-deps-whitelist.txt

module1 {
    ":somemodule1:deps1",
    libs.dagger.android.support.map { it.name() }.get(),
},
module2 {
    ":somemodule2:deps2",
    libs.dagger.android.support.map { it.name() }.get(),
}

9tilov avatar Dec 15 '24 06:12 9tilov

You can do this all from the root script! See https://github.com/autonomousapps/dependency-analysis-gradle-plugin/wiki/Customizing-plugin-behavior#failure-conditions-and-filtering. Would look like this:

// root build script
dependencyAnalysis {
  issues {
    // "all" runs against EVERY module
    all {
      onUnusedDependencies { ... }
      ...
    }

    // "project" runs against just the specified project
    project(':lib') {
      onUnusedDependencies { ... }
      ...
    }
  }
}

and you can do that for each module separately if you need to. Note that global behavior can be defined in all{}, and anything more specific will take precedence over the global behavior.

autonomousapps avatar Jan 10 '25 21:01 autonomousapps