Currently, the procedural jar build process is somewhat hacky, since Gradle is purely declarative, and doesn't have a way to explicitly call tasks from other tasks. Instead, we have to generate tasks to build each procedure jar, and add them to the dependency tree that gradle builds.
This worked fine for a while, but now that we use codegen for procedure parameter schemas / arguments, there is a configuration time dependency on an execution time step running (See Gradle lifecycle), which Gradle doesn't support.
This results in the need to run gradle twice, once to run the annotation processor + generate procedure jar building tasks with :compileJava, and another time to actually build procedures with :buildAllSchedulingProcedureJars.
A gradle plugin might offer a way to inject our imperative build logic deeper into the Gradle build lifecycle, avoiding the need to build twice and keep track of this "state" in the developers head.
Additionally, a gradle plugin could easily be sourced in a new repo, instead of copying build logic form our template repo.
Currently, the procedural jar build process is somewhat hacky, since Gradle is purely declarative, and doesn't have a way to explicitly call tasks from other tasks. Instead, we have to generate tasks to build each procedure jar, and add them to the dependency tree that gradle builds.
This worked fine for a while, but now that we use codegen for procedure parameter schemas / arguments, there is a configuration time dependency on an execution time step running (See Gradle lifecycle), which Gradle doesn't support.
This results in the need to run gradle twice, once to run the annotation processor + generate procedure jar building tasks with
:compileJava
, and another time to actually build procedures with:buildAllSchedulingProcedureJars
.A gradle plugin might offer a way to inject our imperative build logic deeper into the Gradle build lifecycle, avoiding the need to build twice and keep track of this "state" in the developers head.
Additionally, a gradle plugin could easily be sourced in a new repo, instead of copying build logic form our template repo.