You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even though #19874 greatly improved things, each invocation of the vaadin maven plugin seems to still scan the classpath - according to the log output:
[INFO] --- vaadin:24.5.2:prepare-frontend (default) @ ims ---
[INFO] Reflections took 1624 ms to scan 320 urls, producing 17948 keys and 94028 values
.....
[INFO]
[INFO] >>> vaadin:24.5.2:build-frontend (default) > :configure @ ims >>>
--- vaadin:24.5.2:configure (configure) @ ims ---
[INFO] Reflections took 1712 ms to scan 320 urls, producing 17948 keys and 94028 values
......
[INFO]
[INFO] <<< vaadin:24.5.2:build-frontend (default) < :configure @ ims <<<
[INFO]
[INFO] --- vaadin:24.5.2:build-frontend (default) @ ims ---
[INFO] Reflections took 1341 ms to scan 320 urls, producing 17948 keys and 94028 values
.....
Expected behavior
Ideally the classpath is scanned only once
Minimal reproducible example
A normal maven build of any vaadin project
Versions
Vaadin 24.5.2
The text was updated successfully, but these errors were encountered:
The main reason for that is that prepare-frontend and build-frontend can run on different phases, so having different "class path". ClassFinder is now per mojo instances
We can check if it is possible to cache per execution phase.
Another thing that should be investigated is why build-frontend is reported twice
Never mind. The additional ClassFinder is because of the configure goal
Extracts logics from Flow mojos to separated task classes, loaded with a
custom class loader composed by project and plugin dependencies, with
the firsts having precedence on the others.
This make sure classes are always loaded from the same class loader,
preventing errors like having a class loaded by plugin class loader, but
one of its parent present only in project class loader (see #19616).
It also prevents retrieving resources from plugin dependency instead of
from same artifact defined in the project (see #19009).
This refactoring caches a ClassFinder per execution phase, so that it can be
reused by multiple goals configured to run on the same phase.
It also removes the need to instantiate a ClassFinder to checking for Hilla
classes, limiting the number or scans processed during the build.
Fixes#19616Fixes#19009Fixes#20385
Description of the bug
Even though #19874 greatly improved things, each invocation of the vaadin maven plugin seems to still scan the classpath - according to the log output:
Expected behavior
Ideally the classpath is scanned only once
Minimal reproducible example
A normal maven build of any vaadin project
Versions
Vaadin 24.5.2
The text was updated successfully, but these errors were encountered: