vaadin.whitelisted-packages should have a sensible default

[marcushellberg]

Description of the bug

When downloading a project from start.spring.io, it does not have the vaadin.whitelisted-packages property defined.

Building a native image out of the app and running it fails.

Expected behavior

The app works out of the box also when compiled to native.

We should be able to produce the default value com.vaadin,org.vaadin,dev.hilla,com.example.application easily as a fallback as the first packages are our own, and the last might be determined by finding where the application class is located.

Minimal reproducible example

• Download an app with the Vaadin dependency from start.spring.io.
• Native compile it with mvn -Pnative -Pproduction native:compile
• Run the created binary

Versions

• Vaadin / Flow version: 24.0
• Java version: 17, GraalVM
• OS version: Mac

[tarekoraby]

If start.spring.io is the main concern, then we should probably add com.example.demo.

[marcushellberg]

People can change that. Could we add the package that contains the main spring boot application instead? That should most often be correct.

[tarekoraby]

Sounds reasonable to me. Though that might not be the desired setup in some of the larger projects, this solution would ensure that most new evaluators have a setup that works.

[marcushellberg]

Agreed. If there's an explicit value defined as a property, that should override. But this way, most (all?) projects from both start.vaadin.com and start.spring.io would work out of the box

[mshabarov]

Needs to be reproduced and see what's the original error we have when building with native profile.

[mcollovati]

Projects created with start.vaadin.com currently have vaadin.whitelisted-packages set. I tried to remove it, but I cannot see any error; the application works out of the box

[mcollovati]

Trying to run the executable produced by the skeleton project fails, but the error seems more related to PWA and AWT than the whitelisted-packages setting. If I remove the PWA annotation, the native executable works fine.

@marcushellberg any chance that you remember the exact error you got? Or could you reproduce it again and post the log with the evidence of the error?