Hi again I can't go into details because it's a proprietary extension, but we need to change the behaviour of - *DefaultMavenPluginManager*: we need to intercept calls to Mojo#execute so here we proxy the Mojo class that is created from the mojoInterface with some custom stuffs - *DefaultBuildPluginManager*: we decorate the #executeMojo with some custom calls to internal classes of ours
For now, all is good. I just realized the overridden components might not come from the expected extension so let's say we are theorizing about some possible future binary breakage. You can find attached a small reproducer: https://drive.google.com/file/d/1M-wfS8E_VgHF6qd1CthkHQuzkYEMqNe1/view?usp=sharing (I could not attach the zip directly to Gmail ...) To reproduce, once unzipped: - ./mvnw clean install => install 1.0 in your local repo - change version to 2.0 in pom.xml - ./mvnw clean install => install 2.0 in your local repo - add ".mvn/extensions.xml" with ---------- <?xml version="1.0" encoding="UTF-8"?> <extensions> <extension> <groupId>org.example</groupId> <artifactId>double-core-bindings-override</artifactId> <version>1.0</version> </extension> </extensions> ---------- - execute ./mvnw validate -Dmaven.ext.class.path=${HOME}/.m2/repository/org/example/double-core-bindings-override/2.0/double-core-bindings-override-2.0.jar You should then see sth like [INFO] Found MyExtension in realm 'maven.ext' [INFO] Found MyExtension in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Inside MyExtension#init for extension loaded in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Instantiating MyPluginManager for extension loaded in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Using the MavenPluginManager 'MyPluginManager' from realm ' coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Inside MyExtension#init for extension loaded in realm 'maven.ext' [INFO] Using the MavenPluginManager 'MyPluginManager' from realm ' coreExtension>org.example:double-core-bindings-override:2.0' The extension from maven.ext (extension version 1.0) is found and injected The extension from extensions.xml (extension version 2.0) is found and injected The #init for the 2.0 extension is called The #init for the 1.0 extension is called (maven.ext) Only the MyPluginManager instance from extension 2.0 is present, even when called from the extension 1.0. I understand why this happens but this is potentially dangerous. I tried various ways to avoid that from happening but failed. Hence my question, is there a better way to declare core overrides than in components.xml ? Also, side question, when I'm changing the META-INF/maven/extension.xml to contain <exportedPackages> <exportedPackage>org.example</exportedPackage> </exportedPackages> Then, the problem 'goes away': [INFO] Found MyExtension in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Found MyExtension in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Inside MyExtension#init for extension loaded in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Instantiating MyPluginManager for extension loaded in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Using the MavenPluginManager 'MyPluginManager' from realm ' coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Inside MyExtension#init for extension loaded in realm 'coreExtension>org.example:double-core-bindings-override:2.0' [INFO] Using the MavenPluginManager 'MyPluginManager' from realm ' coreExtension>org.example:double-core-bindings-override:2.0' Can you explain what exactly happens in this case ? Maybe I could leverage that to solve my double application problem ? many thanks, François Le mar. 28 juin 2022 à 13:26, Tamás Cservenák <ta...@cservenak.net> a écrit : > In other words, why do you need to override MavenPluginManager in several > different ways? > (or we just theoretize, about some possible future binary breakage?) > > T > > On Tue, Jun 28, 2022 at 1:12 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > Ok, > > > > best would be to create then a reproducer, but have to note: > > while Maven can "protect" (warn) about duplicate/wrong plugin > > declarations, as "lower" we go (and extensions, especially when you throw > > things into lib/ext) are earlier and earlier on the bootstrap of Maven, > and > > it cannot do much there... > > Hence, while Maven tries its best to protect you (users) from mistakes, > it > > cannot always do it, especially when things are just added to > classpath.... > > > > Also, non-backward compatible with your implementation of the Maven > > component (interface) of MavenPluginManager? > > Again, I'd really like to see what happens here, what the extension > intent > > is, not only "reproducer" for "multiple extensions override the same > > component". > > > > Tamas > > > > On Tue, Jun 28, 2022 at 12:32 PM François Guillot < > > francoisguillo...@gmail.com> wrote: > > > >> Hi Tamás, > >> > >> I have one extension (say 'MyExtension'), that declares a binding > override > >> for MavenPluginManager. > >> MyExtension is not supposed to be applied several times per build, and > I'm > >> trying my best to keep only one of them 'active' if that happens. > >> Given there are various ways to declare extensions > ('.mvn/extensions.xml', > >> 'lib/ext' in Maven installation, '-Dmaven.ext.class.path'), the order of > >> applications of extensions, the fact they are not loaded in the same > >> classloader makes it a bit hard to do. > >> But I'm managing that. > >> The only thing I'm not managing 'in code' is controlling which extension > >> wins and overrides the Maven core bindings. > >> > >> I'm thinking ahead if at some point I'm making a non backward compatible > >> change (wrt to my extension code) in my implementation of > >> MavenPluginManager, than I can be in trouble, where the 'chosen' > >> MavenPluginManager implementation will not be compatible with the > 'chosen' > >> MyExtension. > >> > >> I can't share the code of my extension, but I could produce a little > >> reproducer with a noop extension to show you what I mean. > >> > >> Le mar. 28 juin 2022 à 11:45, Tamás Cservenák <ta...@cservenak.net> a > >> écrit : > >> > >> > Howdy, > >> > > >> > I am a bit uncertain if I correctly understand your problem: so you > have > >> > several MavenPluginManager implementations in several extensions, and > >> those > >> > extensions are not compatible with each other? > >> > > >> > Could we step back a little and could you explain what your extension > is > >> > doing? Best if you could show us some sources? > >> > > >> > HTH > >> > Tamas > >> > > >> > > >> > > >> > On Tue, Jun 28, 2022 at 10:18 AM François Guillot < > >> > francoisguillo...@gmail.com> wrote: > >> > > >> > > Hi, > >> > > > >> > > I need to override some default Maven bindings in my custom > extension, > >> > for > >> > > instance "org.apache.maven.plugin.MavenPluginManager" > >> > > > >> > > I'm doing this by providing a "META-INF/plexus/components.xml" in my > >> > > extension's jar with > >> > > << > >> > > > >> > > <?xml version="1.0" encoding="UTF-8"?> > >> > > <component-set> > >> > > <components> > >> > > <component> > >> > > <role>org.apache.maven.plugin.MavenPluginManager</role> > >> > > <implementation>com.acme.MyMavenPluginManager</implementation> > >> > > > >> > > </component> > >> > > </components> > >> > > </component-set> > >> > > > >> > > >> > >> > > > >> > > This works fine, but this has limitations. > >> > > If for some reasons, my extension is applied twice or more to the > >> build, > >> > > then all of these applications will override the Maven core binding. > >> My > >> > > finding is that the last application wins. > >> > > This can be problematic if the user is applying several _versions_ > of > >> my > >> > > extension (probably unknowingly), because the overridden > >> > MavenPluginManager > >> > > might be coming from a version of my extension that is not > compatible > >> > with > >> > > the code in the other one. > >> > > > >> > > Is there a more programmatic way to override Maven core bindings, > that > >> > > would allow me to decide whether a given extension should perform > the > >> > > override or not ? > >> > > > >> > > >> > > >
