I just tried the new 1.3.1 version and it works fine now.
I got the following exception on the first try though
java.lang.NoSuchMethodError:
org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding.closestReferenceMatch()Lorg/
eclipse/jdt/internal/compiler/lookup/ReferenceBinding;
at com.google.gwt.dev.javac.JsniChecker
$CheckingVisitor.findClass(JsniChecker.java:231)
at com.google.gwt.dev.javac.JsniChecker
$CheckingVisitor.checkRefs(JsniChecker.java:142)
at com.google.gwt.dev.javac.JsniChecker
$CheckingVisitor.endVisit(JsniChecker.java:65)
at
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:
247)
at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:
1337)
at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:
1206)
at
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.traverse(CompilationUnitDeclaration.java:
518)
at com.google.gwt.dev.javac.JsniChecker.check(JsniChecker.java:350)
at com.google.gwt.dev.javac.JsniChecker.check(JsniChecker.java:340)
at
com.google.gwt.dev.javac.CompilationUnitInvalidator.validateCompilationUnits(CompilationUnitInvalidator.java:
159)
at
com.google.gwt.dev.javac.CompilationState.compile(CompilationState.java:
198)
at
com.google.gwt.dev.javac.CompilationState.refresh(CompilationState.java:
178)
at
com.google.gwt.dev.javac.CompilationState.<init>(CompilationState.java:
93)
at
com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:
264)
at com.google.gwt.dev.cfg.ModuleDef.getTypeOracle(ModuleDef.java:325)
at com.google.gwt.dev.SwtHostedModeBase
$SwtBrowserWidgetHostImpl.createModuleSpaceHost(SwtHostedModeBase.java:
66)
at
com.google.gwt.dev.shell.ie.BrowserWidgetIE6$External.gwtOnLoad(BrowserWidgetIE6.java:
73)
at
com.google.gwt.dev.shell.ie.BrowserWidgetIE6$External.invoke(BrowserWidgetIE6.java:
161)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.Invoke(IDispatchImpl.java:
294)
at
com.google.gwt.dev.shell.ie.IDispatchImpl.method6(IDispatchImpl.java:
194)
at
org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:
117)
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1925)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
at
com.google.gwt.dev.SwtHostedModeBase.processEvents(SwtHostedModeBase.java:
264)
at
com.google.gwt.dev.HostedModeBase.pumpEventLoop(HostedModeBase.java:
557)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:405)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)
This was solved by changing the order of the GWT library as mentioned
in point 4 in the original email. This should really be mentioned
somewhere.
Thank you
/José
On Mar 19, 5:11 pm, Zak <[email protected]> wrote:
> Hi Keith-
>
> We're also hurtin from the absolute ${workspace_loc} path. Looking
> forward to the fix!
>
> On Mar 18, 5:31 pm, Keith Platfoot <[email protected]> wrote:
>
> > Hi Michail,
>
> > I've confirmed that this is a bug in 1.3: a directory browse dialog
> > *should*be appearing when you launch, to ask for a WAR directory.
> > However, it
> > appears that this only happens when you create a new launch configuration
> > from within the Run/Debug Configurations dialog. If you delete the existing
> > launch configuration and then right-click the project and select Run As >
> > Web Application, you should see the WAR directory prompt as expected (at
> > least the first time... after that the -war argument should be persisted).
>
> > Also, regarding the use of relative WAR directory paths: the lastWarOutDir
> > setting is only used for convenience as an initial path when we display a
> > directory browse dialog for selecting the WAR directory. If you want to
> > specify the WAR directory argument in a launch configuration as a
> > workspace-relative path, you should be able to use something like this:
>
> > -war ${workspace_loc}/path/to/war
>
> > However*,* I say *should* be able to, because unfortunately there is another
> > bug in 1.3 that prevents that variable from being resolved.
>
> > The good news is that* **we will release a fix tomorrow to resolve both of
> > these bugs*, as well as the auto-escaping bug on Windows
> > (http://code.google.com/p/google-web-toolkit/issues/detail?id=4762).
>
> > Keith
>
> > On Wed, Mar 17, 2010 at 6:53 AM, Michail Prusakov <
>
> > [email protected]> wrote:
> > > I've updated the plugin and while trying out the new stuff noticed
> > > that the plugin seems to ignore the web directory name.
>
> > > Here is what I've done: (for the record I am using eclipse galileo
> > > SR2)
> > > 1) created a wtp project with a default content directory (WebContent)
> > > 2) checked "Use Google Web Toolkit"
> > > 3) checked "This Project has a WAR directory", entered the name and
> > > unchecked "Launch and deploy from this directory"
> > > 4) saved the configuration and since I am using tomcat 6 as container,
> > > changed the order of the gwt library as it is written here:
>
> > >http://groups.google.com/group/google-web-toolkit/browse_thread/threa...
> > > (BTW it would be great if the FAQ would mention it)
> > > 5) created a module, html page, entry class (all using wizards)
> > > 6) ran the project in tomcat
> > > 7) created a debug configuration (all according to
> > >http://code.google.com/eclipse/docs/faq.html#gwt_in_eclipse_for_java_ee)
>
> > > Now the funny thing is, the manual said that the plugin would ask for
> > > a destination, but it did not. Furthermore it created a war directory
> > > and as a result the project did not work. I've then ran the gwt
> > > compiler which did ask for the destination and compiled my project.
> > > After that everything worked perfectly.
>
> > > Even though the gwt compiler added a line lastWarOutDir=<correct path
> > > here> to the com.google.gwt.eclipse.core.prefs file in
> > > project's .settings directory, every time I lunch the project for some
> > > reason the plugin still creates the war directory.
>
> > > I've created another similar project. This time I've created a debug
> > > configuration with "Run built-in server" checked. The plugin did ask
> > > for the destination but still created the war directory.
>
> > > BTW would it be possible to allow lastWarOutDir to accept relative
> > > paths (relative to workspace that is)? We usually put the settings to
> > > source control so that only one person would have to go through all
> > > the setup process.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Google Web Toolkit" group.
> > > To post to this group, send email to [email protected].
> > > To unsubscribe from this group, send email to
> > > [email protected]<google-web-toolkit%[email protected]>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/google-web-toolkit?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
