vaadin/flow 25.0.9

Vaadin Flow 25.0.9

on GitHub

Changes since 25.0.8

All changes

New features

• BuildFrontend Incremental build (#23884)
  Commit · Pull request

  Add incremental build to the buildFrontend task. Closes #17354

Fixes

• Prevent stale JAR cache in Reflector under Maven daemon (mvnd) (#23863)
  Commit · Pull request

  Mirror the Gradle daemon fix (33fa374) in the Maven plugin's Reflector and ReflectorClassLoader/CombinedClassLoader: - Extract ReflectionsClassFinder.disableJarCaching() as a public utility so both plugins can reuse it. - Wrap jar: URLs in ReflectorClassLoader.getResource() and getResources() (flow-maven-plugin) and CombinedClassLoader (flow-dev-bundle-plugin) with useCaches(false) to prevent stale JarFileFactory entries across daemon builds. - Make Reflector implement Closeable with a close() method that releases the URLClassLoader file handles, and register a Cleaner action for best-effort GC cleanup of abandoned instances. - Close the temporary Reflector in FlowModeAbstractMojo.isHillaAvailable(MavenProject) via try-with-resources. Releated to #15458

• Prevent addon stylesheet links from being removed during CSS live reload (#23892) (CP: 25.0)
  Commit · Pull request · Issue

• Prevent stale JAR cache in ReflectionsClassFinder under Gradle daemon
  Commit · Pull request · Issue

  Close URLClassLoader on cleanup to release JAR file handles, and disable JVM-level JAR caching in getResource() by wrapping jar: URLs with a URLStreamHandler that sets useCaches(false). The Gradle daemon reuses JVMs across builds. When a sibling module's JAR is rewritten, two independent caching layers can hold stale file handles: 1. URLClassLoader internal cache (URLClassPath → JarLoader) 2. JarFileFactory static HashMap (populated via JarURLConnection) The URLClassLoader.close() call addresses layer 1, but layer 2 is JVM-global and independent of the class loader. Setting useCaches(false) on jar: URL connections prevents JarFileFactory from caching JarFile instances, matching the approach used by Spring's PathMatchingResourcePatternResolver (SPR-4639).

• Propagate forceInstantiation and recreateLayoutChain flags through forward/reroute (#23848) (CP: 25.1) (#23954) (CP: 25.0)
  Commit · Pull request

• Move thread start out of DevServerWatchDog constructor (#23898)
  Commit · Pull request

  Starting a thread in a constructor can expose a partially constructed object. Extract the thread start into a separate start() method that callers invoke after construction completes.

• Route with context path name (#23836)
  Commit · Pull request · Issue

  the same start as the context path from clearing context path out from the url when using react router.

• Move import statements to top in generated web component imports file (#23817) (CP: 25.0)
  Commit · Pull request

  This PR cherry-picks changes from the original PR #23817 to branch 25.0. --- #### Original PR description > AbstractUpdateImports.process() already reorders import lines to > the top for generatedFlowImports, but the same sorting was not > applied to generatedFlowWebComponentImports. This caused interleaved > import and non-import lines (e.g. injectGlobalWebcomponentCss() > calls mixed with import statements) in the web component output. > > Extract a reusable moveImportsToTop() method and apply it both in > process() for main imports and in mergeWebComponentOutputLines() > after merging and deduplicating the web component sources. > > Related to #23689 (comment)

• Improve npm resolution for non-windows (#23810)
  Commit · Pull request

  Adds another potential path to the npm resolver algorithm to make it compatible with node installation performed by frontend-maven-plugin