GWT D~ Eclipse config issue?

GWT Designer allows you to quickly create the modules, composites, panels, remote services and other elements that comprise Google Web Tookit applications.

Moderators: Konstantin.Scheglov, gnebling, Alexander.Mitin, jwren, Eric Clayberg

GWT D~ Eclipse config issue?

Postby rationalblue » Sat Apr 07, 2007 6:10 am

Restated issue below.
Last edited by rationalblue on Sun Apr 08, 2007 2:02 am, edited 2 times in total.
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Re: GWT D~ Eclipse config issue?

Postby rationalblue » Sat Apr 07, 2007 1:35 pm

Update -- At the suggestion of Reinier Zwitserloot over at the google gwt forum (Problem When Compiling GWT Application) I built a project from scratch using the shell command-line approach (projectCreator and applicationCreator). I then imported the project into Eclipse, and added the <inherit..> tag to identify the xml package. This approach worked to eliminate the problem of editor unable to resolve references to the xml library. The editor no longer flags the offending import statements, and the project compiles/deploys normally.

Hence, I infer that the problem I identified is confined to the Eclipse/GWT Designer configuration. I am able to resume progress -- I can build a project with xml functionality, and edit/compile/deploy it with the GWT Designer functionality. But, the requirement to originate all projects that intend to use the xml (or similarly packaged gwt libraries) using the shell-script is cumbersome. If you can identify a configuration fix so that the GWT Designer New Java Project feature achieves the same result, it would be greatly appreciated.
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Re: GWT D~ Eclipse config issue?

Postby Eric Clayberg » Sat Apr 07, 2007 1:43 pm

The question to you is what is the difference between the two projects or project structures?

Any differences in your .classpath or any of the relavant XML files?
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby Konstantin.Scheglov » Sat Apr 07, 2007 11:24 pm

Here is copy of my message in Google's GWT forum. ;-)

Yes, Eclipse shows and allows to use all classes from gwt-user.jar just because this jar is in classpath.

However GWT compiler allows you use only classes in inherited modules. When I try to use XMLParser in default GWT project created with GWT Designer, it shows me compilation error because by default GWT project includes only one modules:
<inherits name="com.google.gwt.user.User"/>

But once I include also following line in gwt.xml module description:
<inherits name="com.google.gwt.xml.XML"/>

...GWT Designer does not show compilation problem for XMLParser anymore. We specially added such feature for GWT Designer to show you problems with modules imports early, during editing of project, not during compilation and show message that you missed some GWT module import.
Konstantin.Scheglov
Moderator
 
Posts: 186
Joined: Tue Oct 18, 2005 8:11 pm
Location: Russian Federation, Lipetsk

Postby rationalblue » Sun Apr 08, 2007 2:01 am

In response to Eric's question -- I don't know of any specific differences between project configs. I built the offending project using only the File > New > Other > GWT Java Project menu item in GWT Designer. I built the project that worked using the command-line shell scripts from GWT ("projectCreator" and "applicationCreator"), and then imported it into Eclipse. That strategy worked -- the editor was able to resolve the names only after I took that approach. So, the problem would appear to be isolated to something in the Eclipse GWT Designer, specifically in the way it constructs the stubbed GWT Java Project.

Before I tested (Google forum) RZ's suggestion, the Eclipse GWT Designer was able to compile and deploy the code, even though the Eclipse editor indicated that it was unable to resolve the names in the import statements. That result isolated the problem to the editor. That conclusion was further substantiated by the fact that as the names were being typed into the import statement, the documentation popup DID recognize the names, and displayed the options available for completing the import statement. Yet, after I finished typing the import statement, the editor could not resolve the names. This inconsistency, together with the results of the test RZ suggested, led me to conclude the problem was internal to the GWT Designer tool (at least the mac version) that I'm using, and not a problem with the GWT package, per se.

