2012/5/22 Olivier Lamy <[email protected]>:
> 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.
Nope in fact. Some use cases makes that impossible.
Sample from war plugin:
/**
* @component role="org.codehaus.plexus.archiver.Archiver" role-hint="jar"
*/
private JarArchiver jarArchiver;
So we need role attribute/information to know the type for writing the
plugin descriptor.
And @Inject doesn't have that.
>
>>
>>>> - 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
--
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]