gosu-lang/gradle-gosu-plugin

Fix classpath pollution

DPUkyle opened this issue · 1 comments

Early builds of the plugin were build with a set version of Gosu, and the plugin (in its buildscript closure) included explicit dependencies for the specific, fixed version of Gosu JARs upon which the plugin was built.

This provided a small convenience factor of not requiring explicit dependencies on Gosu. Going forward, however, this behavior is not desirable.

Furthermore, including a specific Gosu version in the plugin's classpath causes a classpath pollution issue. The plugin should be refactored to avoid any dependencies on Gosu, but instead examine the classpath of the project to which the plugin is applied and throw if Gosu is not present.

Originally I tried to work-around the need to include the Gosu libs as a compile-time dependency by instantiating and invoking the Gosu compiler via reflection. But the code is very unwieldy and, even worse, does not solve the problem of classpath pollution as the buildscript will still need to rely on Gosu. When the project applying the plugin declares a dependency on different Gosu JARs, things get ugly.

Instead I changed course entirely and implemented a 'gosuc' task for ant. This will be published in a forthcoming Gosu release (>1.8.1) in the module "gosu-ant-compiler". The plugin will now behave as follows:

  1. Plugin no longer depends on Gosu libs; instead it dynamically creates an ant build file at runtime which invokes the gosuc task.
  2. Plugin throws if the implementing project does not declare a dependency on gosu-core-api
  3. Plugin infers a dependency on gosu-ant-compiler based on gosu-core-api's version number
  4. gosu-ant-compiler has a runtime dependency on gosu-core
  5. Method org.gosulang.gradle.GosuPlugin#refreshTestRuntimeClasspath ensures that the testRuntime configuration classpath includes gosu-core. Otherwise source and test compilation succeeds, but fails when executing compiled tests.