Re: Plugins with parameters and defaultValue
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 injected like this Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html Le jeudi 6 février 2014 20:32:47 Igor Fedorenko a écrit : 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 Regards, Hervé Le jeudi 6 février 2014 22:04:57 Karl Heinz Marbaise a écrit : 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.0 release
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 wrote: I'm going to work on the remaining issues on Saturday and get as far as I can, and start cutting the release on Sunday morning. Hopefully I will put 3.2.0 up for vote sometime Sunday. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 MavenProject via mojo execution Guice
scope I introduced in [1]
[1]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8700b058574ea79544603ee4eacd6171ef03aa46
--
Regards,
Igor
On 2/8/2014, 5:15, Hervé BOUTEMY wrote:
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
injected like this
Regards,
Hervé
[1]
http://maven.apache.org/ref/3-LATEST/maven-core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html
Le jeudi 6 février 2014 20:32:47 Igor Fedorenko a écrit :
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
Regards,
Hervé
Le jeudi 6 février 2014 22:04:57 Karl Heinz Marbaise a écrit :
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 causes confusion at plugin-tools level
Regards,
Hervé
Le samedi 8 février 2014 09:06:40 Igor Fedorenko a écrit :
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 MavenProject via mojo execution Guice
scope I introduced in [1]
[1]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8700b058574ea
79544603ee4eacd6171ef03aa46
--
Regards,
Igor
On 2/8/2014, 5:15, Hervé BOUTEMY wrote:
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
injected like this
Regards,
Hervé
[1]
http://maven.apache.org/ref/3-LATEST/maven-core/apidocs/org/apache/maven/
plugin/PluginParameterExpressionEvaluator.html
Le jeudi 6 février 2014 20:32:47 Igor Fedorenko a écrit :
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
Regards,
Hervé
Le jeudi 6 février 2014 22:04:57 Karl Heinz Marbaise a écrit :
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 removed, real @Component translated to Plexus requirements will be possible: for the moment, the hack makes such thing impossible Regards, Hervé [1] http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/annotations/JavaAnnotationsMojoDescriptorExtractor.java?r1=1341650r2=1343086pathrev=1343086diff_format=h Le samedi 8 février 2014 11:00:48 Igor Fedorenko a écrit : 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 i...@ifedorenko.com: 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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, 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 i...@ifedorenko.com: 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 objects is a hack that translates into parameter, not into requirement [1] so this hack is confusing when this hack will be removed, real @Component translated to Plexus requirements will be possible: for the moment, the hack makes such thing impossible Regards, Hervé [1] http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/annotations/JavaAnnotationsMojoDescriptorExtractor.java?r1=1341650r2=1343086pathrev=1343086diff_format=h Le samedi 8 février 2014 11:00:48 Igor Fedorenko a écrit : 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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 (notice this part doesn't have anything to do with the hack for pseudo component) WDYT? Hervé Le samedi 8 février 2014 17:10:55 Robert Scholte a écrit : 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 i...@ifedorenko.com: 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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' @Component (which defines a component, not uses it) so perhaps we should deprecate plugin-tools @component/@Component in favor of a new @requirement/@Requirement (notice this part doesn't have anything to do with the hack for pseudo component) WDYT? Hervé Le samedi 8 février 2014 17:10:55 Robert Scholte a écrit : 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 i...@ifedorenko.com: 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
How alive is 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 for plexus? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plugins with parameters and defaultValue
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? -- 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' @Component (which defines a component, not uses it) so perhaps we should deprecate plugin-tools @component/@Component in favor of a new @requirement/@Requirement (notice this part doesn't have anything to do with the hack for pseudo component) WDYT? Hervé Le samedi 8 février 2014 17:10:55 Robert Scholte a écrit : 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 i...@ifedorenko.com: 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 injected by PluginParameterExpressionEvaluator causes confusion at plugin-tools level Can you point me at the code that implements this? I was under impression that plugin-tools @Component was translated to plexus/guice requirement at runtime and there was no real difference between the two. Any special handing of @Component in PluginParameterExpressionEvaluator should not be necessary in 3.2 and I would like to clean this up. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.2.0 release
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 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 wrote: I'm going to work on the remaining issues on Saturday and get as far as I can, and start cutting the release on Sunday morning. Hopefully I will put 3.2.0 up for vote sometime Sunday. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: How alive is Plexus?
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, is supporting the Plexus way of finding component metadata and automatically creating the bindings we need so that those Plexus components run in Guice. But Maven runs on top of Guice via Sisu, not Plexus. Maven's core doesn't use any of the plexus lifecycle support either. That said we have tons of components and plugins out in the wild that use the Plexus idioms and we'll have to support that for many years even if there is no trace of Plexus in Maven's core. Which is why we have the Sisu plexus shim. I am pretty close to removing all Plexus annotations from Maven's core and with a bit of work in the CLI the core will be almost entirely JSR330 running on Guice, but Guice itself is visible in a few places where we have some custom scopes and where the Injector is brought to life. If you don't need any dynamic creation of bindings like we do (our plugin and extension mechanism) then I highly recommend you take a look at Dagger. This is the DI container that Square created and looks like more Google people are working on it now than Square employees. This looks like the successor to Guice and is 24 classes currently, easy to read and works super well in constrained environments like Android and therefore is super fast for normal applications. https://github.com/square/dagger On Feb 8, 2014, at 11:43 AM, Benson Margulies bimargul...@gmail.com wrote: 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 for plexus? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: How alive is Plexus?
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 Plexus implementation we are using today. What this is in practice, for us, is supporting the Plexus way of finding component metadata and automatically creating the bindings we need so that those Plexus components run in Guice. But Maven runs on top of Guice via Sisu, not Plexus. Maven's core doesn't use any of the plexus lifecycle support either. That said we have tons of components and plugins out in the wild that use the Plexus idioms and we'll have to support that for many years even if there is no trace of Plexus in Maven's core. Which is why we have the Sisu plexus shim. I am pretty close to removing all Plexus annotations from Maven's core and with a bit of work in the CLI the core will be almost entirely JSR330 running on Guice, but Guice itself is visible in a few places where we have some custom scopes and where the Injector is brought to life. If you don't need any dynamic creation of bindings like we do (our plugin and extension mechanism) then I highly recommend you take a look at Dagger. This is the DI container that Square created and looks like more Google people are working on it now than Square employees. This looks like the successor to Guice and is 24 classes currently, easy to read and works super well in constrained environments like Android and therefore is super fast for normal applications. https://github.com/square/dagger I'll go read. Thanks. On Feb 8, 2014, at 11:43 AM, Benson Margulies bimargul...@gmail.com wrote: 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 for plexus? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How alive is Plexus?
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 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, is supporting the Plexus way of finding component metadata and automatically creating the bindings we need so that those Plexus components run in Guice. But Maven runs on top of Guice via Sisu, not Plexus. Maven's core doesn't use any of the plexus lifecycle support either. That said we have tons of components and plugins out in the wild that use the Plexus idioms and we'll have to support that for many years even if there is no trace of Plexus in Maven's core. Which is why we have the Sisu plexus shim. I am pretty close to removing all Plexus annotations from Maven's core and with a bit of work in the CLI the core will be almost entirely JSR330 running on Guice, but Guice itself is visible in a few places where we have some custom scopes and where the Injector is brought to life. If you don't need any dynamic creation of bindings like we do (our plugin and extension mechanism) then I highly recommend you take a look at Dagger. This is the DI container that Square created and looks like more Google people are working on it now than Square employees. This looks like the successor to Guice and is 24 classes currently, easy to read and works super well in constrained environments like Android and therefore is super fast for normal applications. https://github.com/square/dagger I don't see any classpath management in here. So what's your view about that? I'll go read. Thanks. On Feb 8, 2014, at 11:43 AM, Benson Margulies bimargul...@gmail.com wrote: 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 for plexus? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How alive is Plexus?
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 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, is supporting the Plexus way of finding component metadata and automatically creating the bindings we need so that those Plexus components run in Guice. But Maven runs on top of Guice via Sisu, not Plexus. Maven's core doesn't use any of the plexus lifecycle support either. That said we have tons of components and plugins out in the wild that use the Plexus idioms and we'll have to support that for many years even if there is no trace of Plexus in Maven's core. Which is why we have the Sisu plexus shim. I am pretty close to removing all Plexus annotations from Maven's core and with a bit of work in the CLI the core will be almost entirely JSR330 running on Guice, but Guice itself is visible in a few places where we have some custom scopes and where the Injector is brought to life. If you don't need any dynamic creation of bindings like we do (our plugin and extension mechanism) then I highly recommend you take a look at Dagger. This is the DI container that Square created and looks like more Google people are working on it now than Square employees. This looks like the successor to Guice and is 24 classes currently, easy to read and works super well in constrained environments like Android and therefore is super fast for normal applications. https://github.com/square/dagger I don't see any classpath management in here. So what's your view about that? You can use something like ClassWorlds or JBoss Modules or roll your own. Dagger is only about DI which is a good thing. I'll go read. Thanks. On Feb 8, 2014, at 11:43 AM, Benson Margulies bimargul...@gmail.com wrote: 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 for plexus? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: 3.2.0 release
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 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 wrote: I'm going to work on the remaining issues on Saturday and get as far as I can, and start cutting the release on Sunday morning. Hopefully I will put 3.2.0 up for vote sometime Sunday. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Apache Maven SCM Publish Plugin 1.0 Released
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 was not difficult. Adding a note on the website and announce is a good idea. Too late this time for announce, but I'll modify site Thanks. And perhaps add something in the announce template Please. Regards, Hervé Le mercredi 5 février 2014 13:09:39 sebb a écrit : On 4 February 2014 07:23, Hervé Boutemy hbout...@apache.org wrote: The Apache Maven team is pleased to announce the release of the Apache Maven SCM Publish Plugin, version 1.0 It looks as though the plugin now requires Maven 3, whereas 1.0-beta2 did not. Was that change intentional? If so, it ought to have been mentioned in the release notes (and on the website) The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM. The primary goal was to have an utility plugin to allow Apache projects to publish Maven websites via the ASF svnpubsub system. The plugin has been tested with git scm too and by example can push content for github pages. http://maven.apache.org/plugins/maven-scm-publish-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId version1.0/version /plugin Release Notes - maven-scm-publish-plugin - Version 1.0 ** Improvement * [MSCMPUB-6] - when creating a directory in svn, if checkout fails, wait a few seconds and retry * [MSCMPUB-7] - Add timestamp when commit starts (and ends) * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server section * [MSCMPUB-11] - display content size (number of directories, files, and size) ** Story * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module ** Task * [MSCMPUB-3] - Upgrade to SCM-1.9 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Apache Maven SCM Publish Plugin 1.0 Released
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] http://maven.apache.org/docs/history.html Le dimanche 9 février 2014 02:25:16 sebb a écrit : 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 was not difficult. Adding a note on the website and announce is a good idea. Too late this time for announce, but I'll modify site Thanks. And perhaps add something in the announce template Please. Regards, Hervé Le mercredi 5 février 2014 13:09:39 sebb a écrit : On 4 February 2014 07:23, Hervé Boutemy hbout...@apache.org wrote: The Apache Maven team is pleased to announce the release of the Apache Maven SCM Publish Plugin, version 1.0 It looks as though the plugin now requires Maven 3, whereas 1.0-beta2 did not. Was that change intentional? If so, it ought to have been mentioned in the release notes (and on the website) The maven-scm-publish-plugin is a utility plugin to allow publishing Maven website to any supported SCM. The primary goal was to have an utility plugin to allow Apache projects to publish Maven websites via the ASF svnpubsub system. The plugin has been tested with git scm too and by example can push content for github pages. http://maven.apache.org/plugins/maven-scm-publish-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId version1.0/version /plugin Release Notes - maven-scm-publish-plugin - Version 1.0 ** Improvement * [MSCMPUB-6] - when creating a directory in svn, if checkout fails, wait a few seconds and retry * [MSCMPUB-7] - Add timestamp when commit starts (and ends) * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server section * [MSCMPUB-11] - display content size (number of directories, files, and size) ** Story * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module ** Task * [MSCMPUB-3] - Upgrade to SCM-1.9 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
