You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Vincent Zurczak <vi...@linagora.com> on 2014/07/23 17:38:00 UTC

testing-harness plugin: LocalRepositoryManager is not set

Hi,

I am not sure this is the right mailing-list.
Maybe I should have posted to the dev list. Anyway...

I have started working on new Maven plug-in last week and I have set up 
unit tests using the testing-harness plugin.
I have problems with Maven injected fields, such as the Maven project.

I use the Maven libraries version 3.2.2, and the harness plugin in 
version 3.2.0.
My mojo has an injected field...

> @Parameter( defaultValue = "${project}", readonly = true )
> private MavenProject project;

This field is correctly set when I run the plugin normally.
But it is null when I use the harness plugin. Here is the code in my test.

> @Rule
> public MojoRule rule = new MojoRule();
>
> @Rule
> public TestResources resources = new TestResources();
>
> @Test( expected = MojoFailureException.class )
> public void testWithoutAssertions() throws Exception {
>
>     File baseDir = this.resources.getBasedir( "project--invalid-app" );
>     File pom = new File( baseDir, "pom.xml" );
>
>     ValidateMojo mojo = (ValidateMojo) this.rule.lookupMojo( 
> "validate", pom );
>     mojo.execute();
> }

The NPE occurs in the execute method.
The documentation indicates we have (or had) to use a stub. [0]
So, so far, I guess it makes sense (I guess, because unless you read 
this page [0], it is not clear on the web site that injected fields will 
not work).

The JIRA entry [1] states we can also use 
MojoRule#lookupConfiguredMojo() to have a mojo configured with the 
default settings.
But when I use it, that is to say...

> ValidateMojo mojo = (ValidateMojo) this.rule.lookupConfiguredMojo( 
> baseDir, "validate" );
> mojo.execute();

... I get the following exception.

> java.lang.Exception: Unexpected exception, 
> expected<org.apache.maven.plugin.MojoFailureException> but 
> was<java.lang.IllegalArgumentException>
>     at 
> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:31)
>     at 
> org.apache.maven.plugin.testing.MojoRule$2.evaluate(MojoRule.java:308)
>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
>     at org.junit.rules.RunRules.evaluate(RunRules.java:18)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>     at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>     at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>     at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>
> *Caused by: java.lang.IllegalArgumentException: Invalid repository 
> system session: LocalRepositoryManager is not set.*
>     at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.invalidSession(DefaultRepositorySystem.java:497)
>     at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.validateSession(DefaultRepositorySystem.java:443)
>     at 
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:316)
>     at 
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:192)
>     at 
> org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:380)
>     at 
> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:239)
>     at 
> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:110)
>     at 
> org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:43)
>     at 
> org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1179)
>     at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:415)
>     at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:398)
>     at 
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:389)
>     at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
>     at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:108)
>     at 
> org.apache.maven.plugin.testing.MojoRule.readMavenProject(MojoRule.java:329)
>     at 
> org.apache.maven.plugin.testing.MojoRule.lookupConfiguredMojo(MojoRule.java:352)
>     at 
> net.roboconf.maven.ValidateMojoTest.testValidProjectButInvalidApp(ValidateMojoTest.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:606)
>     at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>     at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>     at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>     at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>     at 
> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:22)
>     ... 18 more
>

=> Invalid repository system session: LocalRepositoryManager is not set.
I have been struggling with this the entire afternoon.

Any help would be appreciated.
I can submit the sources of the plugin if necessary.

Thanks,

                Vincent.




[ 0 ] : 
http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/examples/complex-mojo-parameters.html
[ 1 ] : http://jira.codehaus.org/browse/MPLUGINTESTING-23

-- 
Vincent Zurczak
Linagora: www.linagora.com <http://www.linagora.com/>

Twitter <https://twitter.com/VincentZurczak> Vincent Zurczak @ LinkedIn 
<http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> My Skype ID 
<callto://vincent.zurczak> My English blog <http://vzurczak.wordpress.com>


Re: testing-harness plugin: LocalRepositoryManager is not set

