date:20130219

+1

2013/2/17 Dennis Lundberg denn...@apache.org:
 Hi,

 We solved N issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=18318

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-240/
 https://repository.apache.org/content/repositories/maven-240/org/apache/maven/plugins/maven-checkstyle-plugin/2.10/maven-checkstyle-plugin-2.10-source-release.zip

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-2.10/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Surefire - Run tests on remote hosts through SSH

On 18 February 2013 21:55, Julien Nicoulaud julien.nicoul...@gmail.comwrote:

 Thanks for the heads up.

 I took a deeper look at Surefire code, and it seems to me this could be
 done directly on the client side by just wrapping
 CommandLineUtils.executeCommandLine() in ForkStarter (

 https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java#L440
 ).
 This could be abstracted with a notion of CommandLineExecutor. But may be
 it's less generic than just allowing to replace ForkedBooter with another
 implementation, and do it on the server side. What extension point did you
 had in mind ?

 Looks interesting but sharing the current work dir is not enough:
  - what about dependencies (in local repo or in reactor)

 - what about multi modules project
 
 I agree this will be problematic. In first version, user would have to make
 sure shares are properly setup. We can think about automatically setting up
 shares for known things like local repo, but I'd like to wait for Vagrant
 1.1 to be out before starting investigating such things.


A more interesting option would be to do something like KK's remote class
loader so that the classpath can be loaded across the SSH tunnel.

https://github.com/jenkinsci/remoting

-Stephen



 Julien

Re: Surefire - Run tests on remote hosts through SSH

On 19 February 2013 09:37, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

On 18 February 2013 21:55, Julien Nicoulaud julien.nicoul...@gmail.comwrote:

Thanks for the heads up.

I took a deeper look at Surefire code, and it seems to me this could be
done directly on the client side by just wrapping
CommandLineUtils.executeCommandLine() in ForkStarter (

https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java#L440
).
This could be abstracted with a notion of CommandLineExecutor. But may
be
it's less generic than just allowing to replace ForkedBooter with another
implementation, and do it on the server side. What extension point did you
had in mind ?

Looks interesting but sharing the current work dir is not enough:
- what about dependencies (in local repo or in reactor)

- what about multi modules project

I agree this will be problematic. In first version, user would have to
make
sure shares are properly setup. We can think about automatically setting
up
shares for known things like local repo, but I'd like to wait for Vagrant
1.1 to be out before starting investigating such things.

A more interesting option would be to do something like KK's remote class
loader so that the classpath can be loaded across the SSH tunnel.

https://github.com/jenkinsci/remoting

Though it might not be possible to support all the way down to JVM 1.3 with
such a thing... (Given that surefire is supposed to support running the
tests (via toolchains) all the way down to 1.3 (or did you drop that far
Kristian?)

-Stephen

Julien

Re: Surefire - Run tests on remote hosts through SSH

2013-02-19 Thread Kristian Rosenvold

We actually still support forking all the way down to 1.3.

The reason we have no issues for this is
A) No-one is using it.
B) it works as advertised.

Take your pick ;)

Kristian

2013/2/19 Stephen Connolly stephen.alan.conno...@gmail.com

On 19 February 2013 09:37, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:

On 18 February 2013 21:55, Julien ll Nicoulaud
julien.nicoul...@gmail.comwrote:

Thanks for the heads up.

I took a deeper look at Surefire code, and it seems to me this could be
done directly on the client side by just wrapping
CommandLineUtils.executeCommandLine() in ForkStarter (

https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java#L440
).
This could be abstracted with a notion of CommandLineExecutor. But may
be
it's less generic than just allowing to replace ForkedBooter with
another
implementation, and do it on the server side. What extension point did
you
had in mind ?

Looks interesting but sharing the current work dir is not enough:
- what about dependencies (in local repo or in reactor)

- what about multi modules project

I agree this will be problematic. In first version, user would have to
make
sure shares are properly setup. We can think about automatically setting
up
shares for known things like local repo, but I'd like to wait for
Vagrant
1.1 to be out before starting investigating such things.

A more interesting option would be to do something like KK's remote class
loader so that the classpath can be loaded across the SSH tunnel.

https://github.com/jenkinsci/remoting

-Stephen

Julien

[VOTE] Apache Maven 3.0.5

Hi,
We fixed 1 issue:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088

Staging repository:
https://repository.apache.org/content/repositories/maven-270/

Staging distribution:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/

Vote open for 72H

[+1]
[0]
[-1]

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache Maven 3.0.5

+1


On 19 February 2013 15:28, Olivier Lamy ol...@apache.org wrote:

 Hi,
 We fixed 1 issue:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088

 Staging repository:
 https://repository.apache.org/content/repositories/maven-270/

 Staging distribution:
 https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/

 Vote open for 72H

 [+1]
 [0]
 [-1]

 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache Maven 3.0.5


