On 26/01/07, Kevan Dunsmore <[EMAIL PROTECTED]> wrote:
I had similar problems with extension in my own plugins. It may be related to the process Maven uses to set private member variables with bound project properties. From what I've seen, it analyzes the source of your plugin when you build and install it but not that of the superclass. It doesn't know that the "testClassesDirectory" member must be set, which causes the Surefire layer to fail with the NPE. Check to see if there is a setter for that member and define a property mapping for it. You may be able to coax it into doing the right thing. I never found a (good) solution for this. Perhaps someone else out there has bridged this gap before. BTW, my solution, which is not available to you since you can't modify the source easily, was to place abstract methods in my base class to access the values I needed. I then bound private members in my subclass plugin in the usual way and implemented the abstract methods to return the relevant values. That meant that for each plugin that extended the base class I had to re-write that boilerplate code. See what I mean about not being a good solution :-) -----Original Message----- From: Petar Tahchiev [mailto:[EMAIL PROTECTED] Sent: Thursday, January 25, 2007 12:52 PM To: Maven Users List Subject: Maven-surefire qurious problem when extending it Hi guys, I have a very unusual problem with the maven-surefire-plugin ver. 2.2 I want to write my own plugin, and as part of it's functionality is to run a couple of junit tests. So I extend the MavenSurefirePlugin and my plugin looks like this: public class MyMojo extends SurefirePlugin {} Later I map my plugin and try to run it. The problem is that whenever I run it I get the following error: [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] null [INFO] ------------------------------------------------------------------------ [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.surefire.SurefirePlugin.execute( SurefirePlugin.java:355) at org.apache.maven.plugin.DefaultPluginManager.executeMojo( DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa l( DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) On line 355 of the maven-surefire plugin stays the following line: else if ( !testClassesDirectory.exists() ) And when debugging it - YES, indeed the the testClassesDirectory is indeed null !!! I know I am missing something really fundamental, but I am not sure what it is, so any help would be greatly appretiated. Thank you all. -- Regards, Petar! Karlovo, Bulgaria. This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information that is protected from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks for the reply Kevan,
It turns out that it looks like a bug in maven, because the instance variables in the parent mojo never get populated. I can't use your approach and that's very bad. If someone else have ever had the same problem it would be nice to share the experience. Also: I want to hear some of the maven dev. guys - does it look like a bug to you and should I fill an issue in the JIRA? Thanks for any response. -- Regards, Petar! Karlovo, Bulgaria.
