Silently no advice without java-library plugin

[patrick-dedication]

Build scan link

Plugin version
3.4.1

Gradle version
9.2.0

JDK version
21

(Optional) Kotlin and Kotlin Gradle Plugin (KGP) version

(Optional) Android Gradle Plugin (AGP) version

(Optional) reason output for bugs relating to incorrect advice

Describe the bug
When I have a subproject which uses the java plugin but not the java-library plugin I silently get no advice.

To Reproduce
Steps to reproduce the behavior:

1. ...

Expected behavior
To get advice for unused dependencies and such, or an error detailing applying the plugin without java-library plugin makes no sense

Additional context

[sergeykad]

I experience the same issue. You can see a minimal reproducer here.
This affects service modules using java + jib in our production monorepo.

[autonomousapps]

Thanks for the issue.

How are you attempting to use the plugin. Are you running ./gradlew buildHealth, or something else?

There is a feature in the plugin that will detect when there are no subproject reports being generated, and warn you in that case. But if some modules do provide analysis, then no warning will be emitted.

It's true the plugin doesn't support the java plugin. I'm not sure where I've ever asserted that, but I acknowledge it's a not uncommon source of confusion. The plugin supports java projects, and expects to find java-library or, if there's only java, then also an "application"-type plugin, e.g.:

private fun Project.isAppProject() =
  pluginManager.hasPlugin(APPLICATION_PLUGIN) ||
    pluginManager.hasPlugin(SPRING_BOOT_PLUGIN) ||
    pluginManager.hasPlugin(GRETTY_PLUGIN) ||
    pluginManager.hasPlugin(ANDROID_APP_PLUGIN) ||
    dagpExtension.forceAppProject

Looking at that code has reminded me that, if your module isn't a library but an "application" of some type instead, you can do this:

// build.gradle(.kts)
dependencyAnalysis {
  app()
}

and then you should see your module analyzed (as an app, meaning there can't be an "api"-like dependencies).

This further reminds me that this has never been documented outside of PR discussions.

[sergeykad]

Yes, I used ./gradlew buildHealth.

In our large monorepo, I eventually spotted that about 30% of modules weren't analyzed - all the plain Java ones.

I'm curious about the rationale for excluding plain Java modules. They seem the simplest to analyze since they have the fewest dependency scopes. I found detecting "application"-type plugins tricky, sice it's unclear what qualifies as an "application." For example, are plugins for IntelliJ or Jenkins considered applications? In our codebase, "application" modules typically use Jib or Shadow.

If you're open to it, would any of these approaches fit the plugin's design?

1. Analyze all modules by default
2. Recognize Jib and Shadow as "application"-type plugins
3. Allow configuring additional "application"-type plugins in the root build.gradle

I appreciate your work on this plugin and understand if these don't align with your vision for it.