We had the same problem a while back. First, we setup a continuous integration server (Hudson<http://hudson-ci.org/>) on one of our test machines. This would pull the latest code from our version control, build it and deploy it on tomcat automatically. We also setup a custom job on hudson that would just run GWTC and copy the files over to tomcat / webserver.
Next, we gave designers access to modify *.ui.xml, *.css and images on this machine. We gave them FTP access, but it could even be a shared folder. So the workflow became - 1. Make a change to *.ui.xml / *.css / images 2. Copy them over to test server 3. Run the hudson job (30s in our case) 4. Refresh browser Its slower than local development, but it made the designers independent of developers. That was a big win for us. --Sri On 7 April 2010 00:40, Graham J <[email protected]> wrote: > Hello, > > I appreciate the need for ClientBundle/ImageBundle/CssResource when an > application is deployed, but it seems like a huge hassle during > development. > > When using these techniques, every time an image is changed or a line > of CSS tweaked, the project has to be recompiled, or at the least, > restarted in dev mode. > > We are planning on contracting out a reskin of our site, and in order > to simplify the process, we have several folders of common resources > that will need to be altered. > > However, those resources are currently being loaded in via > ClientResource. This means that the designers won't be able to view > updated graphics and CSS on the site unless they have the source, and > eclipse, and the GWTDevmode Plugin, etc. etc. etc. > > Is there anyway to either: > 1) Continue using the ClientBundle for accessing resources, but have > it not perform any actual bundling on them, instead loading each asset > individually? or > 2) Recompile the bundles from a source folder at runtime without > having to recompile the whole app or run in dev mode? > > The goal in either case would be to allow the designers to upload > their changed CSS/image assets to a test site, refresh the page, and > see the changes reflected immediately, without ever having to have > access to the application itself, nor require effort from the > development team. > > Thanks, > Graham > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
