fix: fix class and resource loading in maven plugin #20465
Conversation
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
force-pushed
the
issues/19616-maven-plugin-classloading-attempt-3
branch
from
0e40272
to
4304c03
Compare
|
If this PR gets merged, the only change in Hilla should be fixing mock configuration in |
flow-plugins/flow-maven-plugin/src/test/java/com/vaadin/flow/plugin/maven/ReflectorTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Reflector class is in two places. My comments apply in both.
Could Reflector and also some methods in BuildDevBundleMojo and FlowModeAbstractMojo go in shared flow-plugin-base module? There's already dependency to flow-plugin-base and both mojo's seem to use classes from there. See BuildFrontendUtil for example.
flow-plugins/flow-dev-bundle-plugin/src/main/java/com/vaadin/flow/plugin/maven/Reflector.java
Show resolved
Hide resolved
flow-plugins/flow-dev-bundle-plugin/src/main/java/com/vaadin/flow/plugin/maven/Reflector.java
Show resolved
Hide resolved
flow-plugins/flow-dev-bundle-plugin/src/main/java/com/vaadin/flow/plugin/maven/Reflector.java
Outdated
Show resolved
Hide resolved
I was thinking the same, but followed the current solution of copy/pasting code between mojos. |
|
Looking at the code again, what blocks me from moving Reflector to the common module is that it references Maven API but the module is used also by gradle plugin. |
OK, we can just keep the copy now for this PR and not let that block merging. |
|
mshabarov
deleted the
issues/19616-maven-plugin-classloading-attempt-3
branch
|
Hi @mcollovati and @mshabarov, when i performed cherry-pick to this commit to 24.5, i have encountered the following issue. Can you take a look and pick it manually? |
|
Hi @mcollovati and @mshabarov, when i performed cherry-pick to this commit to 24.4, i have encountered the following issue. Can you take a look and pick it manually? |
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
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
Refactoring required by changes in vaadin/flow#20465.
Refactoring required by changes in vaadin/flow#20465. Co-authored-by: Zhe Sun <[email protected]>
Refactoring required by changes in vaadin/flow#20465. Co-authored-by: Zhe Sun <[email protected]>
Refactoring required by changes in vaadin/flow#20465. Co-authored-by: Zhe Sun <[email protected]>
…2912) test: refactor mock setup in maven plugin tests (#2911) Refactoring required by changes in vaadin/flow#20465. Co-authored-by: Marco Collovati <[email protected]> Co-authored-by: Zhe Sun <[email protected]>
…2913) test: refactor mock setup in maven plugin tests (#2911) Refactoring required by changes in vaadin/flow#20465. Co-authored-by: Marco Collovati <[email protected]> Co-authored-by: Zhe Sun <[email protected]> Co-authored-by: Soroosh Taefi <[email protected]>
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
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
Description
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
Type of change
Checklist
Additional for
Featuretype of change