good idea: if we do deprecate plugin-tools' @component, no need to create new
annotations, but better reuse
thanks you for the idea
Hervé
Le samedi 8 février 2014 11:27:19 Igor Fedorenko a écrit :
> Why not use jsr330 or plexus annotations and just deprecate plugin-tools
> @Component annotation
Why not use jsr330 or plexus annotations and just deprecate plugin-tools
@Component annotation?
--
Regards,
Igor
On 2/8/2014, 11:24, Hervé BOUTEMY wrote:
ok, so the other confusing part in plugin-tools is to have a @Component
annotation equivalent to Plexus' @Requirement and not Plexus' @Compon
ok, so the other confusing part in plugin-tools is to have a @Component
annotation equivalent to Plexus' @Requirement and not Plexus' @Component
(which defines a component, not uses it)
so perhaps we should deprecate plugin-tools @component/@Component in favor of
a new @requirement/@Requirement
Got it. Yes, I agree plugin-tools @Component is confusing :-)
--
Regards,
Igor
On 2/8/2014, 11:08, Hervé BOUTEMY wrote:
ok, now I understand where we diverge
yes, "normal" plugin-tools @Component are translated into Plexus requirements
but actual plugin-tools @Component support for Maven obje
In 3.2 it is possible to use jsr330 @Inject and plexus @Requirement to
inject MavenSession, MavenProject and MojoExecution.
--
Regards,
Igor
On 2/8/2014, 11:10, Robert Scholte wrote:
If I'm correct, these are all the same:
CDI @Inject
Plexus' @Requirement
Plugin's @Component
However, th
If I'm correct, these are all the same:
CDI @Inject
Plexus' @Requirement
Plugin's @Component
However, the way MavenSession, MavenProject and MojoExecution are injected
isn't done by DI, but by the expression evaluator.
Robert
Op Sat, 08 Feb 2014 17:00:48 +0100 schreef Igor Fedorenko
ok, now I understand where we diverge
yes, "normal" plugin-tools @Component are translated into Plexus requirements
but actual plugin-tools @Component support for Maven objects is a hack that
translates into parameter, not into requirement [1]
so this hack is confusing
when this hack will be r
On 2/8/2014, 9:56, Hervé BOUTEMY wrote:
ok, here the confusion is that there are 2 @Component annotations:
org.apache.maven.plugins.annotations.Component = plugin-tools
and
org.codehaus.plexus.component.annotations.Component = Plexus on Guice
plugin-tools @Component annotation for objects inje
ok, here the confusion is that there are 2 @Component annotations:
org.apache.maven.plugins.annotations.Component = plugin-tools
and
org.codehaus.plexus.component.annotations.Component = Plexus on Guice
plugin-tools @Component annotation for objects injected by
PluginParameterExpressionEvaluator
I think "confusion" is rather subjective term. Personally, I find
@Parameter(defaultValue="${session}")
MavenSession session;
far more confusing than
@Component
MavenSession session;
This is particular true in 3.2.0, which allows injection of
MojoExecution, MavenSession and Ma
the confusion is that MojoExecution, MavenSession, MavenProject, and generally
everything injected by PluginParameterExpressionEvaluator [1] are not Plexus
components
Fields marked by @Component are not injected by
PluginParameterExpressionEvaluator, only fields marked by @Parameter are
injecte
Hervé,
Can you explain what confusion this causes?
--
Regards,
Igor
On 2/6/2014, 16:47, Hervé BOUTEMY wrote:
Hi,
You'd better not use the @Component annotation but @Parameter instead: this is
a feature that will be deprecated in future version:
http://jira.codehaus.org/browse/MPLUGIN-257
Re
Hi Hervé,
Hi,
You'd better not use the @Component annotation but @Parameter instead: this is
a feature that will be deprecated in future version:
http://jira.codehaus.org/browse/MPLUGIN-257
Thanks for the hint learnt already (via IRC) the right way via
@Parameter ...
But according to the
Hi,
You'd better not use the @Component annotation but @Parameter instead: this is
a feature that will be deprecated in future version:
http://jira.codehaus.org/browse/MPLUGIN-257
Regards,
Hervé
Le jeudi 6 février 2014 22:04:57 Karl Heinz Marbaise a écrit :
> Hi,
>
> in the meantime i found
Hi,
in the meantime i found a better way (thanks to Robert Scholte):
@Component
private MojoExecution mojoExecution;
mojoExecution.getExecutionId();
mojoExecution.getConfiguration();
Kind regards
Karl Heinz Marbaise
Hi Baptiste,
first thanks for the links and answers...
> Here's the thread:
http://maven.40175.n5.nabble.com/Maven2-Maven3-plugin-development-Ensuring-only-the-available-parameters-are-allowed-tp5780854p5780948.html
Maybe I'd try something along those lines:
Plugin plugin = lookupThePluginYo
Here's the thread:
http://maven.40175.n5.nabble.com/Maven2-Maven3-plugin-development-Ensuring-only-the-available-parameters-are-allowed-tp5780854p5780948.html
Maybe I'd try something along those lines:
Plugin plugin = lookupThePluginYouWant(project.getBuildPlugins());
Xpp3Dom config = (Xpp3Dom) p
Hi Baptiste,
> Hi,
I think I remember a recent answer from Stephen about plugin conf,
saying basically you'd just have to fall back to xpath project/build and
then see what's present.
First thanks for the hint...
Any knowledge where to search for ?
Or Stephen ? Do you have a hint ?
Does exi
>From what I can tell in my testing, the @Parameter attributes required=true
>and defaultValue="some value" are mutually exclusive (in terms of behavior).
>That is, if you combine defaultValue="..." and required=true, defaultValue
>always satisfies the required=true setting, making required=tr
Hi,
I think I remember a recent answer from Stephen about plugin conf, saying
basically you'd just have to fall back to xpath project/build and then see
what's present.
My 2 cents
2014-01-30 Karl Heinz Marbaise :
> Hi,
>
> just a question concerning the usage of default values in a mojo...
>
>
20 matches
Mail list logo