Hi,

+1 (non binding from me).

Tested serveral project no regressions found.

Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-pmd-plugin 3.0 is completely broken (MPMD-163 PMD issues are reported multiple times)

Thanks for the patch.
Before releasing, I will wait some days if any other issues.

2013/2/19 Mirko Friedenhagen mfriedenha...@gmail.com:
 Hello,

 I created an issue[1] and supplied a small fix with working unittests
 and tested integratively against the project mentioned in the ticket,
 got the expected output of ~91 violations.
 Next time when I vote for a release I better take one of our bigger
 inhouse projects before stating everything is fine :-(.

 Regards Mirko

 [1] https://jira.codehaus.org/browse/MPMD-163
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Plugin Development - Injection of component


Hi,

currently I'm working on a plugin which works so far so good...but now i 
stumbled over a problem which i didn't understand...


I have a dependency to maven-invoker artifact:

  dependency
groupIdorg.apache.maven.shared/groupId
artifactIdmaven-invoker/artifactId
version2.1.1/version
  /dependency

I have the following annotations in my plugin mojo (using java 5 
annotations):


@Component
private Invoker invoker;

@Component
private InvocationRequest request;

So I thought the injection container will do it's work, but it failed.

Ok..may be I had to be more accurate like the following:

@Component(role=org.apache.maven.shared.invoker.Invoker.class, 
hint=default)

private Invoker invoker;

@Component(role=org.apache.maven.shared.invoker.InvocationRequest.class, 
hint=default)

private InvocationRequest request;

But this doesn't helped either...

I allways got the following error message:

[DEBUG] Configuring mojo 
com.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT:invoker from 
plugin realm 
ClassRealm[plugincom.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT, 
parent: sun.misc.Launcher$AppClassLoader@3182f0db]

Feb 19, 2013 4:48:54 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNING: Error injecting: com.soebes.maven.plugins.itexin.InvokerMojo
com.google.inject.ProvisionException: Guice provision errors:

1) No implementation for 
org.apache.maven.shared.invoker.InvocationRequest was bound.

  while locating com.soebes.maven.plugins.itexin.InvokerMojo

1 error
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
	at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
	at 
org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
	at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.j



It looks like i misunderstand a thing herebut currently I'm 
blockhead ;-(


Can someone enlighten me a little bit and may be give me hint what I'm 
doing wrong ...


The project can be found here: 
https://github.com/khmarbaise/itexin-maven-plugin/tree/invoker-first


Many thanks in advance..
Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin Development - Injection of component

2013-02-19 Thread Robert Scholte

InvocationRequest is not a Component, it is just an interface for  
DefaultInvocationRequest.


Just use:
InvocationRequest request = new DefaultInvocationRequest();

Robert


Op Tue, 19 Feb 2013 18:39:45 +0100 schreef Karl Heinz Marbaise  
khmarba...@gmx.de:



Hi,

currently I'm working on a plugin which works so far so good...but now i  
stumbled over a problem which i didn't understand...


I have a dependency to maven-invoker artifact:

   dependency
 groupIdorg.apache.maven.shared/groupId
 artifactIdmaven-invoker/artifactId
 version2.1.1/version
   /dependency

I have the following annotations in my plugin mojo (using java 5  
annotations):


@Component
private Invoker invoker;

@Component
private InvocationRequest request;

So I thought the injection container will do it's work, but it failed.

Ok..may be I had to be more accurate like the following:

@Component(role=org.apache.maven.shared.invoker.Invoker.class,  
hint=default)

private Invoker invoker;
  
@Component(role=org.apache.maven.shared.invoker.InvocationRequest.class,  
hint=default)

private InvocationRequest request;

But this doesn't helped either...

I allways got the following error message:

[DEBUG] Configuring mojo  
com.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT:invoker from  
plugin realm  
ClassRealm[plugincom.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT,  
parent: sun.misc.Launcher$AppClassLoader@3182f0db]

Feb 19, 2013 4:48:54 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNING: Error injecting: com.soebes.maven.plugins.itexin.InvokerMojo
com.google.inject.ProvisionException: Guice provision errors:

1) No implementation for  
org.apache.maven.shared.invoker.InvocationRequest was bound.

   while locating com.soebes.maven.plugins.itexin.InvokerMojo

1 error
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
	at  
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
	at  
org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
	at  
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.j



