Vladimir Sitnikov

The current bundle modules are not BOMs. See https://blog.gradle.org/alignment-with-gradle-module-metadata for the description of "a". In other words, "a" should be dependency **constraints** rather than versions: * atrium-bom would apply `java-platform`...

The use cases for `b` and `c` are to remove the current pattern of storing versions in `extra` properties: https://github.com/robstoll/atrium/blob/cca39fc1f1e334dcfca73c84a1af76b49ba2d49b/build.gradle.kts#L20-L29 `project.extra` was a thing ~7 years ago, however, it did...

One of the major drawbacks of having `val jacocoToolVersion by extra("0.8.9")` is that you miss Renovate / Dependabot support for the custom syntax. You have to manually discover which versions...

In the mean time, I've released https://github.com/vlsi/kotlin-argument-expression#motivation

> I am at this point unsure how it actually operates and is different from ClassGraph The key difference is that one can build "annotation index" **at the build time**,...

> To load an individual recipe we could indeed do something like Class#forName(), but note that we also have use cases (like the SaaS or CLI) where we indeed want...

> generated at build-time by our build plugin That is one of the options, however, how would you implement that? Imagine someone creating a recipe, pardon me, in Kotlin ;)...

The ultimate solution would be an openrewrite recipe that adds `@AutoService(Recipe.class)` for the recipes :)

> So it would not necessarily have to be a Java service. Java service is something that has zero-arg constructor which you require for the recipe anyway. Everything else (jandex...

I have not double-checked that, however, I think the root cause of `ClassGraph`-based scanning slowness is caused by the fact that `ClassGraph` has to process many more classes than needed:...