Posted by Hervé BOUTEMY <he...@free.fr>.
Le jeudi 24 juillet 2014 12:05:37 Barrie Treloar a écrit :
> On 24 July 2014 01:08, Vincent Zurczak <vi...@linagora.com> wrote:
> > Hi,
> > 
> > I am not sure this is the right mailing-list.
> > Maybe I should have posted to the dev list. Anyway...
> > 
> > I have started working on new Maven plug-in last week and I have set up
> > unit tests using the testing-harness plugin.
> > I have problems with Maven injected fields, such as the Maven project.
> 
> Here will do, the devs are on both.
> 
> (and you will have to wait for someone with more knowledge about using the
> testing harnesses)
> 
> Back when I was trying to use them you had a choice of 3, I think its not
> down to one but I dont know if the documentation on how to set it up and
> use it is readily available.
yes, the 3 are still available, even if 2 options have been removed from front 
page
you can see the previous fonrt page in history [1], and the modules are still 
availabe (and can be seen from modules report, even if not written down in 
front page)

Regards,

Hervé

[1] http://maven.apache.org/plugin-testing-archives/3.1.0/

> 
> When you get your answers, would you add to the knowledge base?
> It is always good to get fresh eyes on these things as the people who
> already know what's going on make assumptions that someone just starting
> out need to know about.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: testing-harness plugin: LocalRepositoryManager is not set

Posted by Barrie Treloar <ba...@gmail.com>.
On 24 July 2014 01:08, Vincent Zurczak <vi...@linagora.com> wrote:

>
> Hi,
>
> I am not sure this is the right mailing-list.
> Maybe I should have posted to the dev list. Anyway...
>
> I have started working on new Maven plug-in last week and I have set up
> unit tests using the testing-harness plugin.
> I have problems with Maven injected fields, such as the Maven project.
>
>>
Here will do, the devs are on both.

(and you will have to wait for someone with more knowledge about using the
testing harnesses)

Back when I was trying to use them you had a choice of 3, I think its not
down to one but I dont know if the documentation on how to set it up and
use it is readily available.

When you get your answers, would you add to the knowledge base?
It is always good to get fresh eyes on these things as the people who
already know what's going on make assumptions that someone just starting
out need to know about.

Re: testing-harness plugin: LocalRepositoryManager is not set

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,


my assumption is to use the maven-compat artifact in your project apart 
from that it would be interesting which kind of plugin do you develop 
and which intention it has...

