Friday, January 27, 2017

Re: GWT/Maven: No source code is available for type junit.framework.Test; did you forget to inherit a required module?



On Friday, January 27, 2017 at 4:07:16 AM UTC+1, Magnus wrote:
Hello Thomas,

I solved the actual problem by removing the Maven generated AppTest.java from the src/test/ path.
However, my further plans are concerned by what you mentioned below:

GWT doesn't care about folders, it reads resources from the classpath.
But then I don't really understand the sense of the *.gwt.xml files, which explicitely include source folders.
No, they subset the classpath by defining subpackages, independently of where they come from (and they sort-of superset the classpath with super-source too).
Still, classpath/classloader based, not file/folder based.

This means that the GWT compiler "sees" everything on the classpath, wether some subfolder is included as source code in some *.gwt.xml files or not.

At the moment, I have separate libraries, one for pure Java code and one for GWT-based Java code. I already thought about moving them into one library, where one subfolder contains the GWT-related code.
For this one "GWT-folder", this would mean:
  • Only the GWT-folder must be seen by the GWT-compiler, since the other code may not compile with it.
  • Only for the GWT-folder, the corresponding source code must be included into the library jar file.
Until now I thought I can do that by placing a *.gwt.xml file only for the GWT-folder, so that all other folders are simply not existing from the GWT's point of view.
But if I understand you right, all other folders would be included by the GWT-compiler, too. And I don't want to fix this by having special run configurations for all my applications.
The optimal solution for me would be: Include a single jar in an application project, and have both the pure Java libraries and the GWT-related libraries present in the application.

Can I do this or must I keep the both libraries separated?

You can totally do that, specifically because .gwt.xml files subset the classpath.

Recap:
1. GWT reads from the classpath, it doesn't care where the files "physically" are: this means if your classpath is src/main/java:target/classes:/path/to/gwt-user.jar:/path/to/gwt-dev.jar, you can have target/classes/myapp/MyApp.gwt.xml (in a typical Maven setup, copied there from src/main/resources/myapp/MyAp.gwt.xml) that references src/main/java/myapp/MyApp.java as simply "myapp.MyApp": GWT doesn't care whether that myapp/MyApp.java actually leaves in src/main/java, target/classes, some JAR, etc.
2. gwt.xml files subset the classpath for GWT: by default, a gwt.xml has an implicit <source path="client"/>, so putting a .gwt.xml file in a package and referencing it from another .gwt.xml (or passing it as the input to GWT) will tell GWT to only consider classes (in the form of *.java resources) in the "client" subpackage. A typical setup would put non-GWT classes in a "server" subpackage, and GWT generators into a "rebind" subpackage; GWT will then ignore them because they're not in the "source path" (which only includes the "client" subpackage here).
3. gwt.xml files can also "superset" the classpath by "rerooting" some subpackages, through super-source. If a .gwt.xml contains <super-source path="super"/>, the GWT will behave as if that "super" subpackage was added to the classpath (note that again this is about packages, whereas the classpath is defined in terms of folders and jar files; what that means is that if myapp/MyApp.gwt.xml from the above example had <super-source path="super"/>, then GWT would behave as if the classpath were src/main/java/myapp/super:target/classes/myapp/super:src/main/java:target/classes:<what would be equivalent to selecting myapp/super inside the gwt-user.jar>:/path/to/gwt-user.jar:<what would be equivalent to selecting myapp/super inside the gwt-dev.jar>:/path/to/gwt-dev.jar:<what would be equivalent to selecting the myapp/super inside the gwt-dev.jar> – well actually, the precedence rules are a bit different IIRC, but you get the idea)
4. the <source> and <super-source> (and <public> by the way) can further subset things by using includes="", excludes="" and skip="" attributes, or <include>, <exclude> and <skip> child elements (the difference between exclude and skip: skip means "not in this module, but another module –generally in the same package– could include it", whereas exclude means "never include this, even if another module –generally in the same package– would include it"; of course it only works that way if both modules are <inherited/>)

Have a look inside gwt-user.jar to understand all that: in one JAR there's client-side code, server-side code, shared client/server code, super-source code; and you can find further subsetting (using include/exclude/skip) in some .gwt.xml files in com/google/gwt/user.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment