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
Currently we can gather dependencies from the project and plugin def (+ additional elements) but it is impossible to solve conflicts with exclusions properly (in particular if you have multiple executions).
To add to that issue, the classloader used to do the exec is not a child first but a parent first so we inherit from the mojo classloader tree which is highly unlikely.
This issue is about ensuring classpath is more controlled but is not about fully isolating the exec from the parent classloader (would break too much projects I think and would need more thoughts about the design of the config (list of classes? packages? jars?...).
Example: it is insanely common with slf4j to have N > 1 bindings due to that.
The text was updated successfully, but these errors were encountered:
…with-exclusion-support
Fixes#160, ensure the java classloader is a child first one and supports to excludes some gathered classpath element to solve manually conflicts
Currently we can gather dependencies from the project and plugin def (+ additional elements) but it is impossible to solve conflicts with exclusions properly (in particular if you have multiple executions).
To add to that issue, the classloader used to do the exec is not a child first but a parent first so we inherit from the mojo classloader tree which is highly unlikely.
This issue is about ensuring classpath is more controlled but is not about fully isolating the exec from the parent classloader (would break too much projects I think and would need more thoughts about the design of the config (list of classes? packages? jars?...).
Example: it is insanely common with slf4j to have N > 1 bindings due to that.
The text was updated successfully, but these errors were encountered: