bmuschko
commented
5 years ago Could you put together a sample project that reproduces the issue?
Open tnielens opened 5 years ago
bmuschko
commented
5 years ago Could you put together a sample project that reproduces the issue?
bmuschko
commented
5 years ago I could reproduce the issue by adding the dependency to the build script's classpath.
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'io.swagger.codegen.v3:swagger-codegen-cli:3.0.7'
}
}
plugins {
id 'org.gradle.playframework' version '0.4'
}The dependency swagger-codegen-cli is a fat JAR that bundles other transitive dependencies with the same package name. As a result Gradle cannot properly resolve version conflicts. If you want to include other dependencies in a JAR then those packages should be shaded to avoid conflicts. I suggest you open an issue with the project at https://github.com/swagger-api/swagger-codegen.
Ultimately, I think the worker API lets Gradle core's classpath bleed into the classpath of the plugin. This is the relevant issue: https://github.com/gradle/gradle/issues/3698. So the issue is twofold. I guess you could also get around the issue if swagger-codegen-cli would shade its dependencies.
Generally speaking I don't think you necessarily want to add the dependency to the buildscript's classpath. Instead you could create a custom configuration, assign the swagger-codegen-cli dependency to it and then pass the classpath to the task that runs the code generation e.g. JavaExec.classpath. But I'd really need to see your code and understand what you are trying to achieve.
ymwang1984
commented
5 years ago @bmuschko Thanks for the analysis. Yes, our case is the same as the swagger plugin (a fat jar on build classpath). We will attempt to do something to get pass it for the moment.
But we are curious, if we fix the issue https://github.com/gradle/gradle/issues/3698 in Gradle 5.4 release, do we need to worry about this problem we see right now?
bmuschko
commented
5 years ago @ymwang1984 I think if you shaded transitive dependencies in your fat JAR with a different package then there's a good likelihood that you will not run into the reported issue. Alternatively (if you do control how the fat JAR is created), you could just publish a version of the dependency that defines its transitive dependencies in its metadata (e.g. pom.xml -> dependencies block) so that you can use Gradle's dependency management capabilities to modify transitives (e.g. exclude or use the same version as Gradle does). Shading can be achieved with the Shadow plugin.
The worker API will still have the issue for exposing Gradle internal dependencies but the risk of facing the issue is decreased. It looks like https://github.com/gradle/gradle/issues/3698 has been moved to 5.5 and won't be addressed with 5.4 so that won't happen soon.
tnielens
commented
5 years ago applying this comment unblocked me
Generally speaking I don't think you necessarily want to add the dependency to the buildscript's classpath. Instead you could create a custom configuration, assign the swagger-codegen-cli dependency to it and then pass the classpath to the task that runs the code generation e.g. JavaExec.classpath. But I'd really need to see your code and understand what you are trying to achieve.
This issue occured while migrating from precedent "software model" version of the plugin. A clearer error message might be helpful.
Thanks for the help
bmuschko
commented
5 years ago The error message would have to be handled by Gradle core. I am going to close this issue for now.
ymwang1984
commented
5 years ago Thank you @bmuschko
Just curious about the choice to use Worker API for "runPlay". Worker API allows us to run tasks in parallel AFAIK. However, I don't think "runPlay" is designed to run in parallel with other tasks.
bmuschko
commented
5 years ago @ymwang1984 The software model Play plugin uses deep and complex Gradle core-internal infrastructure to execute external tools in a forked JVM process e.g. Twirl or for running the Play application. Using this infrastructure isn't really feasible in an external plugin without risking future breakages as Gradle evolves and releases new versions. The public API equivalent for this functionality is the worker API.
The new Play plugin configures the worker API to wait with executing any additional work until the processing functionality has been completed (see Twirl processing as an example).
ymwang1984
commented
5 years ago Makes sense. Thank you.
See following stacktrace. The mentioned swagger codegen module is a dependency of a gradle plugin I use to generate swagger model classes.