Make plugin responsible for managing dependencies
Currently users of the library should manually add necessary dependencies, such as roborazzi artifacts and robolectric.
My suggestion is to make RoborazziPlugin responsible for managing dependencies.
I see roborazzi is split into 3 artifacts, so plugin could install at least core artifact and robolectric.
I can work on this, if you ok with external contributions
Thank you for sharing your ideas and for your willingness to contribute. Your suggestion to simplify the setup process indeed sounds promising.
Regarding your comment that the "plugin could install at least the core artifact and robolectric," I agree that it could be beneficial to have the roborazzi module installed by default.
We might be able to provide Robolectric by using implementation or api in the build.gradle of the roborazzi module. I was initially uncertain about the direction of roborazzi, but I believe usability should be our main concern. (See https://github.com/takahirom/roborazzi/issues/12 for more discussion.)
https://github.com/takahirom/roborazzi/blob/main/roborazzi/build.gradle#L25
Still, I'm pondering whether we should proceed with this installation. For example, JetBrains Compose Multiplatform provides an extension rather than directly installing the dependency. https://github.com/JetBrains/compose-multiplatform/blob/master/gradle-plugins/compose/src/main/kotlin/org/jetbrains/compose/ComposePlugin.kt
Given these considerations, what are your thoughts on proceeding with the installation? Or do you think the extension approach used by JetBrains Compose Multiplatform is more applicable in our case?
With the latest feature of AGP (Android Gradle Plugin), we now have the ability to capture Compose Preview screenshots. This feature seems to use a different source set from test/. While we can inspect the source code, the artifact has not been published yet, so it's unclear whether Roborazzi can be incorporated into this new structure. If Roborazzi can be integrated, it may require dependencies that are not testImplementation.
Therefore, it might be prudent to wait until more information becomes available.
But, in any case, we can provide an extension for users. It would be used like this: testImplementation(roborazzi.rule).
Let's wait for AGP then.
I have rethought this, and it makes our build settings lose their single source of truth, so I can't support this. However, JetBrains Compose style can still be used.