2012/5/22 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.
>>>
>>> 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.

Ok makes sense.
Looks good for me.

>
>>> - 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.

Ok I understand :-)
So no real strong idea on that. both are fine (but @Configuration is
used somewhere else :-) )

>
>>> - 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]
>



-- 
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]

Reply via email to