vaadin/flow 24.6.0.beta2

Vaadin Flow 24.6.0.beta2

on GitHub

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.