I want to setup GWT in a special mode. I only use GWT for the client side as a replacement for having to deal with JavaScript directly.
The idea is to produce a single JS file.
Since this is also part of a bigger project with multiple project pages I got a problem where to put the output of the compiler and how to setup.
The ideal setup would be placing the GWT stuff into a single project and incooperate the ouput in a different project. The question is how to do it?
Update:
The current plan is to compile the JavaScript out of GWT using a simple Java application just issuing the GWT compile command and taking the Eclipse auto-build classes as necessary input. After the sources are compiled to java script the application copies the js files (one for every supported browser) to the related destination. This way the once created js files stay static and other developers do not have to deal with GWT related build tasks and we just avoid a necessary maven fight to get things working on build.
Also the GWT project can now depend on the web project making it possible to start the web application and alter its behaviour by adding support to host mode debugging.
Does anyone know a working example?
The easiest way, if you build a WAR in the end, is to put the output of GWT in a WAR too that you can use an an overlay in the final WAR module.
Other Maven plugins could do the trick too (dependency:unpack, maven-shade-plugin, etc.)
See https://github.com/tbroyer/gwt-maven-archetypes for examples.
Related
I need advice on how to structure a multi-tier GWT/Spring project so that Gradle can build the artifacts and deploy the correct jars..
Google hasn’t helped much – I can find a number of articles on building multi-projects and indeed building GWT project in Gradle however, all of these seem incomplete for my problem domain as I’m finding the following problems as I have encountered the following issues.
In the multi-project examples, the GWT dependencies are being included in the web-application from the war plug-in.
If I go down the single gradle build route then I’m losing decoupling with the projects..
Both the client & Server have dependencies on certain class files (for GWT-RPC); currently these are packaged in the client project so has resulted, again, in a server dependency on the client (for the GWT-RPC DTO objects).. This leads me to feel I need a third module exclusively for the shared class files with the source being also present in the gwt-client project (for the GWT compiler to pick these up)..
So; the question is has anyone came across a multi-tier GWT examples that uses Gradle as the build tool & deals with some/all of the above issues?
Thanks in advance,
Ian.
We're using a single build, but we address point #2 - "coupling of projects" using the Classcycle maven dependency plugin.
Ultimately, you want three genres of code: server, client and shared. The advantage of packaging those separately in separate jars (as you said in point #3) is that your server jar size will be decreased, and you could use more liberal source directories in your .gwt.xml file.
If you decide to use a single jar/war, then you will be including the extra, unused client classes on the server. This could lead to runtime exceptions from code leakage and (potentially?) worse performance on the server. We avoid the runtime exceptions by enforcing the layering separation at build time (using Classcycle), and the extra performance overhead from the extra client classes should be marginal. You can always strip out the client code from the jar after compile, using a post-build task.
Sorry, I don't know much about gradle, but I figured I would try to help anyways.
I just installed the Google Eclipse plugin and created my first test Web Application Project (using both GWT and GAE SDKs). The plugin autogenerated a project that had a war/ directory in it that had some peculiar subdirectories and files in it. An online search for many of these only returned other similar autogenerations of them but without any real explanation of what they are, or what they do:
war/WEB-INF/deploy/<myapp>/rpcPolicyManifest/**
war/WEB-INF/deploy/<myapp>/symbolMaps/**
war/<myapp>/symbolmanifest.json
gwt-unitCache/**
I'm also a litte confused about what the proper structure should be for a GWT WAR that is going to be deployed to GAE. What content should be packaged under war/WEB-INF/? What content should be packaged under the war/ root? Any other special considerations for GWT/GAE WARs? Thanks in advance!
Almost everything in the war/ folder is deployed to GAE. With the exception of temp-files that are used by the plugin, such as war/WEB-INF/appengine-generated/
The war/WEB-INF/ folder contains things needed to set up the GAE. This includes GAE settings for servlets, queues, logging, RPC etc. It also includes libraries that are used server-side and some GWT-mappings.
Note that the GWT libraries only are needed at compile-time and not on the server. You can put all GWT libraries in a lib/ folder outside of war/.
war/WEB-INF/deploy/<myapp>/rpcPolicyManifest/**
RPC is used to call server-methods directly from GWT-code. GWT/GAE is designed to allow RPC out-of-the-box. My guess is that the existence of a RPC policy manifest file is enough to configure GAE to allow the GWT code to use RPC, so they just put it there so you don't have to worry about it.
war/WEB-INF/deploy/<myapp>/symbolMaps/**
The plugin automatically adds the things needed here, so you don't have touch it. But the symbolMaps appear to be a dictionary used by GWT to supply different version of the app based on browser version. The first few lines in one of my symbolMap files read like this:
# { 1 }
# { 'user.agent' : 'gecko1_8' }
# jsName, jsniIdent, className, memberName, sourceUri, sourceLine
Duration,,com.google.gwt.core.client.Duration,,jar:file:/opt/eclipse/plugins/com.google.gwt.eclipse.sdkbundle_2.4.0.v201208080121-rel-r42/gwt-2.4.0/gwt-user.jar!/com/google/gwt/core/client/Duration.java,21
Which specifies how the JavaScript symbol 'Duration' should be interpreted, given that the user agent is gecko 1.8. Each browser-compilation (FF, Opera, Safari, IE etc.) has it's own mapping, allowing for browser-specific optimizations by the GWT compiler.
war/<myapp>/symbolmanifest.json
I don't have this file in my project, but it's probably related to the GWT symbol maps mentioned above. My guess is that it defines the JavaScript symbols that the GWT app uses. If you post a snippet from it we'll be able to see if this is the case.
gwt-unitCache/**
This is a cache-folder that is only used during development. See the release notes for GWT 2.4.0:
Persistent Unit Cache: GWT Compiler and Development mode now cache
compilation artifacts between runs. This results in faster startup
time for iterative development.
Is it possible to use the Guava libraries on a project done with both GWT and Google AppEngine?
I see that the individual jars (the standard Java one and the GWT compatible one) have the same package naming hierarchy. How do these integrate in a GWT+AppEngine projecT?
Yes it is possible. A few Guava classes won't be usable on AppEngine because of the restricted sandbox your app will run in, especially those in the .io package like Files (you will be able to read stuff but not write it).
Are you worried about deploying both jar files and having a conflict? If so, I think it will be fine - when you compile your GWT application, it turns into javascript, so you wouldn't necessarily be deploying the GWT compatible jar, just the normal one.
There won't be any conflict as the gwt one will be used by true DevMode client-side and the GWT compiler, the "normal " one will live in your WEB-INF/lib and be loaded (in DevMode) in a different classloader. It thus depends entirely on your project and build setup.
That being said I never tried it within the same Eclipse project. I always use distinct client and server projects, and -noserver in DevMode.
I use a library which includes, among other things, a servlet. I've fetched the source for this lib to a dynamic web project and it works fine.
I'd like to make an example dynamic web application in another project which would just reference to the classes of this library. Is it possible to do it this way in Eclipse Galileo and deploy to Tomcat.
This I like to do, so that in the library source project I have only the libs own code and my modifications to it and my example app would be a totally another app.
In Eclipse I've referenced my example app project to the lib project and it works fine when coding, but when I try to access the example app URL it throws a ServletException because it can't find the Servlet.
The libs own web page works fine.
Can you not just create a JAR containing the classes you which to share and then reference this JAR in each project?
I would recommend staying away from IDE features like the ones in Eclipse that try to bundle up your app and deploy it for you - I find it helps much more to control this yourself, with your own build scripts, app server setup, etc.
This way you aren't stuck wondering why a certain nuance of the IDE works the way it does (such as, why is Eclipse not deploying the output of a project I've added as a "reference" along with this project?) - you can completely control your own environment. It's more valuable to know how to bundle up and deploy things on your own anyway (since it works the same regardless of whatever IDE you are using), and the tools behind it are a lot more powerful than any "press this shiny button and everything gets deployed and launched" feature in your IDE.
I have recently joined a project that is using multiple different projects. A lot of these projects are depending on each other, using JAR files of the other project included in a library, so anytime you change one project, you have to then know which other projest use it and update them too. I would like to make this much easier, and was thinking about merging all this java code into one project in seperate packages. Is it possible to do this and then deploy only some of the packages in a jar. I would like to not deploy only part of it but have been sassked if this is possible.
Is there a better way to handle this?
Approach 1: Using Hudson
If you use a continuous integration server like Hudson, then you can configure upstream/downstream projects (see Terminology).
A project can have one or several downstream projcets. The downstream projects are added to the build queue if the current project is built successfully. It is possible to setup that it should add the downstream project to the call queue even if the current project is unstable (default is off).
What this means is, if someone checks in some code into one project, at least you would get early warning if it broke other builds.
Approach 2: Using Maven
If the projects are not too complex, then perhaps you could create a main project, and make these sub-projects child modules of this project. However, mangling a project into a form that Maven likes can be quite tricky.
If you use Eclipse (or any decent IDE) you can just make one project depend on another, and supply that configuration aspect in your SVN, and assume checkouts in your build scripts.
Note that if one project depends on a certain version of another project, the Jar file is a far simpler way to manage this. A major refactoring could immediately means lots of work in all the other projects to fix things, whereas you could just drop the new jar in to each project as required and do the migration work then.
I guess it probably all depends on the specific project, but I think I would keep all the projects separate. This help keep the whole system loosely coupled. You can use a tool such as maven to help manage all the dependencies between the projects. Managing dependencies like this is one of maven's main strengths.
Using Ant as your build tool, you can package your project any way that you want. However, leaving parts of your code out of the distribution seems like it would be error prone; you might accidentally leave out necessary classes (presumably, all of your classes are necessary).
In relation to keeping your code in different projects, I have a loose guideline. Keep the code that changes together in the same project and package it in its own jar file. This works best when some of your code can be broken out into utility libraries that change less frequently than your main application.
For example, you might have an application where you've generated web service client classes from a web service WSDL (using something like the Axis library). The web service interface will likely change infrequently, so you don't want to have the regeneration step reoccurring all the time in your main application build. Create a separate project for this piece so that you only have to recreate the web service client classes when the WSDL changes. Create a separate jar and use it in your main application. This style also allows other projects to reuse these utility modules.
When following this style, you should place a version number in the jar manifest so that you can keep track of which applications are using which versions of your module. Depending on how far you want to take this, you could also keep a text file in the jar that details the changes that have occurred for each revision (much like an open source library).
It's all possible (we had the same situation some years ago). How hard or easy it'll be depends on your IDE (refactoring, merging, organizing new project) and you build tool (deploying). We used IDEA as IDE and Ant as build tool and it wasn't too hard. One sunday (nobody working+committing), 2 people on one computer.
I'm not sure what you mean by
"deploy only some of the packages in a jar"
I think you will need all of them at runtime, won't you? As I understood they depend on each other.