AbstractConfiguration.getProjectFolder() fails with IllegalStateException on a Gradle submodule with build.gradle.kts

[mvysny]

Description of the bug

The check at AbstractConfiguration:221 checks for the existence of pom.xml and build.gradle, however Gradle also supports Kotlin-based build files named build.gradle.kts; Flow should therefore check for the existence of that file too.

Expected behavior

AbstractConfiguration.getProjectFolder() should correctly assume the folder to be a project folder if build.gradle.kts is present.

Minimal reproducible example

1. git clone https://github.com/mvysny/karibu-testing/
2. Edit gradle/libs.versions.toml and change vaadin24 and vaadin24_spring at line 8 to 24.3.4
3. ./gradlew test

Versions

• Vaadin / Flow version: 24.3.4 / 24.3.5
• Java version: openjdk-21
• OS version: Linux Ubuntu 23.10

[mvysny]

Stacktrace

    java.lang.IllegalStateException: Failed to determine project directory for dev mode. Directory '/home/mavi/work/my/vok/karibu-testing/karibu-testing-v10-groovy' does not look like a Maven or Gradle project. Ensure that you have run the prepare-frontend Maven goal, which generates 'flow-build-info.json', prior to deploying your application
        at com.vaadin.flow.server.AbstractConfiguration.getProjectFolder(AbstractConfiguration.java:225)
        at com.vaadin.flow.server.DevToolsToken.init(DevToolsToken.java:53)
        at com.vaadin.flow.server.VaadinService.init(VaadinService.java:270)
        at com.github.mvysny.kaributesting.v10.mock.MockVaadinServlet.createServletService(MockVaadinServlet.kt:31)
        at com.vaadin.flow.server.VaadinServlet.createServletService(VaadinServlet.java:336)
        at com.vaadin.flow.server.VaadinServlet.init(VaadinServlet.java:132)
        at com.github.mvysny.kaributesting.v10.MockVaadin.setup(MockVaadin.kt:97)
        at com.github.mvysny.kaributesting.v10.MockVaadin.setup(MockVaadin.kt:69)
        at com.github.mvysny.kaributesting.v10.MockVaadin.setup$default(MockVaadin.kt:65)
        at com.github.mvysny.kaributesting.v10.MockVaadin.setup(MockVaadin.kt)
        at com.github.mvysny.kaributesting.v10.groovy.UploadUtilsTest.setup(UploadUtilsTest.groovy:19)

[contradictioned]

I just saw the same after updating from com.vaadin:vaadin-bom:24.3.12 to com.vaadin:vaadin-bom:24.4.3 (not sure why this wasn't an issue before).

Our project structure looks roughly like this

└── mainProject
    ├── build.gradle.kts
    └── subProject
        └── subproject.gradle.kts

and the error message is `Directory '/path/to/mainProject/subProject' does not look like a Maven or Gradle project.

[mcollovati]

@contradictioned could you please provide a running example project to reproduce the issue?

[mcollovati]

I tried to set up a project resembling the structure posted above, but I was unable to reproduce the issue neither running the app from the command line nor starting it from the IDE

[mvysny]

Quick note: the subproject.gradle.kts looks suspicious, the file is always named build.gradle.kts

[mcollovati]

Yes, in my test project I named it build.gradle.kts. But still, I cannot reproduce. I suppose it has something to do with how the application is started, but I have no idea how to trigger the failing code.

[contradictioned]

When I manually excluded react and hilla dependencies from our project, the issue did not occur anymore. Still I am just trying to build a reproducer.

[contradictioned]

Ok, I got it. Not sure if it is too interesting, but it provokes the exception ;)

Code is here: https://github.com/contradictioned/vaadinNestedProjectsGradlePluginVersionMissmatch

The problem might be related to a missmatch of the vaadin bom and the vaadin gradle plugin. With id("com.vaadin") version "24.3.12" and mavenBom("com.vaadin:vaadin-bom:24.4.3"), when i do vaadinBuildFrontend, this error comes:

Failed to determine project directory for dev mode. Directory '/Users/manuel/Downloads/base-starter-spring-gradle-24-nested/sub-project' does not look like a Maven or Gradle project.

With id("com.vaadin") version "24.4.3", vaadinBuildFrontend finishes without problem.

@mvysny gradle allows modifying the build file name, see e.g. here https://github.com/contradictioned/vaadinNestedProjectsGradlePluginVersionMissmatch/blob/main/settings.gradle.kts#L19 -- in our project we have all submodules' build files named "$submodule.gradle.kts"

[mcollovati]

Having custom names for build files makes the thing complex. Maybe we can check for *.gradle.kts, but I think supporting a completely custom name is not worth it.

[mcollovati]

@contradictioned thanks for the reproducer and the info. I could reproduce the issue by running ./gradlew --stacktrace clean build -Pvaadin.productionMode

The reason why it fails with the version mismatch is that Vaadin 24.4 has the Flow - Hilla unification, that is, of course, not supported by the 24.3 Gradle plugin. The issue comes from the execution of a Hilla node task. Vaadin 24.4 skips it because it detects that Hilla is not in use, but 24.3 does not care about the type of task.

TaskGenerateOpenAPIImpl

[mcollovati]

But actually, the error I get is not the same as the one in the issue description. My error comes directly from Hilla , not from Flow AbstractConfiguration.getProjectFolder() method.

Caused by: com.vaadin.flow.server.ExecutionFailedException: Failed to determine project directory for dev mode. Directory '/home/marco/tmp/trash/xxxxxxx/gradle/vaadinNestedProjectsGradlePluginVersionMissmatch/sub-project' does not look like a Maven or Gradle project.
        at com.vaadin.hilla.internal.AbstractTaskEndpointGenerator.prepareEngineConfiguration(AbstractTaskEndpointGenerator.java:99)
        at com.vaadin.hilla.internal.AbstractTaskEndpointGenerator.getEngineConfiguration(AbstractTaskEndpointGenerator.java:72)
        at com.vaadin.hilla.internal.TaskGenerateOpenAPIImpl.execute(TaskGenerateOpenAPIImpl.java:85)
        at com.vaadin.flow.server.frontend.NodeTasks.execute(NodeTasks.java:342)
        at com.vaadin.flow.plugin.base.BuildFrontendUtil.runNodeUpdater(BuildFrontendUtil.java:332)
        at com.vaadin.gradle.VaadinBuildFrontendTask.vaadinBuildFrontend(VaadinBuildFrontendTask.kt:76)

Hilla also has a GradleRunner.forProject() methods, that checks if build.gradle or build.gradle.kts is present. If I rename the sub-project build file to buid.gradle.kts the build works fine.

[mcollovati]

So, basically I'm still not able to reproduce the original issue.

[mcollovati]

Anyway, I created a PR to support build.gradle.kts in Flow, so it will be aligned with Hilla.