[
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:41 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}} 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.
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 log 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
