I'm in the process of migrating some ANT build scripts to Maven by creating
mojo's that will provided the same functionality. One of the processes I
need to migrate is a customized WAR creation; I need to copy in some
additional files and I also need to create a second zip containing all
static content.
I figured I reused the maven-war-plugin, so I wrote a class that extends
WarMojo (2.0) and aside from just writing a log statement in the
buildExplodedWebapp it didn't do anything. This caused a
NullPointerException (NPE). Then I started on several permutations of this
approach and all end in a NPE. So I googled to see if anyone had done this
before and found a few that had (a.o. Seam). I tried copying their code, but
the NPE still came along. Even copying the source of WarMojo.java to my
class causes the NPE.
All the NPEs revolve around not having null directories, in this case
"outputDirectory" is null. What I do not get is why the behavior is
different if I put the WarMojo code in my own class (and thus causes a NPE);
these setting should be initialized by Maven...
java.lang.NullPointerException
at java.io.File.<init>(File.java:222)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:129)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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)
http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.0/src/main/java/org/apache/maven/plugin/war/WarMojo.java?revision=406221&view=markup
Aside from the technical issue; what would be the correct way to extend the
WAR plugin? I'm still believe I should be extending WarMojo and override &
enhance the buildExplodedWebapp method. The WarMojo can then finish up
creating the War, after I copied in the extra files, and I can also create
the additional zip at that time.
--
View this message in context:
http://old.nabble.com/extending-WAR-tp28742485p28742485.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
