I have another proposal: add an attribute to @Component this will let time to think at standard annotation, with annotations still near old javadoc tags, and fixing Brett's concerns about @Parameter(readonly) (ie a parameter that is not a parameter)
then @Component would have 2 use case: Plexus injection or Maven injection @Component( role = X.class, hint = "xxx" ) @Component( expression = "project" ) it's quite the same as actually, but would remove readonly WDYT? Hervé Le mardi 22 mai 2012 20:47:56 Robert Scholte a écrit : > Op Tue, 22 May 2012 20:32:46 +0200 schreef Brett Porter <[email protected]>: > > On 22/05/2012, at 7:42 PM, Olivier Lamy wrote: > >> 2012/5/22 Brett Porter <[email protected]>: > >>> On 22/05/2012, at 6:37 AM, Hervé BOUTEMY wrote: > >>>> I understand the point > >>>> but I don't think reworking javadoc tags too much now is a good idea: > >>>> javadoc > >>>> tags are not easy to check when using them > >>>> instead, it is important to carefully choose java 5 annotations, > >>>> which are > >>>> checked at compile time, with IDE completion when writing source > >>> > >>> I absolutely agree on this - sorry I didn't make that clear. > >>> > >>>> @Parameter( defaultValue = "${project}", readonly = true ) is ok for > >>>> me > >>>> > >>>> creating a new annotation just to avoid readonly doesn't deserve it > >>>> IMHO > >>> > >>> I don't think that's very clear, as it still implies a project is a > >>> "parameter" when it is really a "special" type of injection. And then > >>> you have a "default" value which implies you can customise it, and a > >>> readonly attribute that says you can't :) It has bothered me a while - > >>> we shouldn't ask the plugin developer to tell us something (readonly) > >>> that we can already infer. > > I agree on this one. This might solve another problem that I face every > now and then: which "special" expressions/parameters are available? > > >>> Maybe time to consolidate, and align the names at the same time, while > >>> still spitting out a compatible plugin.xml for current Maven versions? > >>> > >>> @javax.inject.Inject > >>> - use underlying DI framework > >> > >> ? I miss you here. You mean at runtime level ? So that won't with > >> current core (2.x or 3.x) > > > > I may have misunderstood what you said earlier, but I thought the > > runtime operated off of plugin.xml still - and the plugin tools could > > parse any annotation into that, so we were free to use the standard > > ones. In the future, the core could well use that more directly, which > > would also be easier if it's a standard annotation. > > > >>> - replaces @component > >>> - make sure this works as expected for at least MavenSession, which > >>> gives us access to all the old parameter expressions (project, > >>> session, settings, etc.) > >>> - use @Provider for collections > >>> > >>> @Configuration( defaultValue, required ) > >> > >> A new annotation ? > > > > Pretty much just renaming and simplifying @Parameter to match the name > > used in the POM and avoid confusion with the historical Javadoc tag. > > > >>> - replaces parameter to construct the fields needed for > >>> <configuration> in the POM. > >>> - use @Named for alias > >>> - could even replace required with some form of @NotNull/@Nullable > >>> (http://code.google.com/p/google-guice/wiki/UseNullable, or JSR 303). > >>> - If you're already using ASM you can probably also pull defaultValue > >>> out of an initial assignment instead > >>> > >>> deprecated, description, since, etc. were already addressed in the > >>> earlier thread. > >>> > >>> Olivier, I know you already have this working with the current > >>> annos... would this fit or am I way off base? :) > >> > >> That's not the problem. > >> My issue is to use some stuff like @Inject which we don't handle at > >> runtime on core. > >> > >>> - Brett > >>> > >>> > >>> -- > >>> Brett Porter > >>> [email protected] > >>> http://brettporter.wordpress.com/ > >>> http://au.linkedin.com/in/brettporter > >>> http://twitter.com/brettporter > >>> > >>> > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >> > >> -- > >> Olivier Lamy > >> Talend: http://coders.talend.com > >> http://twitter.com/olamy | http://linkedin.com/in/olamy > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > -- > > Brett Porter > > [email protected] > > http://brettporter.wordpress.com/ > > http://au.linkedin.com/in/brettporter > > http://twitter.com/brettporter > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
