GWT module library should be prepared according to specific convention. The part of module source code which is compiled from Java into Java Script, resides in org.foo.module.client package by default. GWT compiler will use Java sources, not compiled Java bytecode, thus it is important to include "client side" sources inside module library jar file. Building proper jar requires some modification to project's standard pom.xml file:
<resources>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/client/**</include>
<include>**/public/**</include>
<include>**/*.gwt.xml</include>
</includes>
</resource>
</resources>
Source code doesn't belong to standard library archives which should only contain the class files and requires resources.
ReplyDeleteYou should instead pack the project's source to a separate JAR using mvn's source:jar which you can then use whenever necessary.
With GWT you should add the source JAR (which has a classifier "sources") as a dependency. Don't forget to the classifier.
I also don't like mixing compiled classes and their source code in single jar file. But look at the content of gwt-user.jar file which comes with GWT distribution. It is completely mixed, and it is done for a reason.
ReplyDeleteThe GWT comes with a lot of specific conventions that programmer must follow. From beginning it could be really hard for conservative programmer - it was hard for me :)
The approach you are proposing is possible, but makes things much more complicated. In order to work, GWT compiler (also GWT Shell) must have module client source code available via classloader (in practice specified on classpath). You approach implies having complete source jar in the classpath when using GWT! Even if it is possible to set in maven with some tricks I regard doing things this way as non-intuitive (for example for ant users).
IMO understanding the problem requires a paradigm shift. Let me make an analogy - from GWT compiler perspective Java source code which resides in package client plays analogous role as Java byte code for JIT compiler - GWT compiler treats Java as a scripting language (meta definition), which is transformed into another scripting language.
When we are creating GWT module library consisting of client and server code, and we want to share such project, then the source code in client package is a part of data needed to compile other projects against this module. We have to make it available anyway - putting everything in single jar instead of creating two or three (2 kinds of sources - 1 is public) jars seems much more convenient to me.
BTW - GWT approach implies opening the sources of client side code, as a side effect. :)
Both 'anonymous' and 'morisil' (OP) have valid points. I'm currently also struggling with myself trying to figure out which way to go.
ReplyDeleteApart from whether we like or dislike putting source code and compiled artifacts into one and the same JAR there's legal implication. Assume that you as an enterprise develop a generic set of RPC modules and build different web apps for customers on top of them. Hence, you'll produce a WAR that contains your module JAR(s). Since, they are RPC modules the respective JAR contains both client side code and server side code.
Do you really want to ship that to the client? It contains source code...Are you even allowed to ship source code to the client?
I guess to deal with it properly you'd need to produce two artifacts from your module project: a client JAR for the GWT compiler to translate (contains source code) and a server JAR to be packed into a WAR.
Marcel, what you deploy to the client side is the compiled client side javascript and the compiled classes in the war file. You only package the sources if you are creating a reusable library. at runtime, you dont need the sources. all you need in the war file are the javascript files and the class files. The javascript files have obfuscicated code by default and so i feel that they are more secure
ReplyDelete