Compatibility with Android projects

[nightm4re94]

First of all, thanks for this amazing tool! My eternal search for a jvm cycle detection tool that hasn't been outdated and abandoned for years and integrates with Gradle has finally found an end 😄
Now I have tried applying the Gradle plugin to an Android project, and unfortunately the java plugin applied in decycle is incompatible with the Android plugins.
Since the lifecycle of Java and Android projects is rather similar, I was wondering: Would it be possible to remove the explicit application of the java plugin in favor of letting the user do that beforehand? From experience, every Java module has the java plugin applied explicitly anyway, so there is a bit of redundancy in the configuration.

[obecker]

Hey Matthias, thanks for giving Decycle a try. 😀
Yes, this is a valid point, and I surely can make that change.

Could you do me a favor (since I don't have any experience with Android development)?
Could you clone this repository on your machine, remove the line that applies the java plugin, and run gradlew publishToMavenLocal. Then temporarily add in your android project mavenLocal() to the pluginManagement section in settings.gradle, e.g. like this:

pluginManagement {
    repositories {
        mavenLocal()
        mavenCentral()
        gradlePluginPortal()
    }
}

After that you should be able to use id "de.obqo.decycle" version "1.1.1-SNAPSHOT".
Is the Decycle plugin now working as expected?

[nightm4re94]

Thank you for the swift response! I will clone the repo and test via composite build whether there are any other required changes.

[obecker]

By the way, just check out the branch "issue/no-default-java-plugin", then you don't have to modify the code yourself.

[nightm4re94]

The changes in your branch at least prevent any conflicts while applying the plugin, but there's another problem:
In an Android project, the source sets are not detected in the same way as for other Java projects, therefore the list of sourceSets is always empty.
I was able to retrieve the Android source sets with project.android.sourceSets, but this gives you a list of AndroidSourceSets. Not sure yet how to process these afterwards.

[obecker]

Could you possibly provide a minimal gradle build file (or project), so that I can debug this myself?

[nightm4re94]

The project I tested with was basically just the default new project created by Android studio. If you want, I can still zip that for you but it's probably faster to just create a new Android studio project on your own.

[obecker]

Hi Matthias, sorry for the delay. I finally got the time to dig a little bit into the android plugin details. I think I made some progress, however I would like to discuss this with someone having more android development knowledge than me.

The first thing I did was to examine the android source sets:

project.android.sourceSets.forEach { println(it.name) }

This results in this list:

androidTest
androidTestDebug
androidTestRelease
debug
main
release
test
testDebug
testFixtures
testFixturesDebug
testFixturesRelease
testRelease

However, unlike in the java plugin, there are no separate directories/folders for each of these source sets. The IDE (Android Studio) has for a new project only main (actually displayed without name), test , and androidTest. In the build directory in contrast there are directories in build/tmp/kotlin-classes and build/intermediates/javac for debug, release, debugUnitTest, and releaseUnitTest. So I supposed debug and release belong to the source sets with the same names, whereas debugUnitTest and releaseUnitTest belong to testDebug and testRelease. Unfortunately, I couldn't find the compiled classes for androidTest. As far as I understand are debug and release two build types, so the same sources (main) will just be built with different properties.

Since decycle works on the bytecode, i.e. on the compiled classes, it most likely doesn't make much sense to analyze both debug and release directories.

If you checkout the current issue/no-default-java-plugin branch (note, that I have rebased it since our last conversation), build it as described above, but then use version 1.2.0-SNAPSHOT of the plugin, decycle should analyze the classes in the 4 directories debug, debugUnitTest, release, and releaseUnitTest.

The question is how we can map this simply to main and test. Especially since decycle offers a configuration option to analyze only selected source sets (of the Java plugin).

What I can think of is to hard-wire main to debug (or release) and test to debugUnitTest (or releaseUnitTest) and to skip support for custom source sets in the decycle configuration.

What do you think, @nightm4re94 ?

[nightm4re94]

Sorry for taking this long with my response!
Unfortunately I haven't had the opportunity yet to test this and frankly I might not be the Android expert required here 😄
My stakes in developing Android apps have been limited to providing Gradle build infrastructure, but I don't have profound knowledge of the platform and its quirks.
Your assumptions regarding debug and release are correct, these are build variants.
Great success getting the first subsets analyzed, we're on the right track here - mapping the directories with hard-wired names would be an option for the automatically created build variants debug and release. However, this system will fall apart as soon as custom build variants are added, which seems fairly common 😢
I have a longer trip planned soon, so I will probably not be able to continue looking into this within the next month. But I'll make sure to seek out some assistance from Android-savvy colleagues.