search

tbroyer / gwt-maven-plugin

Starting fresh on building GWT projects with Maven
https://tbroyer.github.io/gwt-maven-plugin/
Apache License 2.0
169 stars 41 forks source link

gwt-maven-plugin not working 2.6.0-rc1 #11

Closed natros closed 11 years ago

natros commented 11 years ago

[INFO] --- gwt-maven-plugin:1.0-SNAPSHOT:compile (default-compile) @ cexp-client --- [INFO] Unexpected internal compiler error java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at net.ltgt.gwt.maven.CompileMojo.execute(CompileMojo.java:351) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) at org.codehaus.classworlds.Launcher.main(Launcher.java:46) 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: java.lang.NoSuchMethodError: com.google.gwt.dev.jjs.JJSOptions.shouldClusterSimilarFunctions()Z at com.google.gwt.dev.jjs.JJSOptionsImpl.copyFrom(JJSOptionsImpl.java:64) at com.google.gwt.dev.PrecompileTaskOptionsImpl.copyFrom(PrecompileTaskOptionsImpl.java:61) at com.google.gwt.dev.CompilerOptionsImpl.copyFrom(CompilerOptionsImpl.java:38) at com.google.gwt.dev.CompilerOptionsImpl.(CompilerOptionsImpl.java:34) at com.google.gwt.dev.Compiler.(Compiler.java:118) ... 32 more

tbroyer commented 11 years ago

Are you following these instructions: http://mojo.codehaus.org/gwt-maven-plugin/user-guide/using-different-gwt-sdk-version.html

What does your POM look like?

natros commented 11 years ago

I'm using this plugin (https://github.com/tbroyer/gwt-maven-plugin) not the one from http://mojo.codehaus.org/gwt-maven-plugin/ I thought they were different.

tbroyer commented 11 years ago

Oh whoops! Maybe I should have named it differently after all ;-)

The plugin is supposed to be compiled against the same version of GWT that it'll be used with, and I haven't updated it for 2.6.0-rc1. Maybe you could fork, patch and make a pull-request? I'll happily review it then.

natros commented 11 years ago

Hi Thomas,

It seems there are new methods in com.google.gwt.dev.CompilerOptions that needs to be overridden in CompileMojo. I’ll try to make a patch if I find some spare time.

I’ve read somewhere that this plugin is supposed to be the next gwt official plugin. Are you still commited with that, or should I start looking to the other gwt-maven-plugin?

Filipe Sousa

On 10 Nov 2013, at 16:18, Thomas Broyer notifications@github.com wrote:

Oh whoops! Maybe I should have named it differently after all ;-)

The plugin is supposed to be compiled against the same version of GWT that it'll be used with, and I haven't updated it for 2.6.0-rc1. Maybe you could fork, patch and make a pull-request? I'll happily review it then.

— Reply to this email directly or view it on GitHub.

tbroyer commented 11 years ago

Well, honestly, I don't know. I'm sick of Maven (see http://blog.ltgt.net/maven-is-broken-by-design), and GWT probably won't use Maven after all. So let's say that for now I'm no longer committed to this plugin, but if the community asks for it en masse and the Steering Committee agrees on having an official plugin, then this will likely be that one and then I'll probably be the one maintaining it.

ekuefler commented 11 years ago

My projects also appear to be broken under GWT 2.6. Thomas, do you know what the recommended way to be doing GWT project management will be going forward?

tbroyer commented 11 years ago

Gradle? No, (a bit) more seriously, we should probably have some official support for Maven, but if the Steering Committee isn't committed to an official plugin, then the community will have to choose between the org.codehaus.mojo and this one and maintain it.

I'm currently working on updating org.codehaus.mojo, and will get back to this one after that if Colin doesn't update his PR in between. I still believe this plugin is better than the org.codehaus.mojo one, but there has to be a community effort backing it. I'm still wondering what would be best: I'm currently updating the org.codehaus.mojo plugin because no one else is doing it; that means that either there's no GWT+Maven community, or it's too lazy (or, and I fear it's the real reason, it's mostly composed of “Enterprise” people who live “in the past”: very conservative and only updating their tools and dependencies when they're forced to do it). If I'm the only maintainer for GWT+Maven tools, we'll have to choose one and deprecate the other. My preference would go to this new plugin then, but what if everyone else prefers to continue using the other one?

branflake2267 commented 11 years ago

Well, I admit I could do more but haven't, more or less, I've been packing my schedule with another open source project, very dependent on maven, so I've got to figure out how to help more. :) Now that I've shipped the latest feature, I should be a bit more flexible.

I think the community that wants maven won't update unless they need or have too. I bet like you said, they are sitting on the sidelines waiting for someone else to do it.

If you ask me, I vote to deprecating codehaus and move to this plugin, especially since you're the maintainer of both anyway. I'm not sure I would even bring codehaus up to 2.6, instead focus on yours. :)

tbroyer commented 11 years ago

Thanks a lot for your support @branflake2267 ! I don't blame you, you seem to be doing awesome things in the GWTP+Eclipse/IDEA land.

FYI, the reason I'm updating the codehaus plugin is that we're using it for gwt-site-webapp and @skybrian would like to update it to GWT 2.6 to make use of the -saveSource and -saveSourceOutput arguments. FYI, @jieryn also proposed on Twitter to update it, but only changing the dependency.

Also, not everyone would move to this plugin from the codehaus one as it has fewer features, and I believe some people really need to fork the GWT compilation into another JVM (specifying a distinct JDK to use; e.g. Maven runs from an IBM JDK and they fork an Oracle JDK or OpenJDK for the GWT Compiler; or just for the memory tuning).

skybrian commented 11 years ago

Oh wow there are two of them? Not a Maven fan; I'm just using the one Daniel (I assume) picked for that project.

tbroyer commented 11 years ago

FYI, I just pushed a 2.6.0-SNAPSHOT of the codehaus plugin compiled against GWT 2.6.0-rc1 and adding all missing arguments. I might add an "extraGwtArgs" parameter before releasing 2.6.0-rc1. Please test it and report issues to me by mail directly; I'll release 2.6.0-rc1 in the next few days.

Now back to this net.ltgt plugin.

tbroyer commented 11 years ago

Fixed by 59edbdb

branflake2267 commented 11 years ago

Nice job

tbroyer commented 11 years ago

Just deployed a 1.0-SNAPSHOT to oss.sonatype.org for your testing pleasure. I'll cut another alpha soon. I still need to sort out why integration tests are failing.

natros commented 11 years ago

Thank you Thomas.