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
On 28 May 2012 08:11, Hervé BOUTEMY herve.bout...@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
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
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
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
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
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 ProviderT
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
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
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
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
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
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
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
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(
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
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
@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
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
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
On Sun, May 20, 2012 at 8:12 PM, Hervé BOUTEMY herve.bout...@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
On 21/05/2012, at 8:48 AM, Barrie Treloar wrote:
On Sun, May 20, 2012 at 8:12 PM, Hervé BOUTEMY herve.bout...@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...
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
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
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
Perso, no special idea/comments on that.
The current expression looks fine and property too.
2012/5/13 Hervé BOUTEMY herve.bout...@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
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:
2012/5/14 Robert Scholte apa...@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
Op Mon, 14 May 2012 22:13:52 +0200 schreef Olivier Lamy ol...@apache.org:
2012/5/14 Robert Scholte apa...@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
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},
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,
31 matches
Mail list logo