Kind regards
Karl-Heinz Marbaise
On 7/23/14 5:38 PM, Vincent Zurczak wrote:
> Hi,
>
> I am not sure this is the right mailing-list.
> Maybe I should have posted to the dev list. Anyway...
>
> I have started working on new Maven plug-in last week and I have set up
> unit tests using the testing-harness plugin.
> I have problems with Maven injected fields, such as the Maven project.
>
> I use the Maven libraries version 3.2.2, and the harness plugin in
> version 3.2.0.
> My mojo has an injected field...
>
>> @Parameter( defaultValue = "${project}", readonly = true )
>> private MavenProject project;
>
> This field is correctly set when I run the plugin normally.
> But it is null when I use the harness plugin. Here is the code in my test.
>
>> @Rule
>> public MojoRule rule = new MojoRule();
>>
>> @Rule
>> public TestResources resources = new TestResources();
>>
>> @Test( expected = MojoFailureException.class )
>> public void testWithoutAssertions() throws Exception {
>>
>>     File baseDir = this.resources.getBasedir( "project--invalid-app" );
>>     File pom = new File( baseDir, "pom.xml" );
>>
>>     ValidateMojo mojo = (ValidateMojo) this.rule.lookupMojo(
>> "validate", pom );
>>     mojo.execute();
>> }
>
> The NPE occurs in the execute method.
> The documentation indicates we have (or had) to use a stub. [0]
> So, so far, I guess it makes sense (I guess, because unless you read
> this page [0], it is not clear on the web site that injected fields will
> not work).
>
> The JIRA entry [1] states we can also use
> MojoRule#lookupConfiguredMojo() to have a mojo configured with the
> default settings.
> But when I use it, that is to say...
>
>> ValidateMojo mojo = (ValidateMojo) this.rule.lookupConfiguredMojo(
>> baseDir, "validate" );
>> mojo.execute();
>
> ... I get the following exception.
>
>> java.lang.Exception: Unexpected exception,
>> expected<org.apache.maven.plugin.MojoFailureException> but
>> was<java.lang.IllegalArgumentException>
>>     at
>> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:31)
>>     at
>> org.apache.maven.plugin.testing.MojoRule$2.evaluate(MojoRule.java:308)
>>     at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
>>     at org.junit.rules.RunRules.evaluate(RunRules.java:18)
>>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>>     at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>>     at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>>     at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>>     at
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>>     at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>     at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>>     at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>>     at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>>     at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
>>
>> *Caused by: java.lang.IllegalArgumentException: Invalid repository
>> system session: LocalRepositoryManager is not set.*
>>     at
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.invalidSession(DefaultRepositorySystem.java:497)
>>     at
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.validateSession(DefaultRepositorySystem.java:443)
>>     at
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:316)
>>     at
>> org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:192)
>>     at
>> org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:380)
>>     at
>> org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:239)
>>     at
>> org.apache.maven.project.DefaultModelBuildingListener.buildExtensionsAssembled(DefaultModelBuildingListener.java:110)
>>     at
>> org.apache.maven.model.building.ModelBuildingEventCatapult$1.fire(ModelBuildingEventCatapult.java:43)
>>     at
>> org.apache.maven.model.building.DefaultModelBuilder.fireEvent(DefaultModelBuilder.java:1179)
>>     at
>> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:415)
>>     at
>> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:398)
>>     at
>> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:389)
>>     at
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
>>     at
>> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:108)
>>     at
>> org.apache.maven.plugin.testing.MojoRule.readMavenProject(MojoRule.java:329)
>>     at
>> org.apache.maven.plugin.testing.MojoRule.lookupConfiguredMojo(MojoRule.java:352)
>>     at
>> net.roboconf.maven.ValidateMojoTest.testValidProjectButInvalidApp(ValidateMojoTest.java:60)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>     at java.lang.reflect.Method.invoke(Method.java:606)
>>     at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>>     at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>>     at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>>     at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>>     at
>> org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:22)
>>     ... 18 more
>>
>
> => Invalid repository system session: LocalRepositoryManager is not set.
> I have been struggling with this the entire afternoon.
>
> Any help would be appreciated.
> I can submit the sources of the plugin if necessary.
>
> Thanks,
>
>                 Vincent.
>
>
>
>
> [ 0 ] :
> http://maven.apache.org/plugin-testing/maven-plugin-testing-harness/examples/complex-mojo-parameters.html
> [ 1 ] : http://jira.codehaus.org/browse/MPLUGINTESTING-23
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: testing-harness plugin: LocalRepositoryManager is not set

Posted by Vincent Zurczak <vi...@linagora.com>.
Hi,

Since I only needed to inject the Maven propject, and rather than use a 
stub, I decided to inject the Maven project manually in my mojo.

> final MavenProject mvnProject = new MavenProject() ;
> mvnProject.setFile( baseDir ) ;
> this.rule.setVariableValueToObject( mojo, "project", mvnProject );

But I would have expected the lookupConfiguredMojo method to do this for me.
Until I know more about this, I will stick with my workaround.

Regards,

                  Vincent.

-- 
Vincent Zurczak

Phone: +33 (0) 6 40 28 86 57
Linagora: www.linagora.com <http://www.linagora.com/>

Twitter <https://twitter.com/VincentZurczak> Vincent Zurczak @ LinkedIn 
<http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> My Skype ID 
<callto://vincent.zurczak> My English blog <http://vzurczak.wordpress.com>

Re: testing-harness plugin: LocalRepositoryManager is not set

Posted by Vincent Zurczak <vi...@linagora.com>.
Hi,

Le 23/07/2014 20:29, Karl Heinz Marbaise a écrit :
> my assumption is to use the maven-compat artifact in your project 

