during a maven build, reflections is invoked several times #20385
Comments
|
The main reason for that is that
|
mshabarov
moved this to 🅿️Parking lot - under consideration
in Vaadin Flow ongoing work (Vaadin 10+)
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
mcollovati
added a commit
that referenced
this issue
Nov 13, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
9 tasks
mcollovati
added a commit
that referenced
this issue
Nov 13, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
github-project-automation
bot
moved this from Maybe
to Done / Pending Release
in Vaadin Flow enhancements backlog (Vaadin 10+)
github-project-automation
bot
moved this from 🅿️Parking lot - under consideration
to Done
in Vaadin Flow ongoing work (Vaadin 10+)
github-project-automation
bot
moved this from 🅿️Parking lot - under consideration
to Done
in Vaadin Flow ongoing work (Vaadin 10+)
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
mcollovati
added a commit
that referenced
this issue
Nov 20, 2024
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. Fixes #19616 Fixes #19009 Fixes #20385
|
This ticket/PR has been released with Vaadin 24.4.18. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: