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
I have my fix for
MNG-5572 Warn for building plugins with extensions in a reactor
almost ready, I'd like to add it as well.
Robert
Op Fri, 07 Feb 2014 17:16:56 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
Cool!
On 7 February 2014 16:13, Jason van Zyl ja...@takari.io
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
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
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
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
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
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,
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
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
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'
Since the mailing list archive links on
http://plexus.codehaus.org/mail-lists.html are dead, I thought that
I'd probably reach relevant people here.
I'm using Sisu/Guice in a project, and I'm looking for a _lightweight_
way to add classpath isolation. OSGi goes not qualify. Does anyone
still care
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?
Sure, no problem. I'm still looking at later Sunday, early Monday.
On Feb 8, 2014, at 6:19 AM, Robert Scholte rfscho...@apache.org wrote:
I have my fix for
MNG-5572 Warn for building plugins with extensions in a reactor
almost ready, I'd like to add it as well.
Robert
Op Fri, 07 Feb
The original Plexus implementation is dead and has been for quite a while, even
for us. We don't actually use Plexus the container anymore. The extensions that
were written for Plexus that sit atop Sisu is the effective Plexus
implementation we are using today. What this is in practice, for us,
On Sat, Feb 8, 2014 at 12:22 PM, Jason van Zyl ja...@takari.io wrote:
The original Plexus implementation is dead and has been for quite a while,
even for us. We don't actually use Plexus the container anymore. The
extensions that were written for Plexus that sit atop Sisu is the effective
On Sat, Feb 8, 2014 at 12:32 PM, Benson Margulies bimargul...@gmail.com wrote:
On Sat, Feb 8, 2014 at 12:22 PM, Jason van Zyl ja...@takari.io wrote:
The original Plexus implementation is dead and has been for quite a while,
even for us. We don't actually use Plexus the container anymore. The
On Feb 8, 2014, at 12:42 PM, Benson Margulies bimargul...@gmail.com wrote:
On Sat, Feb 8, 2014 at 12:32 PM, Benson Margulies bimargul...@gmail.com
wrote:
On Sat, Feb 8, 2014 at 12:22 PM, Jason van Zyl ja...@takari.io wrote:
The original Plexus implementation is dead and has been for quite a
Done.
Robert
Op Sat, 08 Feb 2014 18:07:54 +0100 schreef Jason van Zyl ja...@takari.io:
Sure, no problem. I'm still looking at later Sunday, early Monday.
On Feb 8, 2014, at 6:19 AM, Robert Scholte rfscho...@apache.org wrote:
I have my fix for
MNG-5572 Warn for building plugins with
On 6 February 2014 22:01, Hervé BOUTEMY herve.bout...@free.fr wrote:
yes, the change was intentional, to fix
http://jira.codehaus.org/browse/MSCMPUB-10 you issued :)
Thanks for the info.
I'm surprised this required M3, because I have written an M2 plugin
which uses the user/password info. It
if you can provide a patch, or give a link, we can have a look and see if
there is a better way of doing the work, without requiring M3
notice that IMHO, we should think at EOL-ing M2, at least 2.0.x now and 2.2.x
not so far away [1]
Regards,
Hervé
[1]
21 matches
Mail list logo