It looks like i misunderstand a thing herebut currently I'm  
blockhead ;-(


Can someone enlighten me a little bit and may be give me hint what I'm  
doing wrong ...


The project can be found here:  
https://github.com/khmarbaise/itexin-maven-plugin/tree/invoker-first


Many thanks in advance..
Kind regards
Karl-Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin Development - Injection of component

2013-02-19 Thread Stuart McCulloch

On 19 Feb 2013, at 17:39, Karl Heinz Marbaise wrote:

 Hi,
 
 currently I'm working on a plugin which works so far so good...but now i 
 stumbled over a problem which i didn't understand...
 
 I have a dependency to maven-invoker artifact:
 
  dependency
groupIdorg.apache.maven.shared/groupId
artifactIdmaven-invoker/artifactId
version2.1.1/version
  /dependency
 
 I have the following annotations in my plugin mojo (using java 5 annotations):
 
 @Component
 private Invoker invoker;
 
 @Component
 private InvocationRequest request;

^ looking at the invoker source (Default)InvocationRequest is not a component 
but is instead created per-request in AbstractInvokerMojo using 'new' and 
passed into the invoker:


http://svn.apache.org/viewvc/maven/plugins/tags/maven-invoker-plugin-1.8/src/main/java/org/apache/maven/plugin/invoker/AbstractInvokerMojo.java?view=markup#l1593

The Invoker is a component, so that can be injected - it's just the 
InvocationRequest that has to be assembled based on the supplied parameters 
rather than injected.

 So I thought the injection container will do it's work, but it failed.
 
 Ok..may be I had to be more accurate like the following:
 
 @Component(role=org.apache.maven.shared.invoker.Invoker.class, hint=default)
 private Invoker invoker;
 @Component(role=org.apache.maven.shared.invoker.InvocationRequest.class, 
 hint=default)
 private InvocationRequest request;
 
 But this doesn't helped either...
 
 I allways got the following error message:
 
 [DEBUG] Configuring mojo 
 com.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT:invoker from 
 plugin realm 
 ClassRealm[plugincom.soebes.maven.plugins:itexin-maven-plugin:0.1.0-SNAPSHOT,
  parent: sun.misc.Launcher$AppClassLoader@3182f0db]
 Feb 19, 2013 4:48:54 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
 WARNING: Error injecting: com.soebes.maven.plugins.itexin.InvokerMojo
 com.google.inject.ProvisionException: Guice provision errors:
 
 1) No implementation for org.apache.maven.shared.invoker.InvocationRequest 
 was bound.
  while locating com.soebes.maven.plugins.itexin.InvokerMojo
 
 1 error
   at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
   at 
 com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
   at 
 org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
   at 
 com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.j
 
 
 It looks like i misunderstand a thing herebut currently I'm blockhead ;-(
 
 Can someone enlighten me a little bit and may be give me hint what I'm doing 
 wrong ...
 
 The project can be found here: 
 https://github.com/khmarbaise/itexin-maven-plugin/tree/invoker-first
 
 Many thanks in advance..
 Kind regards
 Karl-Heinz Marbaise
 -- 
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de
 
 -
 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: Plugin Development - Injection of component


Hi Robert,
Hi Stuart,

 InvocationRequest is not a Component, it is just an interface for

DefaultInvocationRequest.


