Here's a brief overview of the different layers... Maven plugin annotations are only used at plugin build time to generate Maven's plugin.xml - they are not used at runtime (at least the container doesn't use them)
Maven uses this plugin.xml descriptor to setup the plugin in Plexus (creating the class realm, registering component descriptors as well as arranging for parameter processing - which builds on the converter API provided by Plexus) Plexus is now a facade on top of Sisu. This facade provides the expected API, mapping calls to Sisu and using listeners/adapters to mimic Plexus behaviour - such as limiting component visibility based on realm visibility. (This was developed from scratch by observing what APIs were used by Plexus based apps, mainly Maven, and iterating until the API surface and behaviour matched) Plexus bindings (be that defined in components.xml, Plexus annotations, or registered programmatically) are canonicalized as Guice bindings to provide interoperability with JSR330. Sisu provides a flexible bean layer on top of Guice. It also adds extra dynamics such as injected collections that track components provided by different injectors (in the Maven-Plexus-Guice mapping a plugin is represented by a single injector) as well as the ability to look up or watch for components across multiple injectors. Circling back to the original question: yes you can override components in recent versions of Maven but there are some caveats. First your component must be visible to the plugin (ie be in the same realm or a parent/imported realm like an extension). Second you'll need to use the priority annotation to raise its priority (default components get a low positive priority, based on their realm order - non-default components get a negative priority). If someone puts together a buildable example that should work, but isn't then I'm happy to take a look - just in case you're hitting an edge-case - it would also help me flesh out the documentation on the wiki. HTH -- Cheers, Stuart On 3 Feb 2017 11:47, "Robert Scholte" <rfscho...@apache.org> wrote: > On Fri, 03 Feb 2017 12:39:56 +0100, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: > > Le vendredi 3 février 2017, 10:43:42 CET Robert Scholte a écrit : >> >>> What I expect to happen is that Plexus Component Annotations will be >>> fully >>> replaced with JSR330 annotations. >>> In that case there will be only 1 @Component annotation, i.e. >>> org.apache.maven.plugins.annotations.Component, which is fine by me. >>> >> We should document that >> >> Notice that plexus @Component is not equivalent to @Inject: Plexus >> @Requirement is equivalent to @Inject >> >> And for Maven Plugin Tools, since it is used to generate plugin.xml, >> having an >> annotation that matches the XML fragment will help. >> >> The more I think at it, the more I think Maven Plugin Tools should promote >> @Requirement (and we don't care that it is the same name as the >> @Requirement >> from Plexus, that means @Inject with JSR330) >> >> Also, I expect the community to be more familiar with the maven plugin >>> annotations than with plexus annotations. >>> >> I documented how to switch from Plexus javadoc to Plexus annotations: is >> there >> some doc on switching from Plexus annotations to JSR330? >> > > https://wiki.eclipse.org/Sisu/PlexusMigration > > >> Keep in mind that the original question is actually: can I >>> override/redefine the default implementation for a 'service'? >>> >> that's not this email thread: I suppose you're referring to an other >> discussion >> >> Regards, >> >> Hervé >> >> The >>> discussion about the annotations caused extra confusion but in the end >>> had >>> nothing to do with the issue. >>> >>> thanks, >>> Robert >>> >>> On Fri, 03 Feb 2017 10:15:05 +0100, Hervé BOUTEMY <herve.bout...@free.fr >>> > >>> >>> wrote: >>> > notice:@Component we're using in a Mojo is from Maven Plugin Tools >>> > org.apache.maven.plugins.annotations.Component [1] >>> > >>> > it's different from @Component from Plexus, which is >>> > org.codehaus.plexus.component.annotations.Component [2] >>> > >>> > Using the same class name in a different package is probably a bad >>> idea, >>> > because it's really confusing, sorry: perhaps we should deprecate >>> > @Component >>> > in Maven Plugin Tools and create an annotation with another name. >>> > Any idea on a new name? >>> > >>> > >>> > Then Maven Plugin Tools uses its annotations (@Mojo, @Execute, >>> > @Parameter and >>> > @Component in org.apache.maven.plugins.annotations) to generate >>> META-INF/ >>> > maven/plugin.xml plugin descriptor [3] . @Component annotation is more >>> > precisely at the source of >>> > >>> > <requirements> >>> > >>> > <requirement> >>> > >>> > <role/> >>> > <role-hint/> >>> > <field-name/> >>> > >>> > </requirement> >>> > >>> > </requirements> >>> > >>> > part >>> > >>> > Perhaps creating a @Requirement annotation in Maven Plugin Tools to >>> > replace >>> > @Component would reduce confusion: it would still not make a very >>> visible >>> > difference between @Requirement from Maven Plugin Tools and >>> @Requirement >>> > from >>> > Plexus [2]: but at least, both @Requirement annotations would have the >>> > same >>> > meaning >>> > >>> > WDYT? >>> > >>> > Regards, >>> > >>> > Hervé >>> > >>> > >>> > [1] http://maven.apache.org/plugin-tools/maven-plugin-tools- >>> annotations/ >>> > index.html#Supported_Annotations >>> > >>> > [2] >>> > http://codehaus-plexus.github.io/plexus-containers/plexus-co >>> mponent-annota >>> > tions/ >>> > >>> > [3] http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html >>> > >>> > Le mercredi 1 février 2017, 20:01:10 CET Laird Nelson a écrit : >>> >> Thanks; yeah, I understand--maybe I don't actually--that there are >>> >> certain >>> >> Maven plugin annotations that get converted into the XML descriptor. >>> >> But >>> >> >>> >> what about line 52 and following in the link you sent: >>> >> 1. @Component( role = MyComponentExtension.class, >>> >> 2. hint = "..." ) >>> >> 3. private MyComponent component; >>> >> >>> >> Shouldn't that be replaced with JSR-330? Very confused; sorry! >>> >> >>> >> Best, >>> >> Laird >>> >> >>> >> On Wed, Feb 1, 2017 at 11:59 AM Robert Scholte <rfscho...@apache.org> >>> >> >>> >> wrote: >>> >> > No, plugin annotation are used to generate a plugin descriptor, i.e. >>> >> > META-INF/maven/plugin.xml >>> >> > At runtime this file is used to initialize the plugin, whereas the >>> >> > specified components are injected with sisu/guice >>> >> > >>> >> > Robert >>> >> > >>> >> > On Wed, 01 Feb 2017 20:52:19 +0100, Laird Nelson < >>> ljnel...@gmail.com> >>> >> > >>> >> > wrote: >>> >> > > Thanks. But isn't _that_, in turn, replaced by JSR-330? This is >>> >> >>> >> what >>> >> >>> >> > > I'm >>> >> > > confused about. >>> >> > > >>> >> > > On Wed, Feb 1, 2017 at 11:26 AM Robert Scholte >>> >> >>> >> <rfscho...@apache.org> >>> >> >>> >> > > wrote: >>> >> > >> This is what is used nowadays: >>> >> https://maven.apache.org/components/plugin-tools/maven-plugi >>> n-tools-annot >>> >> a >>> >> >>> >> > tions/index.html> >>> >> > >>> >> > >> Robert >>> >> > >> >>> >> > >> On Wed, 01 Feb 2017 19:21:09 +0100, Laird Nelson >>> >> >>> >> <ljnel...@gmail.com> >>> >> >>> >> > >> wrote: >>> >> > >> > I apologize in advance for the inarticulate nature of this >>> >> >>> >> question. >>> >> >>> >> > >> > I have this faint sense that Sisu and Guice are at the core of >>> >> >>> >> Maven >>> >> >>> >> > >> > these >>> >> > >> > days, with a Plexus layer on top. >>> >> > >> > >>> >> > >> > This makes me think that perhaps I should be using different >>> >> > >> >>> >> > >> annotations >>> >> > >> >>> >> > >> > in >>> >> > >> > my maven plugins than @Component etc. >>> >> > >> > >>> >> > >> > Is this ( >>> >> >>> >> https://maven.apache.org/guides/plugin/guide-java-plugin- >>> development.html >>> >> ) >>> >> >>> >> > >> > still the official guide for writing Maven plugins? If I >>> wanted >>> >> >>> >> to >>> >> >>> >> > >> > inject >>> >> > >> > some named Plexus component, is there some guide showing how to >>> >> >>> >> do >>> >> >>> >> > >> that? >>> >> > >> >>> >> > >> > Thanks, >>> >> > >> > Best, >>> >> > >> > Laird >>> >> >>> >> --------------------------------------------------------------------- >>> >> >>> >> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> >> > >> For additional commands, e-mail: users-h...@maven.apache.org >>> >> > >>> >> > ------------------------------------------------------------ >>> --------- >>> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> >> > For additional commands, e-mail: users-h...@maven.apache.org >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> > For additional commands, e-mail: users-h...@maven.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
