Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

during a maven build, reflections is invoked several times #20385

Open
jorgheymans opened this issue Oct 30, 2024 · 1 comment
Open

during a maven build, reflections is invoked several times #20385

jorgheymans opened this issue Oct 30, 2024 · 1 comment

Comments

@jorgheymans
Copy link

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:

 [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

@mcollovati
Copy link
Collaborator

mcollovati commented Oct 30, 2024

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

mcollovati added a commit that referenced this issue Nov 12, 2024
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 #19616
Fixes #19009
Fixes #20385
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🅿️Parking lot - under consideration
Development

Successfully merging a pull request may close this issue.

3 participants