oh my lord... ;-(

Thanks for enlighten me...

Which means in other words to make the InvocationRequest being a 
component it's missing simply this:


@Component( role = InvocationRequest.class, hint = default )
public class DefaultInvocationRequest
implements InvocationRequest

and these two lines...

public interface InvocationRequest {

   String ROLE = InvocationRequest.class.getName();


Ok...many thanks...for helping...

BTW: Just for the interest is there any good reason not to make 
InvocationRequest a component ?


So this helps me a lot...

Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin Development - Injection of component

2013-02-19 Thread Stuart McCulloch

On 19 Feb 2013, at 18:08, Karl Heinz Marbaise wrote:

 Hi Robert,
 Hi Stuart,
 
  InvocationRequest is not a Component, it is just an interface for
 DefaultInvocationRequest.
 
 oh my lord... ;-(
 
 Thanks for enlighten me...
 
 Which means in other words to make the InvocationRequest being a component 
 it's missing simply this:
 
 @Component( role = InvocationRequest.class, hint = default )
 public class DefaultInvocationRequest
implements InvocationRequest

Setting aside the issue of whether DefaultInvocationRequest should really be a 
component, note that @Component by default defines a singleton component. You 
need to add:

   instantiationStrategy = per-lookup

to get a new instance on every lookup, otherwise you'd always get the same 
instance which would be bad if two threads wanted to populate InvocationRequest 
at the same time.

 and these two lines...
 
 public interface InvocationRequest {
 
   String ROLE = InvocationRequest.class.getName();
 
 Ok...many thanks...for helping...
 
 BTW: Just for the interest is there any good reason not to make 
 InvocationRequest a component ?

AFAIK InvocationRequest is just an abstraction to pass parameters, settings, 
environment etc. into the Invoker rather than something with identity/lifecycle.

 So this helps me a lot...
 
 Kind regards
 Karl-Heinz Marbaise
 -- 
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de
 
 -
 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: [VOTE] Apache Maven 3.0.5

2013-02-19 Thread Stephane Nicoll

+1

S.


On Tue, Feb 19, 2013 at 4:28 PM, Olivier Lamy ol...@apache.org wrote:

 Hi,
 We fixed 1 issue:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088

 Staging repository:
 https://repository.apache.org/content/repositories/maven-270/

 Staging distribution:
 https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/

 Vote open for 72H

 [+1]
 [0]
 [-1]

 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache Maven 3.0.5

2013-02-19 Thread Stuart McCulloch

On 19 Feb 2013, at 15:28, Olivier Lamy wrote:

 Hi,
 We fixed 1 issue:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088

^ see also 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=18697 
for what went into Wagon 2.4

 Staging repository:
 https://repository.apache.org/content/repositories/maven-270/
 
 Staging distribution:
 https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/
 
 Vote open for 72H
 
 [+1]
 [0]
 [-1]
 
 Thanks
 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 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: [VOTE] Apache Maven 3.0.5

2013-02-19 Thread Robert Scholte


+1

Op Tue, 19 Feb 2013 16:28:02 +0100 schreef Olivier Lamy ol...@apache.org:


Hi,
We fixed 1 issue:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088

Staging repository:
https://repository.apache.org/content/repositories/maven-270/

Staging distribution:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.0.5/

Vote open for 72H

[+1]
[0]
[-1]

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
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: [VOTE] Apache Maven 3.0.5

2013-02-19 Thread Jesse Glick


On 02/19/2013 10:28 AM, Olivier Lamy wrote:

We fixed 1 issue:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088


I guess this means that fixes such as MNG-5312 are deferred to another release 
like 3.1.0?


[1] https://jira.codehaus.org/browse/MNG-5312


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin Development - Injection of component


Hi Stuart,

 Setting aside the issue of whether DefaultInvocationRequest should
 really be a component, note that @Component by default defines
  a singleton component. You need to add:


instantiationStrategy = per-lookup

to get a new instance on every lookup, otherwise you'd always get the same

 instance which would be bad if two threads wanted to populate
 InvocationRequest at the same time.

That's a good hintcause that would have caught me later with my idea 
to make multiple threads running ...;-)



AFAIK InvocationRequest is just an abstraction to pass parameters, settings,

 environment etc. into the Invoker rather than
 something with identity/lifecycle.

Yes...but it would have made my life easier in my particular use 
case...but this is no reason to change such a thing...which will work 
only for a single use case.


Thanks a lot.

Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache Maven 3.0.5

2013/2/19 Jesse Glick jgl...@cloudbees.com:
 On 02/19/2013 10:28 AM, Olivier Lamy wrote:

 We fixed 1 issue:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=19088


 I guess this means that fixes such as MNG-5312 are deferred to another
 release like 3.1.0?
correct.


 [1] https://jira.codehaus.org/browse/MNG-5312



 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin Development - Injection of component

2013-02-19 Thread Robert Scholte

With a request-object we have to pass only one object instead of a lot of  
arguments.
This makes it a lot easier to maintain, because the method signature will  
never change.

It's no problem to add new fields to the request.
The same counts for response-objects, when used.

Most request-object follow the builder-pattern, every setter returns the  
request itself.

i.e.: request.setA(a).setB(b).setC(c).setD(d)


Op Tue, 19 Feb 2013 21:13:01 +0100 schreef Karl Heinz Marbaise  
khmarba...@gmx.de:



Hi Stuart,

  Setting aside the issue of whether DefaultInvocationRequest should
  really be a component, note that @Component by default defines
   a singleton component. You need to add:


instantiationStrategy = per-lookup

to get a new instance on every lookup, otherwise you'd always get the  
same

  instance which would be bad if two threads wanted to populate
  InvocationRequest at the same time.

That's a good hintcause that would have caught me later with my idea  
to make multiple threads running ...;-)


AFAIK InvocationRequest is just an abstraction to pass parameters,  
settings,

  environment etc. into the Invoker rather than
  something with identity/lifecycle.

Yes...but it would have made my life easier in my particular use  
case...but this is no reason to change such a thing...which will work  
only for a single use case.


Thanks a lot.

Kind regards
Karl-Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Rejig the front page

2013-02-19 Thread Barrie Treloar

This has been quite for about 10 days.

Is there any consensus on what the update should look like?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Rejig the front page