super-source and eclipse

[Alberto Mancini]

Hi,
in the development of our current project
(Augmented Reality with GWT, the first HOWTO is at http://jooink.blogspot.com/2012/10/gwt-augmented-reality-howto-step-0.html)
we used super-source tag that works perfectly and helped us in avoiding a long code 'refactoring' but I am not able
to convince eclipse to stop showing errors in the 'super-source'd packages (packages names do not match).
This is not really a problem because the code compiles without errors  but having projects with errors is annoying.
Anyone has a suggestion ?

Thanks,
   Alberto.

[Abraham Lin]

Add the root of your super-source folder as a source folder (right-click the folder, open the "Build Path" submenu, and click "Use as Source Folder"). Eclipse should automatically make the necessary modifications to the parent source folder, but you might want to check to make sure.

-Abraham

[Alberto Mancini]

Works perfectly :)

Thank you.
   Alberto

On Fri, Oct 5, 2012 at 3:28 PM, Abraham Lin <atomknig...@gmail.com> wrote:

Add the root of your super-source folder as a source folder (right-click the folder, open the "Build Path" submenu, and click "Use as Source Folder"). Eclipse should automatically make the necessary modifications to the parent source folder, but you might want to check to make sure.

-Abraham

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/qqiCk1UtOBsJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Friday, October 5, 2012 3:28:51 PM UTC+2, Abraham Lin wrote:

Add the root of your super-source folder as a source folder (right-click the folder, open the "Build Path" submenu, and click "Use as Source Folder"). Eclipse should automatically make the necessary modifications to the parent source folder, but you might want to check to make sure.

Don't do that: Eclipse will then compile you super-source and you then risk making your non-client code using those classes fail (unit-tests, server-side, etc.)

To only get rid of the warnings, right-click on the super-source "package" and chose Build Path → Exclude. Or move the super-source into a sibling folder hierarchy that you do not import as a Source Folder in Eclipse but only as a Folder (this is the approach taken by GWT itself: "src/" contains code to be compiled, "super/" contain super-source, e.g. src/com/google/gwt/core/client/impl/WeakMapping.java vs. super/com/google/gwt/core/translatable/com/google/gwt/core/client/impl/WeakMapping.java – a mix of both approaches actually, as newer modules such as com.google.gwt.regexp use a "super" subfolder in the "src/" branch)

And if you want the "full power" of Eclipse for super-source classes, then create another Eclipse project where you import the super-source folder as a Source Folder (again, that's what GWT does: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/user/.classpath vs. http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/lang/.classpath)

[Abraham Lin]

On Friday, October 5, 2012 10:47:33 AM UTC-4, Thomas Broyer wrote:

Don't do that: Eclipse will then compile you super-source and you then risk making your non-client code using those classes fail (unit-tests, server-side, etc.)

Ah, that's true. I'm used to separating client and server code into separate projects, so this hadn't occurred to me.

 

And if you want the "full power" of Eclipse for super-source classes, then create another Eclipse project where you import the super-source folder as a Source Folder (again, that's what GWT does: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/user/.classpath vs. http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/lang/.classpath)

Doesn't this lead to the same problem as adding the super-source folder directly as a source folder? If the fundamental problem is that client-side tests and server-side tests need different classpath configurations, then you would presumably need separate projects or separate testing configurations (with includes/excludes as appropriate).

[Thomas Broyer]

On Friday, October 5, 2012 5:36:26 PM UTC+2, Abraham Lin wrote:

On Friday, October 5, 2012 10:47:33 AM UTC-4, Thomas Broyer wrote:

Don't do that: Eclipse will then compile you super-source and you then risk making your non-client code using those classes fail (unit-tests, server-side, etc.)

Ah, that's true. I'm used to separating client and server code into separate projects, so this hadn't occurred to me.

It's not only about client vs. server, it also affects non-GWTTestCase unit tests of your client code.

 

And if you want the "full power" of Eclipse for super-source classes, then create another Eclipse project where you import the super-source folder as a Source Folder (again, that's what GWT does: http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/user/.classpath vs. http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/lang/.classpath)

Doesn't this lead to the same problem as adding the super-source folder directly as a source folder?

The files will only be compiled into the other Eclipse project, whose output dir is different from the "main" project. That other Eclipse project is only used for editing (so you can take advantage of Eclipse's refactoring or "search references" features for instance), everything else (tests, etc.) still has to be done in the "main" project, where the files are treated as resources, not source files.

[Abraham Lin]

On Friday, October 5, 2012 1:46:54 PM UTC-4, Thomas Broyer wrote:

It's not only about client vs. server, it also affects non-GWTTestCase unit tests of your client code.

 

This doesn't seem right. Given that your client classes will be relying on the super-sourced logic at runtime, why shouldn't the tests utilize the same logic as well? There are almost certainly going to be slight differences between the original non-translatable classes and the super-sourced equivalents, so I'm not seeing why the tests would be structured to make use of the former when the fully-compiled code makes use of the latter. In the best case, the two have the exact same semantics. and it doesn't matter which one you use. But in the general case, the two are not quite the same, so it would seem to make more sense to depend on the version that will actually be in use at runtime.

[Thomas Broyer]

You can have the same test run in both modes: JRE which is very fast, and GWT which is painfully slow. com.google.gwt.regexp, com.google.gwt.typedarrays, com.google.gwt.safehtml are things you can use in both modes; that way you can test your business logic with a fast JRE test, and once in a while (e.g. on the CI server) confirm that it'll run in the browser with a slow GWT test. The same goes for your own emulated things: unit-test them (in both modes), then use them (and unit-test that code in JRE mode only, or in both mode; but developers don't have to pay the slow GWTTestCase tax and can still run tests on their own machines, fast)

[Pacha Thavala]

Do you know how to make the file in  super-source tag available on compile time?

[confile]

How should this work with a second project?

If I a super/ folder as source and have a gwt.xml in super/emul.gwt.xml with: 

<super-source path=""/>

Then this will not work. The super source must be in a subfolder.