Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom compilation taks #103

Open
aalmiray opened this issue Aug 25, 2019 · 2 comments
Open

Support custom compilation taks #103

aalmiray opened this issue Aug 25, 2019 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@aalmiray
Copy link
Contributor

Currently the default compilation tasks for the main and test sourceSets are enhanced for Java, Kotlin, and Groovy following a strict name matching convention i.e these tasks are matched

  • compileJava
  • compileKotlin
  • compileGroovy
  • compileTestJava
  • compileTestKotlin
  • compileTestGroovy

It’d be great if additional compile tasks were enhanced too. This will likely require matching tasks by type (CompileJava for example). Another option is to inspect the properties of each SourceSet as they point to the compile tasks that affect said sourceSet.

This feature is needed by the GroovyFX project as it declares an extra sourceSet named demo https://github.com/groovyfx-project/groovyfx/blob/master/gradle/demo.gradle

@tlinkowski tlinkowski added the enhancement New feature or request label Aug 27, 2019
@aalmiray
Copy link
Contributor Author

aalmiray commented Sep 2, 2019

This change is bigger than I thought as pretty much all tasks enriched by the plugin are found by name. This behavior poses 2 big problems:

  1. Only specific tasks get enriched. For example compileJava belonging to the main SourceSet but not compileDemoJava belonging to the demo SourceSet.
  2. Task search is performed eagerly, some tasks may fail to be found if the modules plugin is applied before others. This breaks the push Gradle has been doing in the past year to move most behavior to lazy evaluation.

In short, it'd be better if APIs such as project.task.withType(TaskType.class, { task -> }) be used instead as

  1. It matches tasks by type.
  2. Enables lazy evaluation.

@big-andy-coates
Copy link
Collaborator

I agree. It should also be possible to attach a listener to ensure any tasks created after the plugin is initialised also get detected as well. Happy to accept a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants