My Google-fu has failed me, so asking here to see if anyone knows if this is possible/how it might be achieved: I have a plugin that is a "meta-plugin" (composes and configures other plugins, adds dependencies, etc) to configure a project... for example to set up a project with a default set of plugins and/or dependencies that are commonly used/required. I have a library dependency that depends on some heavy-weight spring autoconfiguring dependency (e.g. jooq). Is there a way to detect if a dependency (e.g.

org.jooq:jooq

) is already in play for a project, and only add my library dependency if the other dependency exists? Basically I only want to provide this additional library functionality automatically if the project is already using the heavy-weight dependency. Thanks for the info/help.

https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.artifacts/-configuration/with-dependencies.html is a hook you can you use to modify dependencies right before they're finalized

Oh interesting... Would that be the flattened/transitive list of dependencies, or just the ones directly included by a project? It's a common pattern where the heavy-weight dependency (e.g. Jooq) is coming in through a different module related to data access. I suppose I can just test it out... even first-order deps would be a step in the right direction.

just direct dependencies

Alrighty... well maybe getting half-way there is good enough to get most of the use cases. Thanks for the info!

Just to clarify, I think what ephemenient means - and I agree - is, that if your convention plugin is applied to project X and there applies the component metadata rule to make jooq depend on your additional module, it will work fine. But if X is a library and Y depends on X, then Y will not have this additional dependency. But if your convention plugin is just for "end-products" without further consumers, it should work fine with the component metadata rule. Please correct me if I misunderstood @ephemient 🙂

Ah that's a really interesting idea... I missed that subtlety... Just to restate, for a project using my plugin: • If Jooq is added as a dependency anywhere by the project or dependencies of the project , the rule will bring in the additional helpful library that depends on Jooq. • If the project doesn't ever use Jooq, then no helpful library is added. If that's accurate, that actually works really well... I'm not too concerned about the transitive bit... as those consumers can use the helpful plugin as well if necessary. This is great! Thanks for the clarification @Vampire, and thanks @ephemient for the new tool in the toolbox.

Yes, you got it right.

This is working great for me -- with one minor/semi-trivial hiccup... I'm trying to make the rule cacheable, but I also want to do some informational logging... I can pass the logger/project as part of the params, but then I need to remove cache-ability. Questions are: • Is cache-ability a worthwhile endeavor, or should I just pass the logger via the constructor params? • Is there a way to access the associated project/logger somehow via an injected field etc? I can of course always fall back to

println

and keep cacheability, but of course then that doesn't respect the gradle logging level etc.

You're saying just create a new one? Is there any reason/need to associate with the project logger?

yeah just create one for your class, no need to use the project logger. Gradle doesn't support fine-grained logging configuration anyway

Ah.. I always assume gradle was associating logs with the associated project and conditionally displaying the more/less detailed information depending on outcomes of tasks etc.... but if not, then this works great too!

You can even create a standard slf4j logger and use it, you will just miss the Gradle-specific levels

👍 -- Sounds like I was assuming more magic from the gradle logger than there actually is 😃