Field Detail

• protected static final java.lang.String COMMANDS_STAGING_DIR

  Build-dir root staged by copyCommands; laid out as the archive sees it.

• public static final java.lang.String PLUGIN_ID

• protected static final java.lang.String TEMPLATES_STAGING_DIR

  Build-dir root staged by copyTemplates; laid out as the archive sees it.

Constructor Detail

• @javax.inject.Inject
  GrailsPluginGradlePlugin(ToolingModelBuilderRegistry registry)

Method Detail

• @java.lang.Override
  void apply(Project project)

• @java.lang.Override
  protected void applySpringBootPlugin(Project project)

• protected void checkForConfigurationClash(Project project)

• protected void configureAssembleTask(Project project)

• @groovy.transform.CompileDynamic
  protected void configureAstSources(Project project)

• protected void configureJarTask(Project project)

• protected void configurePluginResources(Project project)

  Packages plugin templates into the runtime jar and routes command scripts into either the runtime jar or the companion -cli jar.

  When GrailsCliArtifactGradlePlugin is applied, src/main/scripts is staged as META-INF/commands on the cli source set, so Groovy/YAML/JSON command resources ship only on grailsCliClasspath and stay out of runtimeClasspath, bootJar, and bootWar. Without a companion, the historical behavior is preserved: scripts remain in the runtime plugin jar so unmigrated Grails 7 plugins and legacyCommandSupport consumers keep discovering them on the application classpath. Templates always stay on the runtime jar.

  copyCommands and copyTemplates stay Copy tasks - build scripts configure them through tasks.named('copyTemplates', Copy) - and each owns one directory that nothing else writes, laid out exactly as the archive sees it. The staging tree is wiped before it is regenerated, so a script or template whose source was deleted stops being packaged; a plain Copy only ever adds. The wipe runs as a task action, so it happens only when the task actually executes and up-to-date checks are untouched.

  Those directories are attached to a source set output instead of being copied again by process*Resources. That is what keeps GSP templates intact: grails-app/views is a resource directory whose *.gsp files are excluded from processResources, and copy patterns set on a task apply to every spec composed into it - so anything routed through processResources would lose the GSP templates that generate-views and s2ui-override render from.

• @groovy.transform.CompileStatic
  protected void configureSourcesJarTask(Project project)

• @java.lang.Override
  protected void configureTemplateResources(Project project)

  A plugin's src/main/templates are always packaged by copyTemplates, so the base wiring that folds them into processResources must not also apply. Routing them through processResources would subject them to the **/*.gsp exclusion that keeps compiled views out of build/resources/main, silently dropping GSP templates such as the ones generate-views and s2ui-override render from.

• @java.lang.Override
  protected void createBuildPropertiesTask(Project project)

• protected java.lang.String getDefaultProfile()

• @java.lang.Override
  protected groovy.lang.Closure<java.lang.String> getGroovyCompilerScript(GroovyCompile compile, Project project)