codeconsole commented on code in PR #16472:
URL: https://github.com/apache/grails-core/pull/16472#discussion_r4169451341
##########
grails-gradle/model/src/main/groovy/org/grails/io/support/MainClassFinder.groovy:
##########
@@ -85,6 +100,13 @@ class MainClassFinder {
}
if (rootDir) {
+ File projectDir = rootDir.canonicalFile
+ for (File entry in classpath) {
+ if (entry.isDirectory() &&
findRootDirectory(entry)?.canonicalFile == projectDir) {
Review Comment:
Fixed along the lines of your probe. The transform now passes
`source.configuration.targetDirectory`, and `MainClassFinder` first accepts
classpath directories under the same `<build>/classes` as the target, so a
plugin subproject's classes, under its own build directory, stay out. That only
applies when the target is laid out as
`<build>/classes/<language>/<sourceSet>`, so an unusual target can't widen the
search; the same-project check stays as the fallback. With `enable-mvc-check`
in the `rootProject.layout.buildDirectory.dir(project.name)` layout and no
`build/`, all 7 `integrationTest` tests pass with `--no-build-cache`. Since the
class is now found in each of these layouts, the compiled spec no longer
depends on which layout filled the build cache.
##########
grails-testing-support-core/src/main/groovy/org/grails/compiler/injection/testing/IntegrationTestAstTransformation.groovy:
##########
@@ -131,6 +132,29 @@ class IntegrationTestAstTransformation implements
ASTTransformation, TransformWi
}
+ /**
+ * The classpath the spec is compiled with: the compiler configuration's
entries and those of the class loaders it
+ * compiles against. It carries the application's main classes directory
wherever the build puts it. Dynamic, as
+ * static flow typing would hold the loop's class loader to the first
one's type and fail on its parent.
+ */
+ @CompileDynamic
+ private static Collection<File> compileClasspath(SourceUnit source) {
Review Comment:
Added `IntegrationTestApplicationClassSpec`. It compiles an `@Integration`
spec the way a build does: a source file inside a project directory, compiled
with a `CompilationUnit` into `<build>/classes/groovy/integrationTest`, against
a classpath holding a plugin subproject's classes (with an `Application` of its
own, listed first) and the application's. It then loads the spec and checks
`@ContextConfiguration(classes = Application)`, with the build directory inside
the project but not `build/`, at the root of the checkout, and outside it. The
last two fail without the target-directory change.
##########
grails-gradle/model/src/main/groovy/grails/util/BuildSettings.groovy:
##########
@@ -335,6 +337,24 @@ class BuildSettings {
BASE_DIR = System.getProperty(APP_BASE_DIR) ? new
File(System.getProperty(APP_BASE_DIR)) :
(IOUtils.findApplicationDirectoryFile() ?: new File('.'))
GRAILS_APP_DIR_PRESENT = new File(BASE_DIR, 'grails-app').exists() ||
new File(BASE_DIR, 'Application.groovy').exists()
TARGET_DIR = new File(BASE_DIR,
System.getProperty('project.target.dir', 'build'))
- RESOURCES_DIR = !GRAILS_APP_DIR_PRESENT ? null :
(System.getProperty(PROJECT_RESOURCES_DIR) ? new
File(System.getProperty(PROJECT_RESOURCES_DIR)) : new File(TARGET_DIR,
'resources/main'))
+ RESOURCES_DIR = !GRAILS_APP_DIR_PRESENT ? null :
resourcesDir(System.getProperty(PROJECT_RESOURCES_DIR), BASE_DIR, TARGET_DIR)
+ }
+
+ /**
+ * {@link #RESOURCES_DIR}: a {@link #PROJECT_RESOURCES_DIR} that is
relative, as the Gradle plugin passes it, joined
+ * to the application directory rather than the working directory, which a
build can move; one that is absolute
+ * as it is; and without one, {@code resources/main} in the target
directory.
+ *
+ * @param fromSystem the {@link #PROJECT_RESOURCES_DIR} system property,
or null
+ * @param baseDir the application directory
+ * @param targetDir the target directory
+ * @return the resources directory
+ */
+ static File resourcesDir(String fromSystem, File baseDir, File targetDir) {
Review Comment:
Done. It's private now, and the forked-JVM feature covers the absolute case
alongside the relative one and no property.
--
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]
