On Tue, Jul 25, 2023 at 8:57 PM Slawomir Jaranowski <s.jaranow...@gmail.com> wrote:
> It is very magical that we export classes but not export artifact > which contains those classes ... > > So, just to clear up: For ref http://takari.io/book/91-maven-classloading.html In relation to https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/resources/META-INF/maven/extension.xml "export package" => the package is imported by child classloader (or in other words, is exported by core) "export artifact" => (and this may be surprising) HAS NO DIRECT CLASSLOADER EFFECT, this is more like whole artifact is IGNORED/not added to child classloader CP, despite artifact has dependency on it (keyed by GA, V ignored), as assumption is that core "export package" provides replacement And one more remark: classrealms created are "self first" (so they consult themselves first, then parent), EXCEPT for imported entries that always come from import (someone correct me if I am wrong here). And plugin realms have Maven API imported (!) if no extension, or have Maven API as parent and imported extension, if any, Conclusion: "exported package" ALWAYS OVERRIDE classes, whatever plugin does (sans shading, of course). Digression: You may remember, that this was the whole point of "provided" changes sweeping across plugins: - in Maven 3.8.x times, such artifacts were collected/resolved (jar downloaded to local repo) only to be omitted from CP --> waste of time, bandwidth and confusing to users: after build their local repo contained million different Vs of things like maven-core (all the versions that each plugins were coded against) - with "provided" scope this does not happen anymore (is not collected nor resolved/downloaded) - but, we had experiments in this area (for example https://issues.apache.org/jira/browse/MNG-7097) that led to the first "provided" solution (but it needed a bugfix in MPP) - moreover, extension.xml changes are to be expected, as there are other upcoming experiments (and we'd need V, so "exported artifacts" should be expanded to GAV at least (probably at build time) - and based on that, next "major improvement" (in guided resolution) improving speed and all is something along this line: https://github.com/apache/maven/pull/1188 (where Maven Core, "knowing itself constituents" already auto-injects itself as depMgt for plugins) And sorry for the thread hijack... === As for current thread: Given our goal is to totally decouple plexus-utils, maybe we want instead this: <!-- plexus-utils (for DOM-type fields in maven-model) --> <exportedPackage>org.codehaus.plexus.util.xml.Xpp3Dom</exportedPackage> <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlPullParser</exportedPackage> <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlPullParserException</exportedPackage> <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlSerializer</exportedPackage> to have this? <!-- plexus-utils (for DOM-type fields in maven-model) --> <exportedPackage>org.codehaus.plexus.util.xml</exportedPackage> ?
