[
http://jira.codehaus.org/browse/MGWT-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179518#action_179518
]
Kazimierz Pogoda edited comment on MGWT-86 at 6/6/09 9:43 AM:
--------------------------------------------------------------
I have identified the problem. I am working in the same company as Leszek. We
are using similar complex architecture of maven/gwt builds across different
projects. Our specific approach triggers error described in this ticket. Here
is brief description of our use case - projects are split into maven modules:
* we are using a lot of own gwt libraries (no entry points) - they are
packaged in jars and supplemented with sources of the client gwt part
* gwt part of the application has own maven module which depends on these
libraries - it is also supplemented with sources of the client gwt part
* war artifact is produced by another module which depends on gwt part module
The {{NullPointerException}} is thrown when {{CompileMojo}} invoked from war
producing mave module tries to resolve the gwt module using classpath. In case
of mave module sources it works ok, in case of scanning global mojo classpath
for gwt modules it fails.
The reason is in {{classpathBuilder}} field of {{AbstractGwtMojo}} class being
hidden by field of the same name from {{AbstractGwtShellMojo}} class. Removing
this field solved our problem but I don't know the side consequences.
was (Author: morisil):
I have identified the problem. I am working in the same company as Leszek.
We are using similar complex architecture of maven/gwt builds across different
projects. Our specific approach triggers error described in this ticket. Here
is brief description of our use case - projects are split into maven modules:
* we are using a lot of own gwt libraries (no entry points) - they are
packaged in jars and supplemented with sources of the client gwt part
* gwt part of the application has own maven module which depends on these
libraries - it is also supplemented with sources of the client gwt part
* war artifact is produced by another module which depends on gwt part module
The {{NullPointerException}} is thrown when {{CompileMojo}} tries to resolve
the module using classpath. In case of module sources it works ok, in case of
scanning global mojo classpath it fails.
The reason is in {{classpathBuilder}} field of {{AbstractGwtMojo}} class being
hidden by field of the same name from {{AbstractGwtShellMojo}} class. Removing
this field solved our problem but I don't know the side consequences.
> NPE during compilation
> ----------------------
>
> Key: MGWT-86
> URL: http://jira.codehaus.org/browse/MGWT-86
> Project: Maven 2.x GWT Plugin
> Issue Type: Bug
> Reporter: Leszek Gruchala
> Priority: Blocker
>
> I'm trying to run the plugin on the Hudson:
> Here you have stacktrace:
> INFO] [gwt:compile {execution: compile}]
> [INFO] using GWT jars for specified version 1.6.4
> [INFO] Unpack native libraries required to run GWT
> [INFO] establishing classpath list (scope = compile)
> [....]
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] null
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.codehaus.mojo.gwt.AbstractGwtModuleMojo.readModule(AbstractGwtModuleMojo.java:156)
> at
> org.codehaus.mojo.gwt.shell.CompileMojo.compilationRequired(CompileMojo.java:175)
> at org.codehaus.mojo.gwt.shell.CompileMojo.compile(CompileMojo.java:133)
> at
> org.codehaus.mojo.gwt.shell.CompileMojo.doExecute(CompileMojo.java:97)
> at
> org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMojo.java:134)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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 hudson.maven.agent.Main.launch(Main.java:165)
> at hudson.maven.MavenBuilder.call(MavenBuilder.java:159)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:579)
> at
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:525)
> at hudson.remoting.UserRequest.perform(UserRequest.java:103)
> at hudson.remoting.UserRequest.perform(UserRequest.java:47)
> at hudson.remoting.Request$2.run(Request.java:236)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
> If there is something I can help you resolve the problem, just ask.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
