dependency-analysis-gradle-plugin VS android-buddy

And perhaps https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin

I'd love to hear more about the complexity of configuring multi-module builds. Dependency management is an obvious point here and there are plugin that can help here (like https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin for instance), but I'd be happy to hear more pain points.

Added a new test suite, named "functionalTest", and configured it to use the Spock test framework, along with three dependencies: Truth, TestKit-Truth, and the project itself. This reveals the interesting point that, by default, new test suites don't have the project under test on the classpath, which enables true black box testing if you're into that kind of thing.

A little more than two years ago, in October 2019, I began work on my first significant open source project, the Dependency Analysis Gradle Plugin. I had just left a job where I had done relatively little coding, was taking a month off, and wanted to get back into a building mode and learn some new things. I decided to explore the domain of unused-dependency detection. The nearest competitor I was aware of was the Gradle Lint Plugin from the Netflix Nebula collection. However, as that plugin has never supported Android projects, that meant I had an exploitable niche—if only I could exploit it.

Tony actually wrote a plugin that does just this! Check it out!

(The commit is available here.)

That's what happened to me when I tried to write some bytecode transformations using Byte Buddy. I noticed that they wouldn't work for Android right away, and instead, some sort of adapter is needed in order to make the connection between these bytecode transforming tools and the Android compilation so that said transformations happen at compile time. Sadly for me, such compilation adapter didn't exist for Byte Buddy and Android, which is why I took the time to create one: Android Buddy.