Le lundi 21 mai 2012 20:58:08 Mark Struberg a écrit : > > Nothing is done at maven execution time (as we will need some core > > changes for that) and IMHO this could slow execution. > > This depends on whether we do a full ClassPath scan or still have some parts > in the XML. With e.g. CDI it would also be possible to use the existing > plugin.xml and provide all the meta-information via the Extension SPI. That > works fine and I know folks who have even written a CDI Extension which > takes a Spring-XML and feeds the BeanManager with it. > > But of course we need to be careful and think hard about a possible > performance impact. LieGrue, > strub IIUC, that means that if Maven Plugin Tools annotations 3.0 are widely used, we can imagine for Maven 3.1 (or 3.2 or...) that the core gets as much info as possible from annotations content instead of plugin.xml, only Mojo class names would be in a resource file then this would deprecate the plugin descriptor generator
that's a future in a long time, when we don't need plugins compatibility with even Maven 3.0: far far away! Regards, Hervé > > > ----- Original Message ----- > > > From: Olivier Lamy <ol...@apache.org> > > To: Maven Developers List <dev@maven.apache.org> > > Cc: > > Sent: Monday, May 21, 2012 5:06 PM > > Subject: Re: Maven Plugins annotations support @Component role attribute > > to Class<?>> > > 2012/5/21 Brett Porter <br...@apache.org>: > >> On 21/05/2012, at 9:03 PM, Olivier Lamy wrote: > >>> 2012/5/21 Brett Porter <br...@apache.org>: > >>>> On 21/05/2012, at 3:45 AM, Hervé BOUTEMY wrote: > >>>>> here, the end-user is a plugin developer, then someone who > > > > should be able to > > > >>>>> create a (Plexus) component when necessary > >>>>> > >>>>> Yes, I liked @Component too but as soon as you write a > > > > component and inject > > > >>>>> somponents inside it, you discover the discrepency: the more I > > > > work on this, > > > >>>>> the more I discover these little discrepencies that lost me for > > > > a long time. > > > >>>>> Notice that the target is JSR330 @Inject. > >>>>> Is it too early to use @Inject? > >>>> > >>>> Agree - I didn't think @component (the Javadoc annotation) > > > > would carry over to the plugin annotation. It should just use @Inject if > > that's feasible. > > > >>> Yup possible > >>> @Inject > >>> @Named( value = "maven" ) > >>> protected ArtifactMetadataSource artifactMetadataSource; > >>> > >>> But not possible anymore for > >>> @Component( role = ArtifactMetadataSource.class, roleHint = > > > > "maven" ) > > > >>> protected Object artifactMetadataSource; > >>> > >>> but not sure it's a real problem for this "feature" :-) > >>> > >>> But again we use annotations here only for plugin metadata generation > >>> and not at runtime. > >>> > >>> Maybe in the future we could handle @Inject at runtime level. > >>> > >>> But IMHO classpath scanning at runtime to find various annotations > >>> will have a huge performance impact whereas simply reading the xml > >>> plugin descriptor is fast. > >>> And that's what we need with a tool such Maven fast > > > > startup/execution. > > > >> I'm way behind on some of this stuff, but I thought the Maven side > > > > scanned these at build time and constructed the component metadata - so > > you have both available. The plugin processor would do the same... > > Olivier? > > > > Yup even with annotations everything is done in maven-plugin-plugin > > which generate plugin descriptor. > > Nothing is done at maven execution time (as we will need some core > > changes for that) and IMHO this could slow execution. > > > >> - Brett > >> > >> -- > >> Brett Porter > >> br...@apache.org > >> http://brettporter.wordpress.com/ > >> http://au.linkedin.com/in/brettporter > >> http://twitter.com/brettporter > >> > >> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