I appreciate that you apparently did take steps to resolve this issue early on. I only downloaded the version of GWT Designer a couple of days ago for evaluation on my Mac. I suppose it is possible that the glitch you had resolved in earlier versions somehow returned in the Mac version. (I've had gremlins return in code before, so I know how frustrating that can be.)
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Postby Konstantin.Scheglov » Sun Apr 08, 2007 2:27 am

Well, may be I should describe in more details how we show GWT specific compilation problems. We add so named "compilation participant", extension point "org.eclipse.jdt.core.compilationParticipant" that allows us do some additional steps during compilation. What we do is check that all types references in "client" code are available in imported GWT modules. As you know, GWT has sub-set of JRE "lang" and "util" classes as well as set of its own UI and non-UI classes.

We don't implement our own Java editor, we use standard one from Eclipse JDT. It will allow you import any classes that are available in classpath. However GWT adds one requirement that you should also add GWT module with this class in GWT.XML descriptor. This is why "editor could not resolve the names" after you finish typing.

I've checked today morning that GWT tools create project with same initial imports - only "com.google.gwt.user.User" module, so even in this case you have to add import for "com.google.gwt.xml.XML".

Also, if I try to start GWT application without importing XML, GWTShell shows me error:
[ERROR] Line 7: The import com.google.gwt.xml cannot be resolved

Where line 7 contains following code:

import com.google.gwt.xml.client.XMLParser;


Well, I know that it is not obvious that you need something additional than have jar in classpath, but this is how GWT works.
Konstantin.Scheglov
Moderator
 
Posts: 186
Joined: Tue Oct 18, 2005 8:11 pm
Location: Russian Federation, Lipetsk

Re: GWT D~ Eclipse config issue?

Postby Eric Clayberg » Sun Apr 08, 2007 5:05 am

rationalblue wrote:Hence, I infer that the problem I identified is confined to the Eclipse/GWT Designer configuration. I am able to resume progress -- I can build a project with xml functionality, and edit/compile/deploy it with the GWT Designer functionality. But, the requirement to originate all projects that intend to use the xml (or similarly packaged gwt libraries) using the shell-script is cumbersome. If you can identify a configuration fix so that the GWT Designer New Java Project feature achieves the same result, it would be greatly appreciated.

Please see Konstantin's earlier response. What you are describing as a "problem" isn't actually a problem at all. It is the result of a feature intentionally added to GWT Designer so that it can flag problems with GWT code much earlier than GWT would by itself. By itself, the Eclipse compiler would not flag a problem with referencing the GWTParser class, but your GWT code would still fail at runtime due to the missing <inherits> statement in your gwt.xml file. GWT Designer enhances the Eclipse compiler with knowledge about the gwt.xml file and the capabilities of the GWT libraries. GWT Designer can actually flag references to classes that are not emulated by GWT or that are not inherited properly. GWT, using only the un-augmented Eclipse compiler, can't do this, so you run the considerable risk of discovering problems at runtime that could (and should) have been caught much earlier. Using GWT Designer, you should see compilation problems like the following:

Code: Select all
com.google.gwt.xml.client.XMLParser can not be found in source packages. Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly

Once you fix the problem with the gwt.xml file and force a recompile of your class (either by resaving it or telling Eclipse to rebuild it), those errors will go away.

Image
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby rationalblue » Sun Apr 08, 2007 7:55 am

Thanks for the detailed treatment of the issue, and I don't mean to belabor what may now turn out to be an unimportant detail, or which may, in the end, be unrelated to your product. You have a great product which has performed well in my evaluation so far.

However, as I said earlier -- I observed that the Eclipse editor continued to flag the import statements AFTER I had included the appropriate <inherits..> tag in the config xml file. It continued to flag the import statements, and new ones added, EVEN THOUGH it also displayed the correct and appropriate documentation in the code-completion popup as the lines were being entered. Moreover, the code compiled and deployed correctly without error, despite the red-underscored lines in the edit window.

That is most certainly not an intentional feature of Eclipse.

Just a few minutes ago, I determined that executing a "Clean" will apparently cause the editor to suddenly get smart and no longer flag the import statements. I have now tested that result a couple of times.

I have no clue what "Clean" does, but I suspect that it clears some cache in the deep dark recesses of the editor; and that bowel movement causes it to recover its senses.

As I said, I apologize if I've brought too much attention to this issue. And I do very much appreciate your support. The issue stumped me for a day and a half. The simple expedient of inserting the <inherits...> tag resolved the functional problem -- allowing the project to compile/deploy without errors. But it did NOT eliminate the troubling problem of confusion with the editor's unhappy name resolution problem.

It now appears that the complete solution is simple:

<inherits...> in the appropriate project xml config file, AND
Clean before you Build.

Perhaps that's always good advice, but in the heat of learning a new tool, two if you include GWT, and the usual uncertainty about exactly what it is that Eclipse is doing, I beg leave to be briefly insane.
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Postby Eric Clayberg » Sun Apr 08, 2007 8:28 am

rationalblue wrote:However, as I said earlier -- I observed that the Eclipse editor continued to flag the import statements AFTER I had included the appropriate <inherits..> tag in the config xml file. It continued to flag the import statements, and new ones added, EVEN THOUGH it also displayed the correct and appropriate documentation in the code-completion popup as the lines were being entered. Moreover, the code compiled and deployed correctly without error, despite the red-underscored lines in the edit window.

Was the xml file saved? Had you saved the java file or done anything else that would have caused the class to be recompiled?

The Eclipse incremental compiler kicks in when Java classes are changed or when files like the .classpath file are changed. It does not trigger a recompile when an xml file is changed. We are looking into ways to force that to happen.

rationalblue wrote:Just a few minutes ago, I determined that executing a "Clean" will apparently cause the editor to suddenly get smart and no longer flag the import statements. I have now tested that result a couple of times. I have no clue what "Clean" does, but I suspect that it clears some cache in the deep dark recesses of the editor; and that bowel movement causes it to recover its senses.

Actually, all "Clean" does is trigger a manual build (e.g., it cleans out the existing .class files and regenerates them).

You can accomplish the same thing with the Java file you are working with by re-saving it. That will trigger it to recompile with updated knowledge about the state of the gwt.xml file.

Those errors always reflect the state of the gwt.xml file the last time the file was compiled. If the gwt.xml file was missing an <inherit> at the time of compilation, you would see those errors. Once the gwt.xml file is fixed, those errors would go away the next time the file is compiled (for any reason). Unfortunately, just changing the gwt.xml file by itself is not enough to trigger a project-wide recompile (as changing the .classpath file would).

rationalblue wrote:As I said, I apologize if I've brought too much attention to this issue. And I do very much appreciate your support. The issue stumped me for a day and a half. The simple expedient of inserting the <inherits...> tag resolved the functional problem -- allowing the project to compile/deploy without errors. But it did NOT eliminate the troubling problem of confusion with the editor's unhappy name resolution problem.

If at any time during that period your Java file was modified and saved, those compilation problems should have gone away immediately (assuming that you have automatic build turned on for your project). If automatic build is turned off, you would need to manually trigger a build.

rationalblue wrote:It now appears that the complete solution is simple:
<inherits...> in the appropriate project xml config file, AND
Clean before you Build.

Clean is just synonymous with (Re)Build.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby rationalblue » Sun Apr 08, 2007 9:03 am

I just stepped through a distilled sequence to reproduce the problem, and it goes like this:

Create a new GWT Java Project
Add a single import statement from the libraries in question, such as: com.google.gwt.user.client.xml.XMLParser;

Editor will popup completion window until you reach the first x, then it will flag the line with red underscore indicating it can't resolve the name.

Edit the gwt.xml file to add the <inherits...> tag:
<inherits name="com.google.gwt.xml.XML"/>
Save the gwt.xml file.

Return and note that the editor has still flagged the offending import statement with the red underscore and indicates it can't resolve the name.

Save that java file. Saving does not change the editor's mood about the offending line.

Attempt Build All, or Build Project. It will fail to launch due to errors.

Do a Clean.

You can now build and execute the project without problems.
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Postby Eric Clayberg » Sun Apr 08, 2007 2:26 pm

rationalblue wrote:then it will flag the line with red underscore indicating it can't resolve the name.

Exactly what error are you seeing? Are you seeing a type resolution error like "XMLParser can't be resolved to a type" or a module inheritance error like "XMLParser can not be found in source packages. Check the inheritance chain from your module; it may not be inheriting a required module or a module may not be adding its source path entries properly"? Those are very different errors.

rationalblue wrote:Edit the gwt.xml file to add the <inherits...> tag:
<inherits name="com.google.gwt.xml.XML"/>
Save the gwt.xml file.
Return and note that the editor has still flagged the offending import statement with the red underscore and indicates it can't resolve the name.

Are you sure its flagging a type resolution problem? Until that Java file is recompiled, the module inheritance error would remain.

rationalblue wrote:Save that java file. Saving does not change the editor's mood about the offending line.

Hmmm. Under normal circumstances, saving the file should definitely remove that error at that point. The only way that I can think of that it would not do this would be for automatic building to be turned off (not something I would ever recommend).

rationalblue wrote:Attempt Build All, or Build Project.

Build All and Build Projects shouldn't even be available options, if you have automatic building turned on.

Neither of those options triggers a full rebuild. They only rebuild the Java files that have been modified/affected since the last build.

rationalblue wrote:Do a Clean. You can now build and execute the project without problems.

Clean actually does do a full rebuild of all files whether Eclipse considers them to be dirty or not.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby Eric Clayberg » Sun Apr 08, 2007 4:32 pm

I have some good news to report...we have been investigating how to get Eclipse to trigger a recompile any time the gwt.xml file changes.

You will need to try the latest build and make sure that you have the Eclipse Project > Build Automatically option turned on.

Before:

Image

After:

Image
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby rationalblue » Mon Apr 09, 2007 5:18 am

Your recommendation is definitely consistent with my observations -- the clue was the difference between Clean and Build All, which apparently doesn't really mean "build all,"....
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Postby Eric Clayberg » Mon Apr 09, 2007 7:37 am

rationalblue wrote:Your recommendation is definitely consistent with my observations -- the clue was the difference between Clean and Build All, which apparently doesn't really mean "build all,"....

Hopefully, the latest build will make all of this a moot point. ;-)
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Postby rationalblue » Wed Apr 11, 2007 11:15 am

What is the procedure to install the latest build on my Mac, if I'm still in the eval period for the earlier build?

I have been using GWT Designer v1.6.0_for_Eclipse3.2

Eclipse 3.3 is not yet available for Mac (as of last night).

I have downloaded GWT for the mac, v1.6.1_for_Eclipse3.2.zip, and unzipped it into the same folder as v1.6.0.

There are no instruction on the website for this how to proceed beyond this point.

Thanks.
rationalblue
 
Posts: 11
Joined: Thu Apr 05, 2007 2:41 pm
Location: Maryland

Next

Return to GWT Designer

Who is online

Users browsing this forum: No registered users and 3 guests