codeconsole commented on code in PR #16184:
URL: https://github.com/apache/grails-core/pull/16184#discussion_r3962835073
##########
grails-gradle/plugins/src/main/groovy/org/grails/gradle/plugin/views/gsp/GroovyPagePlugin.groovy:
##########
@@ -437,6 +436,22 @@ class GroovyPagePlugin implements Plugin<Project> {
}
}
+ // The archives below take the compiled pages by copy. They belong on
the test class path as
+ // well, so a test of the application loads the same pages it ships -
the view registry among
+ // them. They cannot be registered as source set output: that output
is what `classes` builds,
+ // and compileGroovyPages runs after `classes`, so it would cycle.
+ //
+ // The main runtime class path is deliberately left alone. A boot
archive packages every
+ // directory of it into its own classes directory, and the pages are
copied there already, so
+ // each page would arrive twice - and an application run from the
build renders its templates
+ // as they are edited, which is what a page compiled ahead of the edit
would stand in the way
+ // of.
+ FileCollection compiledPages = project.files(destDir,
webappDestDir).builtBy(compileGroovyPages)
+ SourceSet testSourceSet = SourceSets.findSourceSet(project,
SourceSet.TEST_SOURCE_SET_NAME)
+ if (testSourceSet != null) {
+ testSourceSet.runtimeClasspath = testSourceSet.runtimeClasspath +
compiledPages
Review Comment:
Scoped to a non-Grails build in 1ca0145550, in the provider form above:
`plugins.withType(GrailsGradlePlugin)` records the answer however the plugin is
applied, and `project.provider` decides when Gradle builds the task graph.
`webappDestDir` now declares `builtBy(compileWebappGroovyPages)` rather than
relying on `compileGroovyPages` depending on it.
New test project `gsp-compile-classpath-grails` asserts a Grails build gets
no pages on the test runtime classpath and that `test` has no
`compileGroovyPages` dependency; the existing non-Grails case still asserts it
does.
##########
grails-core/src/main/groovy/org/grails/plugins/CoreGrailsPlugin.groovy:
##########
@@ -91,13 +93,19 @@ class CoreGrailsPlugin extends Plugin {
private static final String SPRING_PROXY_TARGET_CLASS_CONFIG =
'spring.aop.proxy-target-class'
def beans = {
- bean(ClassLoader).primary() { GrailsApplication grailsApplication ->
+ // Both of these are the GrailsApplication read through another type,
so both stand down for
+ // an application that has none: this configuration is contributed by
every Spring Boot
+ // application with grails-core on its class path, where only a Grails
application has the
+ // plugin lifecycle that builds one.
+ bean(ClassLoader).primary().annotate(ConditionalOnBean, value:
GrailsApplication) { GrailsApplication grailsApplication ->
Review Comment:
Gated as a whole in 3af263cb69. `@ConditionalOnBean(GrailsApplication)`
moved to the plugin class, which `@GrailsBeans` carries onto the generated
`CoreAutoConfiguration` — `@Conditional` is in its sibling-annotation set — and
both beans are declared plainly again.
The surface is no longer mixed: a plain Boot application gets none of the
configuration, `grailsResourceLocator` and `GrailsPlaceholderConfigurer`
included, and places holders the way Spring Boot does.
`CoreAutoConfigurationSpec` asserts that instead. A Grails application is
unaffected — `grails-core` and the `gsp-sitemesh3` `@Integration` suite pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
