We made a simple app with Vaadin 14, Spring Boot and Kotlin. The app runs flawlessly on OSX, a Linux laptop as well as in a Docker container based on a Linux image on AWS ECS.
However, we don’t get it to run on a Windows 10 machine. The app starts and we can access the UI. But all styles are missing. The UI looks totally broken, even though the buttons are working.
There are no errors in the Java log, but the browser console shows the following:
style-gather.js?ee41:216 Could not find style data in module named lumo-color
style-gather.js?ee41:216 Could not find style data in module named lumo-typography
What are we missing? We tried two Windows machines - same result on both of them.
Hey Artur, thank you for your investigation! We can confirm the same behaviour.
On a Mac we can see:
2020-07-15 19:18:32.172 INFO --- [ main]
dev-updater : Visited 87 classes. Took 15 ms.
2020-07-15 19:18:32.185 INFO --- [ main]
dev-updater : Skipping `npm install`.
2020-07-15 19:18:32.185 INFO --- [ main]
dev-updater : Copying frontend resources from jar files ...
2020-07-15 19:18:32.215 INFO --- [ main]
dev-updater : Visited 11 resources. Took 29 ms.
2020-07-15 19:18:32.237 INFO --- [ main]
dev-updater : No js modules to update '/Users/thomas/Bringmeister/con-search-keywords/target/frontend/generated-flow-imports.js' file
Whereas on Windows we see:
2020-07-16 17:23:49.759 INFO --- [ main]
dev-updater : Visited 1 classes. Took 16 ms.
2020-07-16 17:23:49.784 INFO --- [ main]
dev-updater : Removed 1 dependencies
2020-07-16 17:23:49.792 INFO --- [ main]
dev-updater : Updated npm C:\Users\sscheller\IdeaProjects\con-search-keywords\package.json.
2020-07-16 17:23:49.813 INFO --- [ main]
dev-updater : Running `pnpm install` to resolve and optionally download frontend dependencies. This may take a moment, please stand by...
2020-07-16 17:23:49.835 INFO --- [ main]
dev-updater : Generated pnpmfile hook file: 'C:\Users\sscheller\IdeaProjects\con-search-keywords\pnpmfile.js'
To make things a bit stranger, my colleague who’s using the Windows laptop has checked-out the GitHub project from above. And guess what, this one is working on his Windows laptop. The log looks like this:
2020-07-16 17:26:54.991 INFO 644 --- [ main]
dev-updater : Visited 87 classes. Took 69 ms.
2020-07-16 17:26:55.054 INFO 644 --- [ main]
dev-updater : Skipping `pnpm install`.
2020-07-16 17:26:55.055 INFO 644 --- [ main]
dev-updater : Copying frontend resources from jar files ...
2020-07-16 17:26:55.233 INFO 644 --- [ main]
dev-updater : Visited 11 resources. Took 178 ms.
2020-07-16 17:26:55.341 INFO 644 --- [ main]
dev-updater : No js modules to update 'C:\Users\sscheller\IdeaProjects\vaadin-win-issue\target\frontend\generated-flow-imports.js' file
And yes, as a result the generated-flow-imports.js looks very different. On OSX it’s full of imports, on Windows it’s almost empty.
Do you have any idea how to solve this? (I’m happy with a workarround)
Have you tried if the same issue exists with with Maven build? That would help us to know if the issue is limited to the Gradle plugin. Our team that is working on the builds is mostly on vacation this month, it might be hard to get help via forum soon. I don’t have access to Windows machine currently so can’t easily test it by myself.
I don’t think that the problem is related to the Gradle plugin. As far as I understand it, the problem occurs at runtime when Vaadin is scanning classes. The Gradle plugin shouldn’t be involved at this point. I can remove the Gradle plugin entirely from the script and I still run in the same issues.
I played around with the dependencies a bit and found out that it works when I remove some of them:
// This will work
implementation ...
// implementation "org.zalando:logbook-spring-boot-starter:2.0.0"
// implementation "io.springfox:springfox-swagger2:2.9.2"
// implementation "io.springfox:springfox-swagger-ui:2.9.2"
implementation ...
// This not
implementation ...
implementation "org.zalando:logbook-spring-boot-starter:2.0.0"
// implementation "io.springfox:springfox-swagger2:2.9.2"
// implementation "io.springfox:springfox-swagger-ui:2.9.2"
implementation ...
// This also not
implementation ...
// implementation "org.zalando:logbook-spring-boot-starter:2.0.0"
implementation "io.springfox:springfox-swagger2:2.9.2"
implementation "io.springfox:springfox-swagger-ui:2.9.2"
implementation ...
However, it doesn’t seem to be a problem with those particular libraries. When my colleague removes them in the original project (not the one I pushed to GitHub), he still has the same problems on his Windows machine.
It looks either like some sort of class path issue or something with Spring (probably Spring Boot Autoconfigurations). But I’m unable to debbug this.
What is Vaadin scanning at this point? Can I somehow force Vaadin to scan particular classes?
I can reproduce the problem on Win10+JDK8 when running https://github.com/Artur-/vaadin-win-issue via gradlew bootRun. Curiously the app works just fine when launched via Intellij’s SpringBoot launcher.
Even after I delete all Kotlin code, convert Application.kt back to Java and even remove Vaadin Gradle Plugin and all other plugins except the java plugin, org.springframework.boot and the io.spring.dependency-management plugin, the issue still persists and the DevModeInitializer reports 0 classes.
When I try to create a simple MyRoute.java class with the following contents:
@Route("")
public class MyRoute extends VerticalLayout {
public MyRoute() {
add(new Button("Hi!"));
}
}
this class gets detected and DevModeInitializer prints initDevModeHandler called with 1 classes. That leads me to believe that the Spring Boot classpath scanning only considers src/main/java when run from Gradle on Windows. Unfortunately I’m not a Spring Boot expert so I can’t really pinpoint what’s going on here, but the Vaadin Gradle plugin doesn’t seem to be the culprit here.
Attaching a chopped-down version of the app which still reproduces the issue. Please run gradlew bootRun to reproduce the issue; after node_modules has been populated you can comment out id 'com.vaadin' version '0.8.0' from build.gradle, re-run gradlew bootRun and still observe that only 1 class is detected. 18386970.zip (398 KB)
Hey Martin, thank you for your investigation. I’ve downloaded your ZIP file and can confirm that running gradlew bootRun will lead to the issue (only 1 class scanned). However, running the app with the IntelliJ launcher works just fine.
