Gradle Dataset: Failed to execute 'gradle :printClasspath -b 'classpath.gradle

[akwick]

Steps to reproduce:

• Checkout the dataset: <https://github.com/anam-dodhy/MUBench/tree/master/data/dragonite-java
• Build the project with MUBench:

Got:

    Exception in CompileVersionTask: Failed to execute 'gradle :printClasspath -b 'classpath.gradle'': 
    Detector:
    GrouMiner
    Command:
    ./mubench run ex2 GrouMiner --only dragonite-java

Expected:

• Successful build
• When running the build command from the versions.yml in ./mubench browse, the command is successful.

cc @anam-dodhy

[salsolatragus]

Problem seems to be that these are multi-projects.

It's not the actual build that's failing (as you manually confirmed), but the command we use to print all the dependency classpaths (the one you see in the error message). This command (or more precisely the classpath.gradle inject into the project) assumes that there is a build.gradle in the project root, extends it by a printClasspath task, and executes this new task. There's two problems with this in multi-projects, as far as I can see:

1. Multi-projects may not have a build.gradle in their root, if there's nothing to build for the root. This we could solve by making sure there is at least an empty build.gradle, which is equivalent to having none for gradle, but fixes our extension.
2. For multi-projects, our extension task needs to run for the subprojects, as opposed to the root project. I'm not experienced enough with gradle to figure out how we can do this without modifying the build.gradle files of all subprojects...

I'm open for suggestions 😅

[akwick]

I'm also no expert with gradle and I must admit that my last gradle project in which I also developed was during my bachelor's.

I figured out that the issue is due to the missing runtime configuration in the root build.gradle file.
One solution could be to use the subprojects { ... } structure and extend the current printclasspath task [ build.gradle ].
Another solution could be to use the allprojects{ ... } structure and add a check if the runtime configuration is present before calling it, e.g., via if (project.configurations.findByName('runtime')) [ build.gradle ].
I think the later one is the cleaner solution but is a bit more verbose. Both results in an output like this:

mubench> gradle printClasspath
:dragonite-echo:printClasspath
/mubench/checkouts/dragonite-java/e26ffff/checkout/dragonite-sdk/build/libs/dragonite-sdk-0.3.4.jar
/mubench/checkouts/dragonite-java/e26ffff/checkout/dragonite-utils/build/libs/dragonite-utils-0.1.0.jar
/root/.gradle/caches/modules-2/files-2.1/com.github/bucket4j/1.3.0/c1024c4f8c0ec1929cfd3f808ab39f4d41683057/bucket4j-1.3.0.jar
:dragonite-forwarder:printClasspath
/mubench/checkouts/dragonite-java/e26ffff/checkout/dragonite-sdk/build/libs/dragonite-sdk-0.3.4.jar
/mubench/checkouts/dragonite-java/e26ffff/checkout/dragonite-mux/build/libs/dragonite-mux-0.3.0.jar
...

A minor problem with this solution is that the parsing of the classpath needs to be adapted as well as the structure of the output changes:

1. We can't check for equal to :printClasspath anymore (line 119) and instead check for the string :printClasspath, e.g. with endswith.
2. We can't only collect the indices for the start and and anymore (line 121) and instead need to collect the lines between the different subproject tasks.

However, I observed another issue:
Adapting this in the classpath.gradle results in an error: Task 'printClasspath' not found in root project 'checkout'. . Adding this change directly into a new build.gradle (as the project has no build.gradle in the root directory) works fine. I assume I simply missed a minor and important detail while "faking" the build process on the MuBench shell.

What do you think about one of these solutions?

[salsolatragus]

I'd prefer a cleaner solution. Verbosity doesn't seem like a major problem here.

Would parsing work the same for projects with and projects without subprojects?

Which command did you use to run 'printClasspath' when the error occurred? I think you need to explicitly tell gradle which .gradle file to use, because classpath.gradle does not follow the conventional naming scheme.

[akwick]

The error was a mistake on my site - or writing down a wrong state. Thanks for pointing it out. Yes, one need to use -b to pass a non-conventional .gradle file, e.g., mubench> gradle printClasspath -b ./classpath.gradle.

Based on my understanding of the docu, it should work. I tested the second option against a project (chensun) without subprojects and it worked. [I randomly selected it from the projects returned by find -name classpath.gradle - classpathgradle-verify-chensun.txt]. However, it's not yet a complete systematic run of all existing projects. Thus, it could be that I was just lucky with my selection.