You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Hervé BOUTEMY <he...@free.fr> on 2012/05/13 21:59:01 UTC
Maven Plugin Tools - renaming "expression"
As discussed previously, there was some interest in changing supported tags.
Now that Java 5 annotations support is ok, I already added some change in
MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
where ${ } would even not be supported
Please comment: any objection? any better idea?
Regards,
Hervé
[1] https://jira.codehaus.org/browse/MPLUGIN-194
[2] https://jira.codehaus.org/browse/MPLUGIN-196
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
Op Mon, 14 May 2012 22:13:52 +0200 schreef Olivier Lamy <ol...@apache.org>:
> 2012/5/14 Robert Scholte <ap...@sourcegrounds.com>:
>> I like these adjustments, but there's one spot which is probably even
>> more
>> important: the specific goal-page.
>>
>> Just an example:
>> ---
>> failOnError:
>>
>> Indicates whether the build will continue even if there are clean
>> errors.
>> •Type: boolean
>> •Since: 2.2
>> •Required: No
>> •Expression: ${maven.clean.failOnError}
>> •Default: true
>> ---
>>
>> I'm not sure how we could make it clear how to use
>> expressions/properties.
>> Some global description on this page?
>>
>> Or an easy to copy-paste line like:
>> •Commandline argument: -Dmaven.clean.failOnError=
>
> can come from project.properties or settings.properties.
> So that's not the only way to configure that :-)
True, although less usual, but that could be solved with an additional
<maven.clean.failOnError></maven.clean.failOnError> :P
I guess to keep it a bit clean we should either describe it on top of the
page or refer to a (new?) general plugin usage page.
>>
>> -Robert
>>
>> Op Mon, 14 May 2012 17:59:58 +0200 schreef Olivier Lamy
>> <ol...@apache.org>:
>>
>>
>>> Perso, no special idea/comments on that.
>>> The current "expression" looks fine and "property" too.
>>>
>>> 2012/5/13 Hervé BOUTEMY <he...@free.fr>:
>>>>
>>>> As discussed previously, there was some interest in changing supported
>>>> tags.
>>>>
>>>> Now that Java 5 annotations support is ok, I already added some
>>>> change in
>>>> MPLUGIN-194 [1]: you can remove ${ } when defining parameter
>>>> expression
>>>>
>>>> I just created MPLUGIN-196 issue [2] to rename "expression" to
>>>> "property",
>>>> where ${ } would even not be supported
>>>>
>>>> Please comment: any objection? any better idea?
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>>
>>>> [1] https://jira.codehaus.org/browse/MPLUGIN-194
>>>>
>>>> [2] https://jira.codehaus.org/browse/MPLUGIN-196
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
2012/5/14 Robert Scholte <ap...@sourcegrounds.com>:
> I like these adjustments, but there's one spot which is probably even more
> important: the specific goal-page.
>
> Just an example:
> ---
> failOnError:
>
> Indicates whether the build will continue even if there are clean errors.
> •Type: boolean
> •Since: 2.2
> •Required: No
> •Expression: ${maven.clean.failOnError}
> •Default: true
> ---
>
> I'm not sure how we could make it clear how to use expressions/properties.
> Some global description on this page?
>
> Or an easy to copy-paste line like:
> •Commandline argument: -Dmaven.clean.failOnError=
can come from project.properties or settings.properties.
So that's not the only way to configure that :-)
>
> -Robert
>
> Op Mon, 14 May 2012 17:59:58 +0200 schreef Olivier Lamy <ol...@apache.org>:
>
>
>> Perso, no special idea/comments on that.
>> The current "expression" looks fine and "property" too.
>>
>> 2012/5/13 Hervé BOUTEMY <he...@free.fr>:
>>>
>>> As discussed previously, there was some interest in changing supported
>>> tags.
>>>
>>> Now that Java 5 annotations support is ok, I already added some change in
>>> MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
>>>
>>> I just created MPLUGIN-196 issue [2] to rename "expression" to
>>> "property",
>>> where ${ } would even not be supported
>>>
>>> Please comment: any objection? any better idea?
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>
>>> [1] https://jira.codehaus.org/browse/MPLUGIN-194
>>>
>>> [2] https://jira.codehaus.org/browse/MPLUGIN-196
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
I like these adjustments, but there's one spot which is probably even more
important: the specific goal-page.
Just an example:
---
failOnError:
Indicates whether the build will continue even if there are clean errors.
•Type: boolean
•Since: 2.2
•Required: No
•Expression: ${maven.clean.failOnError}
•Default: true
---
I'm not sure how we could make it clear how to use expressions/properties.
Some global description on this page?
Or an easy to copy-paste line like:
•Commandline argument: -Dmaven.clean.failOnError=
-Robert
Op Mon, 14 May 2012 17:59:58 +0200 schreef Olivier Lamy <ol...@apache.org>:
> Perso, no special idea/comments on that.
> The current "expression" looks fine and "property" too.
>
> 2012/5/13 Hervé BOUTEMY <he...@free.fr>:
>> As discussed previously, there was some interest in changing supported
>> tags.
>>
>> Now that Java 5 annotations support is ok, I already added some change
>> in
>> MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
>>
>> I just created MPLUGIN-196 issue [2] to rename "expression" to
>> "property",
>> where ${ } would even not be supported
>>
>> Please comment: any objection? any better idea?
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1] https://jira.codehaus.org/browse/MPLUGIN-194
>>
>> [2] https://jira.codehaus.org/browse/MPLUGIN-196
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
Perso, no special idea/comments on that.
The current "expression" looks fine and "property" too.
2012/5/13 Hervé BOUTEMY <he...@free.fr>:
> As discussed previously, there was some interest in changing supported tags.
>
> Now that Java 5 annotations support is ok, I already added some change in
> MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
>
> I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
> where ${ } would even not be supported
>
> Please comment: any objection? any better idea?
>
> Regards,
>
> Hervé
>
>
> [1] https://jira.codehaus.org/browse/MPLUGIN-194
>
> [2] https://jira.codehaus.org/browse/MPLUGIN-196
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
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 <br...@apache.org>:
> > 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.
>
> 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
> >>> brett@apache.org
> >>> http://brettporter.wordpress.com/
> >>> http://au.linkedin.com/in/brettporter
> >>> http://twitter.com/brettporter
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://brettporter.wordpress.com/
> > http://au.linkedin.com/in/brettporter
> > http://twitter.com/brettporter
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Stephen Connolly <st...@gmail.com>.
On 28 May 2012 08:11, Hervé BOUTEMY <he...@free.fr> wrote:
> We can implement @component based on field type *and name*:
>
> // defaults to ${project}
> @Component
> MavenProject myProject
>
> // but reactorProjects gives ${reactorProject}
> @Component
> MavenProject reactorProjects
Should be an array or list ^^^ is ending with a "s"
>
>
> And the list of magical field type+name can grow as much as we find use cases.
>
> But is this a good idea? Isn't it too magical?
>
> Regards,
>
> Hervé
>
> Le dimanche 27 mai 2012 22:21:46 Hervé BOUTEMY a écrit :
>> Le samedi 26 mai 2012 22:06:47 Brett Porter a écrit :
>> > // inject stuff for Maven - session covers all but should also support
>> >
>> > the same for project, localRepository, reactorProjects, // mojoExecution,
>> > executedProject, plugin, settings
>> >
>> > @Inject
>> > private MavenSession session;
>>
>> I just implemented project, mojo, plugin, session and settings: see
>> MPLUGIN-204 [1]
>> I didn't implement localRepository, reactorProjects, executedProject: we
>> can't differentiate executedProject from project based on its simple class
>> name, and I hesitated for localRepository and reactorprojects: is the type
>> sufficient?
>>
>> Adding new magical Maven objects just requires adding config in PluginUtils.
>>
>> Regards,
>>
>> Hervé
>>
>> [1] http://jira.codehaus.org/browse/MPLUGIN-204
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
We can implement @component based on field type *and name*:
// defaults to ${project}
@Component
MavenProject myProject
// but reactorProjects gives ${reactorProject}
@Component
MavenProject reactorProjects
And the list of magical field type+name can grow as much as we find use cases.
But is this a good idea? Isn't it too magical?
Regards,
Hervé
Le dimanche 27 mai 2012 22:21:46 Hervé BOUTEMY a écrit :
> Le samedi 26 mai 2012 22:06:47 Brett Porter a écrit :
> > // inject stuff for Maven - session covers all but should also support
> >
> > the same for project, localRepository, reactorProjects, // mojoExecution,
> > executedProject, plugin, settings
> >
> > @Inject
> > private MavenSession session;
>
> I just implemented project, mojo, plugin, session and settings: see
> MPLUGIN-204 [1]
> I didn't implement localRepository, reactorProjects, executedProject: we
> can't differentiate executedProject from project based on its simple class
> name, and I hesitated for localRepository and reactorprojects: is the type
> sufficient?
>
> Adding new magical Maven objects just requires adding config in PluginUtils.
>
> Regards,
>
> Hervé
>
> [1] http://jira.codehaus.org/browse/MPLUGIN-204
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 26 mai 2012 22:06:47 Brett Porter a écrit :
> // inject stuff for Maven - session covers all but should also support
> the same for project, localRepository, reactorProjects, // mojoExecution,
> executedProject, plugin, settings
> @Inject
> private MavenSession session;
I just implemented project, mojo, plugin, session and settings: see
MPLUGIN-204 [1]
I didn't implement localRepository, reactorProjects, executedProject: we can't
differentiate executedProject from project based on its simple class name, and
I hesitated for localRepository and reactorprojects: is the type sufficient?
Adding new magical Maven objects just requires adding config in PluginUtils.
Regards,
Hervé
[1] http://jira.codehaus.org/browse/MPLUGIN-204
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
from what I see, this consists in:
- renaming @Component to @Role
- detect @Inject instead of @Component in descriptor extractor
- hardcode special Maven objects to "magically" generate ${project} expression
and other Maven objects that can be recognized by their sole type
for Lists and Maps, I don't know if the component injection code in core can
do the expected work, I need to investigate into DefaultMavenPluginManager.
Notice that readonly has to remain for exceptional cases where @Parameter
isn't intended for user configuration
All this should be doable and not so hard to implement.
The only drawback I see is that the new annotations would be more different
from javadoc tags, then need more work for plugin developers to learn.
IMHO, given that annotations will get compiled, we should provide @Component,
but deprecate with instructions to use @Inject: this will give users an easier
transition than direct @Component replacement/removal.
Regards,
Hervé
Le samedi 26 mai 2012 22:06:47 Brett Porter a écrit :
> On 25/05/2012, at 5:23 PM, Brett Porter wrote:
> >> But anything more specific that these needs extension: we're in that case
> >>
> >> Please have a look at [2], with proposed Improvements and comment
> >
> > Agree - but I'd still like to avoid typing both in the 90% of cases where
> > the plugin tools can figure it out for you.
> >
> > I'll see if I can put together an example that covers all the different
> > types...
> What if @Parameter were left as is (@Inject would be optional there), but we
> used the following for the different types of @Component injections:
>
> ===
>
> // inject stuff for Maven - session covers all but should also support
> the same for project, localRepository, reactorProjects, // mojoExecution,
> executedProject, plugin, settings
> @Inject
> private MavenSession session;
>
> // standard injection used for most components
> @Inject
> private IComponent component;
>
> // injection where we need a specific implementation (role-hint)
> @Inject
> @Named("another")
> private IMultiComponent anotherComponent;
>
> // Lookup a Map by its generic type (fine for plugin.xml, might be
> erasure problem at runtime) @Inject
> private Map<String, IMultiComponent> componentsMap;
>
> // Lookup a List by its generic type
> @Inject
> private List<IMultiComponent> componentsList;
>
> // Lookup an array by its type
> @Inject
> private IMultiComponent[] componentsArray;
>
> /// EXCEPTIONAL CASES
>
> // Specify the role, since it is less specific than the concrete class
> we need it to be // NOTE: As you can't have two qualifiers, we move the
> hint back into here for this case // The other alternative is just have
> @Role(clazz) and not make it a @Qualifier, then the hint is always @Named.
> // That may impact how useful it would be at runtime though
> @Inject
> @Role(role = IMultiComponent.class, hint = "another")
> private AnotherComponentImpl specificComponent;
>
> // Lookup a Map by its role
> @Inject
> @Role(role = IMultiComponent.class)
> private Map<String, AbstractMultiComponent> componentsMapByRole;
>
> // Lookup a List by its role
> @Inject
> @Role(role = IMultiComponent.class)
> private List<AbstractMultiComponent> componentsListByRole;
>
> // Lookup an array by its role
> @Inject
> @Role(role = IMultiComponent.class)
> private AbstractMultiComponent[] componentsArrayByRole;
>
> ===
>
> This is for Role:
>
> ====
>
> @Retention(RUNTIME)
> @Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD})
> @Qualifier
> public @interface Role {
> Class<?> role();
>
> String hint() default "default";
> }
>
> ====
>
> WDYT?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Brett Porter <br...@apache.org>.
On 25/05/2012, at 5:23 PM, Brett Porter wrote:
>> But anything more specific that these needs extension: we're in that case
>>
>> Please have a look at [2], with proposed Improvements and comment
>
> Agree - but I'd still like to avoid typing both in the 90% of cases where the plugin tools can figure it out for you.
>
> I'll see if I can put together an example that covers all the different types...
What if @Parameter were left as is (@Inject would be optional there), but we used the following for the different types of @Component injections:
===
// inject stuff for Maven - session covers all but should also support the same for project, localRepository, reactorProjects,
// mojoExecution, executedProject, plugin, settings
@Inject
private MavenSession session;
// standard injection used for most components
@Inject
private IComponent component;
// injection where we need a specific implementation (role-hint)
@Inject
@Named("another")
private IMultiComponent anotherComponent;
// Lookup a Map by its generic type (fine for plugin.xml, might be erasure problem at runtime)
@Inject
private Map<String, IMultiComponent> componentsMap;
// Lookup a List by its generic type
@Inject
private List<IMultiComponent> componentsList;
// Lookup an array by its type
@Inject
private IMultiComponent[] componentsArray;
/// EXCEPTIONAL CASES
// Specify the role, since it is less specific than the concrete class we need it to be
// NOTE: As you can't have two qualifiers, we move the hint back into here for this case
// The other alternative is just have @Role(clazz) and not make it a @Qualifier, then the hint is always @Named.
// That may impact how useful it would be at runtime though
@Inject
@Role(role = IMultiComponent.class, hint = "another")
private AnotherComponentImpl specificComponent;
// Lookup a Map by its role
@Inject
@Role(role = IMultiComponent.class)
private Map<String, AbstractMultiComponent> componentsMapByRole;
// Lookup a List by its role
@Inject
@Role(role = IMultiComponent.class)
private List<AbstractMultiComponent> componentsListByRole;
// Lookup an array by its role
@Inject
@Role(role = IMultiComponent.class)
private AbstractMultiComponent[] componentsArrayByRole;
===
This is for Role:
====
@Retention(RUNTIME)
@Target({ElementType.FIELD, ElementType.TYPE, ElementType.METHOD})
@Qualifier
public @interface Role {
Class<?> role();
String hint() default "default";
}
====
WDYT?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Brett Porter <br...@apache.org>.
On 24/05/2012, at 3:05 PM, Hervé BOUTEMY wrote:
> Hi Barrie,
>
> I was ignorant too and found reading javadoc for javax.inject fast and very
> useful [1]
> In summary, standard contains:
> - 3 concepts: @Inject, @Qualifier and @Scope
> - 2 basic use case: @Named as classical Qualifier and @Singleton as classical
> Scope
> I still didn't investigate Provider<T>
Provider just allows you to specify something that will get you a T, rather than injecting a T. It's the sort of thing that will apply to the Map/List types.
>
> But anything more specific that these needs extension: we're in that case
>
> Please have a look at [2], with proposed Improvements and comment
Agree - but I'd still like to avoid typing both in the 90% of cases where the plugin tools can figure it out for you.
I'll see if I can put together an example that covers all the different types...
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
Hi Barrie,
I was ignorant too and found reading javadoc for javax.inject fast and very
useful [1]
In summary, standard contains:
- 3 concepts: @Inject, @Qualifier and @Scope
- 2 basic use case: @Named as classical Qualifier and @Singleton as classical
Scope
I still didn't investigate Provider<T>
But anything more specific that these needs extension: we're in that case
Please have a look at [2], with proposed Improvements and comment
Regards,
Hervé
[1] http://atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-
summary.html
[2]
https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins
Le mercredi 23 mai 2012 08:16:26 Barrie Treloar a écrit :
> On Wed, May 23, 2012 at 7:00 AM, Olivier Lamy <ol...@apache.org> wrote:
> [del]
>
> >>> 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.
>
> Please excuse my extreme ignorance of annotation injection :)
>
> But would have thought there was something that helped with this
> problem already available.
>
> My quick googling looks like @Qualifier types of @Named might be what is
> needed. Can someone with a clue confirm this?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, May 23, 2012 at 7:00 AM, Olivier Lamy <ol...@apache.org> wrote:
[del]
>>> 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.
Please excuse my extreme ignorance of annotation injection :)
But would have thought there was something that helped with this
problem already available.
My quick googling looks like @Qualifier types of @Named might be what is needed.
Can someone with a clue confirm this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
2012/5/22 Olivier Lamy <ol...@apache.org>:
> 2012/5/22 Brett Porter <br...@apache.org>:
>>
>> 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.
>
> 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
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>> http://au.linkedin.com/in/brettporter
>>>> http://twitter.com/brettporter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
2012/5/22 Brett Porter <br...@apache.org>:
>
> 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.
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
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> http://au.linkedin.com/in/brettporter
>>> http://twitter.com/brettporter
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
Op Tue, 22 May 2012 20:32:46 +0200 schreef Brett Porter <br...@apache.org>:
>
> 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.
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
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> http://au.linkedin.com/in/brettporter
>>> http://twitter.com/brettporter
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Brett Porter <br...@apache.org>.
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
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
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)
> - 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 ?
> - 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
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by 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
- 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 )
- 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? :)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
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
@Parameter( defaultValue = "${project}", readonly = true ) is ok for me
creating a new annotation just to avoid readonly doesn't deserve it IMHO
Regards,
Hervé
Le lundi 21 mai 2012 14:49:44 Brett Porter a écrit :
> On 21/05/2012, at 8:48 AM, Barrie Treloar wrote:
> > On Sun, May 20, 2012 at 8:12 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> >> bingo: you got it!
> >> ok, now I understand, you're right, I was focused at my property vs
> >> expression task and forgot the most normal way of configuring plugins...
> >>
> >> I'll revert and improve the docs
> >
> > I've been lurking on this discussion, so I'm not sure my ideas are
> > fully baked...
> >
> > Before you revert, isn't Robert's example behaving like @Inject?
> > i.e. you would not use @Parameter any more on these objects.
>
> Right, that was a point I was trying to make in an earlier post, but I
> confused it by my last sentence. @parameter default-value="${project}"
> sounds wrong because it implies you can actually configure a different
> project.
>
> I think we want to:
> - create a new annotation/attribute to obtain the maven-internal bits; and
> if that has happened then... - move @required to be an attribute of
> @parameter, as it makes no sense for the other annotations - drop
> @readonly, as it's redundant on every type of annotation
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Brett Porter <br...@apache.org>.
On 21/05/2012, at 8:48 AM, Barrie Treloar wrote:
> On Sun, May 20, 2012 at 8:12 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>> bingo: you got it!
>> ok, now I understand, you're right, I was focused at my property vs expression
>> task and forgot the most normal way of configuring plugins...
>>
>> I'll revert and improve the docs
>
> I've been lurking on this discussion, so I'm not sure my ideas are
> fully baked...
>
> Before you revert, isn't Robert's example behaving like @Inject?
> i.e. you would not use @Parameter any more on these objects.
Right, that was a point I was trying to make in an earlier post, but I confused it by my last sentence. @parameter default-value="${project}" sounds wrong because it implies you can actually configure a different project.
I think we want to:
- create a new annotation/attribute to obtain the maven-internal bits; and if that has happened then...
- move @required to be an attribute of @parameter, as it makes no sense for the other annotations
- drop @readonly, as it's redundant on every type of annotation
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Barrie Treloar <ba...@gmail.com>.
On Sun, May 20, 2012 at 8:12 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> bingo: you got it!
> ok, now I understand, you're right, I was focused at my property vs expression
> task and forgot the most normal way of configuring plugins...
>
> I'll revert and improve the docs
I've been lurking on this discussion, so I'm not sure my ideas are
fully baked...
Before you revert, isn't Robert's example behaving like @Inject?
i.e. you would not use @Parameter any more on these objects.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
bingo: you got it!
ok, now I understand, you're right, I was focused at my property vs expression
task and forgot the most normal way of configuring plugins...
I'll revert and improve the docs
thank you!
Hervé
Le dimanche 20 mai 2012 12:04:31 Robert Scholte a écrit :
> Consider
>
> @Parameter default-value="${project}"
> private MavenProject mavenProject
>
> This would suggest, that you use it inside the configuration of the plugin
>
> <configuration>
> <mavenProject>???</mavenProject>
> </configuration>
>
> Also, it will appear in the goal-reports. If I'm correct readonly is used
> as a marker to ignore this parameter in the report.
>
> -Robert
>
> Op Sun, 20 May 2012 11:31:23 +0200 schreef Hervé BOUTEMY
>
> <he...@free.fr>:
> > @Parameter default-value="${project}"
> >
> > or with javadoc tags
> >
> > /**
> >
> > * @parameter default-value="${project}"
> > */
> >
> > no?
> >
> > IIUC, the old habbit to use expression because the attribute name let
> > think
> > it
> > can do more than default-value is the culprit: that's why renaming
> > expression
> > is really important IMHO
> >
> > or I'm missing something
> >
> > thanks for your comments, don'thesitate to continue and try to break the
> > reasoning, because it seems nobody is completely sure
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 20 mai 2012 10:50:26 vous avez écrit :
> >> Hmm, maybe I was a bit too fast.
> >>
> >> How about those standard expressions like ${project}, ${settings},
> >> ${localRepository}, etc.
> >> These should stay readonly and AFAIK the @parameter is the only way to
> >> set
> >> these fields.
> >>
> >> -Robert
> >>
> >> Op Sun, 20 May 2012 00:10:22 +0200 schreef Hervé BOUTEMY
> >>
> >> <he...@free.fr>:
> >> > ok, I see
> >> > IIUC, it is an old feature we can let in javadoc tags for
> >>
> >> compatibility
> >>
> >> > (even
> >> > if there were warnings for a long time about this old way of
> >>
> >> configuring
> >>
> >> > components) but at least remove from java 5 annotations, no?
> >> >
> >> > Le dimanche 20 mai 2012 00:05:13 Robert Scholte a écrit :
> >> >> In the early days before @component was used, you had to use
> >>
> >> expression.
> >>
> >> >> See
> >>
> >> http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-
> >>
> >> >> moj o-params.html for example
> >> >>
> >> >> In that case it is very useful to have readonly.
> >> >>
> >> >> -Robert
> >> >>
> >> >>
> >> >> Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
> >> >>
> >> >> <he...@free.fr>:
> >> >> > the more I look at readonly, the mess I understand what it is
> >>
> >> intended
> >>
> >> >> > to do.
> >> >> >
> >> >> > If default-value is properly used, i don't see why we would mark a
> >> >> > parameter
> >> >> > as readonly: simply leave it without property (or expression)
> >> >> >
> >> >> > What am I missing?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >> >> >
> >> >> > Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
> >> >> >> I think these are both good ideas.
> >> >> >>
> >> >> >> There's a couple of things expression currently supports that
> >> >>
> >> >> probably
> >> >>
> >> >> >> shouldn't be supported under "property" to avoid confusion: -
> >> >> >> ${project.*}
> >> >> >> as these should be specified under a default-value (they can't be
> >> >> >> overridden by -Dproject.XXX, etc.). - ${settings}, ${session},
> >>
> >> etc. -
> >>
> >> >> >> Maven
> >> >> >> internal variables. It would be good to have some other way to
> >> >>
> >> >> describe
> >> >>
> >> >> >> them that is not @parameter, and can avoid the need for the
> >>
> >> redundant
> >>
> >> >> >> @readonly and @required they usually come with
> >> >> >>
> >> >> >> Looking at that, it actually seems like readonly and required
> >>
> >> belong
> >>
> >> >> as
> >> >>
> >> >> >> attributes of @parameter now too.
> >> >> >>
> >> >> >> - Brett
> >> >> >>
> >> >> >> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> >> >> >> > As discussed previously, there was some interest in changing
> >> >>
> >> >> supported
> >> >>
> >> >> >> > tags.
> >> >> >> >
> >> >> >> > Now that Java 5 annotations support is ok, I already added some
> >> >> >>
> >> >> >> change in
> >> >> >>
> >> >> >> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
> >> >> >>
> >> >> >> expression
> >> >> >>
> >> >> >> > I just created MPLUGIN-196 issue [2] to rename "expression" to
> >> >> >>
> >> >> >> "property",
> >> >> >>
> >> >> >> > where ${ } would even not be supported
> >> >> >> >
> >> >> >> > Please comment: any objection? any better idea?
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> >
> >> >> >> > Hervé
> >> >> >> >
> >> >> >> >
> >> >> >> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
> >> >> >> >
> >> >> >> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >> --
> >> >> >> Brett Porter
> >> >> >> brett@apache.org
> >> >> >> http://brettporter.wordpress.com/
> >> >> >> http://au.linkedin.com/in/brettporter
> >> >> >> http://twitter.com/brettporter
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
Consider
@Parameter default-value="${project}"
private MavenProject mavenProject
This would suggest, that you use it inside the configuration of the plugin
<configuration>
<mavenProject>???</mavenProject>
</configuration>
Also, it will appear in the goal-reports. If I'm correct readonly is used
as a marker to ignore this parameter in the report.
-Robert
Op Sun, 20 May 2012 11:31:23 +0200 schreef Hervé BOUTEMY
<he...@free.fr>:
> @Parameter default-value="${project}"
>
> or with javadoc tags
>
> /**
> * @parameter default-value="${project}"
> */
>
> no?
>
> IIUC, the old habbit to use expression because the attribute name let
> think
> it
> can do more than default-value is the culprit: that's why renaming
> expression
> is really important IMHO
>
> or I'm missing something
>
> thanks for your comments, don'thesitate to continue and try to break the
> reasoning, because it seems nobody is completely sure
>
> Regards,
>
> Hervé
>
> Le dimanche 20 mai 2012 10:50:26 vous avez écrit :
>> Hmm, maybe I was a bit too fast.
>>
>> How about those standard expressions like ${project}, ${settings},
>> ${localRepository}, etc.
>> These should stay readonly and AFAIK the @parameter is the only way to
>> set
>> these fields.
>>
>> -Robert
>>
>> Op Sun, 20 May 2012 00:10:22 +0200 schreef Hervé BOUTEMY
>>
>> <he...@free.fr>:
>> > ok, I see
>> > IIUC, it is an old feature we can let in javadoc tags for
>> compatibility
>> > (even
>> > if there were warnings for a long time about this old way of
>> configuring
>> > components) but at least remove from java 5 annotations, no?
>> >
>> > Le dimanche 20 mai 2012 00:05:13 Robert Scholte a écrit :
>> >> In the early days before @component was used, you had to use
>> expression.
>> >>
>> >> See
>> >>
>> http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-
>> >> moj o-params.html for example
>> >>
>> >> In that case it is very useful to have readonly.
>> >>
>> >> -Robert
>> >>
>> >>
>> >> Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
>> >>
>> >> <he...@free.fr>:
>> >> > the more I look at readonly, the mess I understand what it is
>> intended
>> >> > to do.
>> >> >
>> >> > If default-value is properly used, i don't see why we would mark a
>> >> > parameter
>> >> > as readonly: simply leave it without property (or expression)
>> >> >
>> >> > What am I missing?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
>> >> >> I think these are both good ideas.
>> >> >>
>> >> >> There's a couple of things expression currently supports that
>> >>
>> >> probably
>> >>
>> >> >> shouldn't be supported under "property" to avoid confusion: -
>> >> >> ${project.*}
>> >> >> as these should be specified under a default-value (they can't be
>> >> >> overridden by -Dproject.XXX, etc.). - ${settings}, ${session},
>> etc. -
>> >> >> Maven
>> >> >> internal variables. It would be good to have some other way to
>> >>
>> >> describe
>> >>
>> >> >> them that is not @parameter, and can avoid the need for the
>> redundant
>> >> >> @readonly and @required they usually come with
>> >> >>
>> >> >> Looking at that, it actually seems like readonly and required
>> belong
>> >>
>> >> as
>> >>
>> >> >> attributes of @parameter now too.
>> >> >>
>> >> >> - Brett
>> >> >>
>> >> >> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
>> >> >> > As discussed previously, there was some interest in changing
>> >>
>> >> supported
>> >>
>> >> >> > tags.
>> >> >> >
>> >> >> > Now that Java 5 annotations support is ok, I already added some
>> >> >>
>> >> >> change in
>> >> >>
>> >> >> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
>> >> >>
>> >> >> expression
>> >> >>
>> >> >> > I just created MPLUGIN-196 issue [2] to rename "expression" to
>> >> >>
>> >> >> "property",
>> >> >>
>> >> >> > where ${ } would even not be supported
>> >> >> >
>> >> >> > Please comment: any objection? any better idea?
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > Hervé
>> >> >> >
>> >> >> >
>> >> >> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
>> >> >> >
>> >> >> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> --
>> >> >> Brett Porter
>> >> >> brett@apache.org
>> >> >> http://brettporter.wordpress.com/
>> >> >> http://au.linkedin.com/in/brettporter
>> >> >> http://twitter.com/brettporter
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
@Parameter default-value="${project}"
or with javadoc tags
/**
* @parameter default-value="${project}"
*/
no?
IIUC, the old habbit to use expression because the attribute name let think
it
can do more than default-value is the culprit: that's why renaming expression
is really important IMHO
or I'm missing something
thanks for your comments, don'thesitate to continue and try to break the
reasoning, because it seems nobody is completely sure
Regards,
Hervé
Le dimanche 20 mai 2012 10:50:26 vous avez écrit :
> Hmm, maybe I was a bit too fast.
>
> How about those standard expressions like ${project}, ${settings},
> ${localRepository}, etc.
> These should stay readonly and AFAIK the @parameter is the only way to set
> these fields.
>
> -Robert
>
> Op Sun, 20 May 2012 00:10:22 +0200 schreef Hervé BOUTEMY
>
> <he...@free.fr>:
> > ok, I see
> > IIUC, it is an old feature we can let in javadoc tags for compatibility
> > (even
> > if there were warnings for a long time about this old way of configuring
> > components) but at least remove from java 5 annotations, no?
> >
> > Le dimanche 20 mai 2012 00:05:13 Robert Scholte a écrit :
> >> In the early days before @component was used, you had to use expression.
> >>
> >> See
> >> http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-
> >> moj o-params.html for example
> >>
> >> In that case it is very useful to have readonly.
> >>
> >> -Robert
> >>
> >>
> >> Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
> >>
> >> <he...@free.fr>:
> >> > the more I look at readonly, the mess I understand what it is intended
> >> > to do.
> >> >
> >> > If default-value is properly used, i don't see why we would mark a
> >> > parameter
> >> > as readonly: simply leave it without property (or expression)
> >> >
> >> > What am I missing?
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
> >> >> I think these are both good ideas.
> >> >>
> >> >> There's a couple of things expression currently supports that
> >>
> >> probably
> >>
> >> >> shouldn't be supported under "property" to avoid confusion: -
> >> >> ${project.*}
> >> >> as these should be specified under a default-value (they can't be
> >> >> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. -
> >> >> Maven
> >> >> internal variables. It would be good to have some other way to
> >>
> >> describe
> >>
> >> >> them that is not @parameter, and can avoid the need for the redundant
> >> >> @readonly and @required they usually come with
> >> >>
> >> >> Looking at that, it actually seems like readonly and required belong
> >>
> >> as
> >>
> >> >> attributes of @parameter now too.
> >> >>
> >> >> - Brett
> >> >>
> >> >> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> >> >> > As discussed previously, there was some interest in changing
> >>
> >> supported
> >>
> >> >> > tags.
> >> >> >
> >> >> > Now that Java 5 annotations support is ok, I already added some
> >> >>
> >> >> change in
> >> >>
> >> >> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
> >> >>
> >> >> expression
> >> >>
> >> >> > I just created MPLUGIN-196 issue [2] to rename "expression" to
> >> >>
> >> >> "property",
> >> >>
> >> >> > where ${ } would even not be supported
> >> >> >
> >> >> > Please comment: any objection? any better idea?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >> >> >
> >> >> >
> >> >> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
> >> >> >
> >> >> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> --
> >> >> Brett Porter
> >> >> brett@apache.org
> >> >> http://brettporter.wordpress.com/
> >> >> http://au.linkedin.com/in/brettporter
> >> >> http://twitter.com/brettporter
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
Hmm, maybe I was a bit too fast.
How about those standard expressions like ${project}, ${settings},
${localRepository}, etc.
These should stay readonly and AFAIK the @parameter is the only way to set
these fields.
-Robert
Op Sun, 20 May 2012 00:10:22 +0200 schreef Hervé BOUTEMY
<he...@free.fr>:
> ok, I see
> IIUC, it is an old feature we can let in javadoc tags for compatibility
> (even
> if there were warnings for a long time about this old way of configuring
> components) but at least remove from java 5 annotations, no?
>
> Le dimanche 20 mai 2012 00:05:13 Robert Scholte a écrit :
>> In the early days before @component was used, you had to use expression.
>>
>> See
>> http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-moj
>> o-params.html for example
>>
>> In that case it is very useful to have readonly.
>>
>> -Robert
>>
>>
>> Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
>>
>> <he...@free.fr>:
>> > the more I look at readonly, the mess I understand what it is intended
>> > to do.
>> >
>> > If default-value is properly used, i don't see why we would mark a
>> > parameter
>> > as readonly: simply leave it without property (or expression)
>> >
>> > What am I missing?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
>> >> I think these are both good ideas.
>> >>
>> >> There's a couple of things expression currently supports that
>> probably
>> >> shouldn't be supported under "property" to avoid confusion: -
>> >> ${project.*}
>> >> as these should be specified under a default-value (they can't be
>> >> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. -
>> >> Maven
>> >> internal variables. It would be good to have some other way to
>> describe
>> >> them that is not @parameter, and can avoid the need for the redundant
>> >> @readonly and @required they usually come with
>> >>
>> >> Looking at that, it actually seems like readonly and required belong
>> as
>> >> attributes of @parameter now too.
>> >>
>> >> - Brett
>> >>
>> >> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
>> >> > As discussed previously, there was some interest in changing
>> supported
>> >> > tags.
>> >> >
>> >> > Now that Java 5 annotations support is ok, I already added some
>> >>
>> >> change in
>> >>
>> >> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
>> >>
>> >> expression
>> >>
>> >> > I just created MPLUGIN-196 issue [2] to rename "expression" to
>> >>
>> >> "property",
>> >>
>> >> > where ${ } would even not be supported
>> >> >
>> >> > Please comment: any objection? any better idea?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> >
>> >> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
>> >> >
>> >> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
>> >> >
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> --
>> >> Brett Porter
>> >> brett@apache.org
>> >> http://brettporter.wordpress.com/
>> >> http://au.linkedin.com/in/brettporter
>> >> http://twitter.com/brettporter
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, I see
IIUC, it is an old feature we can let in javadoc tags for compatibility (even
if there were warnings for a long time about this old way of configuring
components) but at least remove from java 5 annotations, no?
Le dimanche 20 mai 2012 00:05:13 Robert Scholte a écrit :
> In the early days before @component was used, you had to use expression.
>
> See
> http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-moj
> o-params.html for example
>
> In that case it is very useful to have readonly.
>
> -Robert
>
>
> Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
>
> <he...@free.fr>:
> > the more I look at readonly, the mess I understand what it is intended
> > to do.
> >
> > If default-value is properly used, i don't see why we would mark a
> > parameter
> > as readonly: simply leave it without property (or expression)
> >
> > What am I missing?
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
> >> I think these are both good ideas.
> >>
> >> There's a couple of things expression currently supports that probably
> >> shouldn't be supported under "property" to avoid confusion: -
> >> ${project.*}
> >> as these should be specified under a default-value (they can't be
> >> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. -
> >> Maven
> >> internal variables. It would be good to have some other way to describe
> >> them that is not @parameter, and can avoid the need for the redundant
> >> @readonly and @required they usually come with
> >>
> >> Looking at that, it actually seems like readonly and required belong as
> >> attributes of @parameter now too.
> >>
> >> - Brett
> >>
> >> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> >> > As discussed previously, there was some interest in changing supported
> >> > tags.
> >> >
> >> > Now that Java 5 annotations support is ok, I already added some
> >>
> >> change in
> >>
> >> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
> >>
> >> expression
> >>
> >> > I just created MPLUGIN-196 issue [2] to rename "expression" to
> >>
> >> "property",
> >>
> >> > where ${ } would even not be supported
> >> >
> >> > Please comment: any objection? any better idea?
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> >
> >> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
> >> >
> >> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >> http://au.linkedin.com/in/brettporter
> >> http://twitter.com/brettporter
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Robert Scholte <ap...@sourcegrounds.com>.
In the early days before @component was used, you had to use expression.
See
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-mojo-params.html
for example
In that case it is very useful to have readonly.
-Robert
Op Sat, 19 May 2012 22:44:13 +0200 schreef Hervé BOUTEMY
<he...@free.fr>:
> the more I look at readonly, the mess I understand what it is intended
> to do.
>
> If default-value is properly used, i don't see why we would mark a
> parameter
> as readonly: simply leave it without property (or expression)
>
> What am I missing?
>
> Regards,
>
> Hervé
>
> Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
>> I think these are both good ideas.
>>
>> There's a couple of things expression currently supports that probably
>> shouldn't be supported under "property" to avoid confusion: -
>> ${project.*}
>> as these should be specified under a default-value (they can't be
>> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. -
>> Maven
>> internal variables. It would be good to have some other way to describe
>> them that is not @parameter, and can avoid the need for the redundant
>> @readonly and @required they usually come with
>>
>> Looking at that, it actually seems like readonly and required belong as
>> attributes of @parameter now too.
>>
>> - Brett
>>
>> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
>> > As discussed previously, there was some interest in changing supported
>> > tags.
>> >
>> > Now that Java 5 annotations support is ok, I already added some
>> change in
>> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter
>> expression
>> >
>> > I just created MPLUGIN-196 issue [2] to rename "expression" to
>> "property",
>> > where ${ } would even not be supported
>> >
>> > Please comment: any objection? any better idea?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >
>> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
>> >
>> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
the more I look at readonly, the mess I understand what it is intended to do.
If default-value is properly used, i don't see why we would mark a parameter
as readonly: simply leave it without property (or expression)
What am I missing?
Regards,
Hervé
Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
> I think these are both good ideas.
>
> There's a couple of things expression currently supports that probably
> shouldn't be supported under "property" to avoid confusion: - ${project.*}
> as these should be specified under a default-value (they can't be
> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. - Maven
> internal variables. It would be good to have some other way to describe
> them that is not @parameter, and can avoid the need for the redundant
> @readonly and @required they usually come with
>
> Looking at that, it actually seems like readonly and required belong as
> attributes of @parameter now too.
>
> - Brett
>
> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> > As discussed previously, there was some interest in changing supported
> > tags.
> >
> > Now that Java 5 annotations support is ok, I already added some change in
> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
> >
> > I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
> > where ${ } would even not be supported
> >
> > Please comment: any objection? any better idea?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
> >
> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Olivier Lamy <ol...@apache.org>.
Fun, I just discovered too this configuration mode for the plexus
configuration field name.
Frankly I'm not sure it's used neither really useful as introduced
difference between field name and configuration field to use in your
pom.
+1 to simply remove that (we have jumped to version 3.0-SNAPSHOT so
IMHO "yes we can" :-) ).
2012/5/18 Hervé BOUTEMY <he...@free.fr>:
> I removed readonly and required as attributes of @component (both in javadoc
> or java 5 annotation form), since they are ignored by the descriptor
> generation step (see r1339666)
>
> I renamed "expression" to "property" for Java 5 annotations in r1339888.
>
> Then I tried to add "property" support for javadoc tags, and found an un-
> documented feature: property already exists in JavaMojoDescriptorExtractor
>
> // ----------------------------------------------------------------------
> // We will look for a property name here first and use that if present
> // i.e:
> //
> // @parameter property="project"
> //
> // Which will become the name used for the configuration element which
> // will in turn will allow plexus to use the corresponding setter.
> // ----------------------------------------------------------------------
>
> String property = parameter.getNamedParameter(
> JavaMojoAnnotation.PARAMETER_PROPERTY );
>
> if ( !StringUtils.isEmpty( property ) )
> {
> pd.setName( property );
> }
> else
> {
> pd.setName( entry.getKey() );
> }
>
>
> anybody knows? uses?
> then property won't be a good choice to replace expression, we'll need a new
> idea...
> please comment
>
> Regards,
>
> Hervé
>
> Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
>> I think these are both good ideas.
>>
>> There's a couple of things expression currently supports that probably
>> shouldn't be supported under "property" to avoid confusion: - ${project.*}
>> as these should be specified under a default-value (they can't be
>> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. - Maven
>> internal variables. It would be good to have some other way to describe
>> them that is not @parameter, and can avoid the need for the redundant
>> @readonly and @required they usually come with
>>
>> Looking at that, it actually seems like readonly and required belong as
>> attributes of @parameter now too.
>>
>> - Brett
>>
>> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
>> > As discussed previously, there was some interest in changing supported
>> > tags.
>> >
>> > Now that Java 5 annotations support is ok, I already added some change in
>> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
>> >
>> > I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
>> > where ${ } would even not be supported
>> >
>> > Please comment: any objection? any better idea?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >
>> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
>> >
>> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Hervé BOUTEMY <he...@free.fr>.
I removed readonly and required as attributes of @component (both in javadoc
or java 5 annotation form), since they are ignored by the descriptor
generation step (see r1339666)
I renamed "expression" to "property" for Java 5 annotations in r1339888.
Then I tried to add "property" support for javadoc tags, and found an un-
documented feature: property already exists in JavaMojoDescriptorExtractor
// ----------------------------------------------------------------------
// We will look for a property name here first and use that if present
// i.e:
//
// @parameter property="project"
//
// Which will become the name used for the configuration element which
// will in turn will allow plexus to use the corresponding setter.
// ----------------------------------------------------------------------
String property = parameter.getNamedParameter(
JavaMojoAnnotation.PARAMETER_PROPERTY );
if ( !StringUtils.isEmpty( property ) )
{
pd.setName( property );
}
else
{
pd.setName( entry.getKey() );
}
anybody knows? uses?
then property won't be a good choice to replace expression, we'll need a new
idea...
please comment
Regards,
Hervé
Le mardi 15 mai 2012 10:20:00 Brett Porter a écrit :
> I think these are both good ideas.
>
> There's a couple of things expression currently supports that probably
> shouldn't be supported under "property" to avoid confusion: - ${project.*}
> as these should be specified under a default-value (they can't be
> overridden by -Dproject.XXX, etc.). - ${settings}, ${session}, etc. - Maven
> internal variables. It would be good to have some other way to describe
> them that is not @parameter, and can avoid the need for the redundant
> @readonly and @required they usually come with
>
> Looking at that, it actually seems like readonly and required belong as
> attributes of @parameter now too.
>
> - Brett
>
> On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> > As discussed previously, there was some interest in changing supported
> > tags.
> >
> > Now that Java 5 annotations support is ok, I already added some change in
> > MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
> >
> > I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
> > where ${ } would even not be supported
> >
> > Please comment: any objection? any better idea?
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://jira.codehaus.org/browse/MPLUGIN-194
> >
> > [2] https://jira.codehaus.org/browse/MPLUGIN-196
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Plugin Tools - renaming "expression"
Posted by Brett Porter <br...@apache.org>.
I think these are both good ideas.
There's a couple of things expression currently supports that probably shouldn't be supported under "property" to avoid confusion:
- ${project.*} as these should be specified under a default-value (they can't be overridden by -Dproject.XXX, etc.).
- ${settings}, ${session}, etc. - Maven internal variables. It would be good to have some other way to describe them that is not @parameter, and can avoid the need for the redundant @readonly and @required they usually come with
Looking at that, it actually seems like readonly and required belong as attributes of @parameter now too.
- Brett
On 14/05/2012, at 5:59 AM, Hervé BOUTEMY wrote:
> As discussed previously, there was some interest in changing supported tags.
>
> Now that Java 5 annotations support is ok, I already added some change in
> MPLUGIN-194 [1]: you can remove ${ } when defining parameter expression
>
> I just created MPLUGIN-196 issue [2] to rename "expression" to "property",
> where ${ } would even not be supported
>
> Please comment: any objection? any better idea?
>
> Regards,
>
> Hervé
>
>
> [1] https://jira.codehaus.org/browse/MPLUGIN-194
>
> [2] https://jira.codehaus.org/browse/MPLUGIN-196
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org