Actually, I already had this artifact in my dependencies. ;)
Your answer gave me the idea to try without, but it was worst.



Le 23/07/2014 22:06, Martin Gainty a écrit :
> MG>woops localRepositoryManager was never set! ...this should help out
> @Override
> public  void  initialize()  throws  InitializationException
> {
>      RepositorySystem  repositorySystem;
>      try  {
>          repositorySystem=  this.plexusComponentManager.getPlexus().lookup(RepositorySystem.class);
>      }  catch  (ComponentLookupException  e)  {
>          throw  new  InitializationException("Failed to lookup RepositorySystem",  e);
>      }
>
>      LocalRepository  localRepo=  new  LocalRepository(this.aetherConfiguration.getLocalRepository());
>      this.localRepositoryManager=  repositorySystem.newLocalRepositoryManager(localRepo);
> }

I have tried to set the local repository manager by hand.
I sub-classed MojoRule and overrode the readMavenProject( File ) method 
to set my local repository...


> @Override
> public MavenProject readMavenProject( File basedir ) throws Exception {
>
>         // New
>         DefaultRepositorySystemSession repositorySession = new 
> DefaultRepositorySystemSession();
>         RepositorySystem repositorySystem;
>         try {
>             repositorySystem = getContainer().lookup( 
> RepositorySystem.class );
>
>         } catch (ComponentLookupException e) {
>             throw new InitializationException("Failed to lookup 
> RepositorySystem", e);
>         }
>
>         LocalRepository localRepo = new LocalRepository( new File( 
> "/home/vzurczak/.m2/repository" ));
>         LocalRepositoryManager localRepositoryManager = 
> repositorySystem.newLocalRepositoryManager( repositorySession, 
> localRepo );
>         // New
>
>         File pom = new File( basedir, "pom.xml" );
>         MavenExecutionRequest request = new 
> DefaultMavenExecutionRequest();
>         request.setBaseDirectory( basedir );
>         ProjectBuildingRequest configuration = 
> request.getProjectBuildingRequest();
>
>         // Fix
>         repositorySession.setLocalRepositoryManager( 
> localRepositoryManager );
>         configuration.setRepositorySession( repositorySession );
>         // Fix
>
>         MavenProject project = lookup( ProjectBuilder.class ).build( 
> pom, configuration ).getProject();
>         Assert.assertNotNull( project );
>         return project;
> }

However, when I run my tests, my plug-in is not found.


> [ERROR] Unresolveable build extension: Plugin 
> net.roboconf:roboconf-maven-plugin:1.0-SNAPSHOT or one of its 
> dependencies could not be resolved: Failed to read artifact descriptor 
> for net.roboconf:roboconf-maven-plugin:jar:1.0-SNAPSHOT @

So, setting the usual local repo ignores the plugin under test.
I don't know if I could add my target directory as some sort of special 
repo.
On the other hand, maybe I am not using the testing-harness plugin 
correctly. :|

For the curious, the project is here. [0]
You can comment the things related to the roboconf-core module (in the 
POM and in the validate mojo).



Le 24/07/2014 04:35, Barrie Treloar a écrit :
> Back when I was trying to use them you had a choice of 3, I think its 
> not down to one but I dont know if the documentation on how to set it 
> up and use it is readily available. When you get your answers, would 
> you add to the knowledge base? It is always good to get fresh eyes on 
> these things as the people who already know what's going on make 
> assumptions that someone just starting out need to know about. 

Sure. I could help to update the documentation... once it works. :)
Is forking https://github.com/apache/maven-plugin-testing and submitting 
a pull request the best way to propose a patch?

Best regards,

                         Vincent.



[ 0 ] : https://github.com/roboconf/roboconf-maven-plugin


-- 
Vincent Zurczak
Linagora: www.linagora.com <http://www.linagora.com/>

Twitter <https://twitter.com/VincentZurczak> Vincent Zurczak @ LinkedIn 
<http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> My Skype ID 
<callto://vincent.zurczak> My English blog <http://vzurczak.wordpress.com>