hboutemy commented on PR #92: URL: https://github.com/apache/maven-apache-parent/pull/92#issuecomment-1537064345
> This issue looks legit to me wrt to [MNG-5697](https://issues.apache.org/jira/browse/MNG-5697). @hboutemy do you mind explaining your position ? Robert opened MNG-5697 as a long term target, that shows an ideal situation where plugins can provide their lifecycle mapping themselves instead of having core define everything for them https://maven.apache.org/ref/3.9.1/maven-core/default-bindings.html perfect objective. Has Maven core the features required for that? NO. Why is this "plugin as extension" feature not ok? Marking a plugin as an extension puts *all its classes and dependencies* in Maven core classloader: this obviously covers the wanted lifecycle binding from the plugin, I understand the idea from this PR. But this also covers every dependency from the plugin: classloaders from plugins marked as extension are not isolated any more, Maven core classloader mixes dependencies from everything; This is a recipe for conflicts: per-plugin classloader was exactly done to avoid such issue for MNG-5697 to work, there are multiple Maven core feature required: 1. contributing only partial content of a plugin to core classloader 2. a way to load this early in the build lifecycle: IIRC, the current class loading of a plugin happens late, but for contributing a new lifecycle binding requires to happen very early: This is what is described in the Jira issue in bold **Maven core should then get the lifecycle mappings and artifact handlers configurations from the plugin at the beginning of the build, before begin able to calculate the build plan** For plugins that have their bindings coded in Maven core, this is hard to see because you benefit from default bindings, and it's not to check that it's plugin-provided binding that has been used instead of core one Try with a plugin that has no default binding and this "early load" aspect will be very visible -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
