Skip to content

Vaadin Flow 24.6.0.beta2

Pre-release
Pre-release
Compare
Choose a tag to compare
@vaadin-bot vaadin-bot released this 22 Nov 10:02
· 16 commits to main since this release
55f1147

Changes since 24.6.0.beta1

All changes

New features

  • Generate PWA icons at build time
    Commit · Pull request · Issue

    Generates PWA icons during the production build, preventing the need to use AWT APIs at runtime and making first requests to the application faster. Also prevents potential issues caused by loading AWT native library in native images.

Fixes

  • Vaadin/router added with react-router
    Commit · Pull request · Issue

    Exclude vaadin/router when runing in react mode. Without exclusion vaadin/router gets added from the vaadin-core.json package in platform.

  • Attach element when used in drag source
    Commit · Pull request · Issue

    Attach elemnt to dom and move it outside of the viewport to have it visible as a drag image. Image can be used without attaching to dom. Hidden elements are also not shown so throw exception when using one as dragImage. Log attach as debug now that the

  • Exclude project maven dependencies from isolated class loader
    Commit · Pull request

    If the user project directly or transitively depends on maven artifacts, mojos can fail at runtime because of Maven API loaded from both isolated class loader and maven.api realm. This change prevents maven artifacts from being added to the isolated class loader.

  • Prevent blocking when closing ViteWebSocketConnection
    Commit · Pull request · Issue

    This change prevent ViteWebSocketConnection to wait indefinitely on close waiting for the client websocket to close request to complete.

  • Production also with file extensions
    Commit · Pull request

    Also use file extensions with production build.

  • Fix class and resource loading in maven plugin
    Commit · Pull request · Issues 19616, 19009, 20385

    Run Flow mojos using an isolated class loader that includes both project and plugin dependencies, with project dependencies taking precedence. This ensures that classes are always loaded from the same class loader at runtime, preventing errors where a class might be loaded by the plugin's class loader while one of its parent classes is only available in the project’s class loader (see #19616). Additionally, this approach prevents the retrieval of resources from plugin dependencies when the same artifact is defined within the project (see #19009). This refactoring also introduces caching for ClassFinder instances per execution phase, allowing multiple goals configured for the same phase to reuse the same ClassFinder. It also removes the need to instantiate a ClassFinder solely for Hilla class checks, reducing the number of scans performed during the build.