Thanks for the great answer.  With this final issue out of the way, I am 
ready to have my company jump into GWT with both feet!  

Even though we are a big Maven shop, I 100% agree that short-cycle 
rapid-development is an arena of the IDE, and not your build tool.  That 
said, we do make extensive use of Cargo to launch our own Jetty and Tomcat 
instances so that we can rapidly code-test-debug on the server side.  When 
we were doing Flex development, we would have the Flex Builder configured 
to drop the SWF/SWC files in the exploded WAR directory of these locally 
running servlet containers.  Sounds like we could do the same with GPE.

The key part that I was missing was adding the source directories to the 
classpath in the launcher.  The Google web application launcher 
documentation is rather sparse:

http://code.google.com/eclipse/docs/running_and_debugging_2_0.html

Whats a good resource to get schooled on this thing?

On Friday, December 9, 2011 2:59:45 PM UTC-5, Thomas Broyer wrote:
>
>
>
> On Friday, December 9, 2011 5:44:38 PM UTC+1, David Vree wrote:
>>
>> My team is currently converting a web-app to GWT and we would like to 
>> break our client code into at least 2 and maybe as many as 4 separate Maven 
>> modules/projects.
>>
>> When doing this is it possible to use development mode and allow hot code 
>> editing of the dependent modules?
>>
>
> Yes, absolutely. Not sure you can do it in a "Maven way" though (it looks 
> to me like Maven is not designed for such things; not that you cannot do 
> it, but it'll be a bit "hackish")
>
> Google provided me with the following links, but they seem to be 
>> inconclusive.  
>>
>>
>> http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users/browse_thread/thread/8d073905c5ec2663
>>
>> http://stackoverflow.com/questions/5236181/how-to-be-productive-in-a-gwt-maven-multi-module-project
>> http://jira.codehaus.org/browse/MGWT-76
>>
>> I am hoping somebody already does this and can provide some useful tips.
>>
>
> We're using Eclipse with m2e and the Google Plugin for Eclipse, and, in 
> addition to "resolving artifacts from the workspace", we just add each 
> project's source so the Eclipse launcher's classpath (yes, it has to be 
> done manually, but you can easily share the .launcher file between 
> computers, at least as a template).
>
> If you also have server-side classes in your modules, it becomes much more 
> trickier: I don't think there's another solution than running an external 
> servlet container, point it to your packaging=war project's 
> target/<final-name>, and add the other projects' target/classes to the 
> webapp extra-classpath. We have a *-context.xml file for Jetty 7 that does 
> just that; something like:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "
> http://www.eclipse.org/jetty/configure.dtd";>
> <Configure class="org.eclipse.jetty.webapp.WebAppContext">
>   <Set name="contextPath">/myapp</Set>
>   <Set name="baseResource">
>     <New class="org.eclipse.jetty.util.resource.ResourceCollection">
>       <Arg>
>         <Array type="java.lang.String">
>           <!-- load resources right from the src/main/webapp -->
>           <Item><SystemProperty 
> name="project.root"/>/project-webapp/src/main/webapp/</Item>
>           <!-- after a first build, or "mvn war:exploded", contains the 
> project-webapp's dependencies in the WEB-INF/lib -->
>           <Item><SystemProperty 
> name="project.root"/>/project-webapp/target/project-webapp-${project.version}/</Item>
>         </Array>
>       </Arg>
>     </New>
>   </Set>
>
>   <Set name="copyWebDir">false</Set>
>   <Set name="copyWebInf">false</Set>
>   <Set name="extractWAR">false</Set>
>   <Set name="defaultsDescriptor"><Property default="." 
> name="jetty.home"/>/etc/webdefault.xml</Set>
>
>   <!-- adds to the webapp's classpath each one of the dependencies' 
> target/classes folder -->
>   <Set name="extraClasspath"><SystemProperty 
> name="project.root"/>/project-webapp/target/classes/;<SystemProperty 
> name="project.root"/>/project-module1/target/classes/;<SystemProperty 
> name="project.root"/>/project-module2/target/classes/</Set>
> </Configure>
>
> And you launch your Jetty with -Dproject.root="" pointing to the location 
> of your maven parent folder (where all your modules live) and 
> -Dproject.version="" with your project's version (unless you configured the 
> final name of the project-webapp to *not* include the version).
> Eclipse will compile your java files into each project's target/classes, 
> which are in the extraClasspath of the webapp (just like if there were in 
> the webapp's WEB-INF/classes, or a JAR in WEb-INF/lib). To refresh the 
> server-side code, simply "touch" the context file and Jetty will reload it 
> (we setup Jetty to check for changes every second when developping; this is 
> done through a Maven profile in another project which packages everything 
> together, including some Jetty configuration files; but if you don't need 
> such things, just change the file manually in Jetty's configuration, on 
> each developer's computer)
>
> This is our setup for development and it works pretty well, for almost a 
> year now (we previously tried Eclipse WTP but had issues with it: it 
> sometimes failed to deploy some classes, or even JARs)
>
> In a few words: it requires a bit of time to setup everything in the 
> beginning, but then all you have to do is: launch your local Jetty, launch 
> the DevMode in "-noserver" from Eclipse. To debug the server-side code, 
> make sure you launch Jetty with the debug agent (you just have to uncomment 
> a line in the default start.ini file), and then connect to it from Eclipse 
> as if it's a "remote app".
>

-- 
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/-/wZQJG2WKAwMJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to