On 22/05/2012, at 7:42 PM, Olivier Lamy wrote:
> 2012/5/22 Brett Porter <br...@apache.org>:
>> 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.
>>
>> 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
>> 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
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
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
