That's pretty much the approach I use. I prefer to keep the war/ directory as minimal as possible in terms of what is in source control. I keep only the web.xml & app HTML page. By default the war/ directory gets added to ignore because that is where generated resources are placed. Instead I prefer to use ant to copy the necessary resources across during compilation. The downside is that you need to maintain Eclipse paths separately.
I find it's not a major issue as the project gets older, because paths don't tend to change. The problem does appear though if they do change, because after a while your developers will probably be using Eclipse exclusively, so they'll fix Eclipse and forget about ant (forgetting about Eclipse isn't that big a deal because your developers will notice it right away). On Sun, Apr 26, 2009 at 12:35 PM, Isaac Truett <[email protected]> wrote: > > Thanks. That is an interesting thread, although it seems to be > addressing a separate need: multiple classpath definitions, which I > think would be a big win for the GEP. > > I've been using multiple classpath definitions in my Ant build scripts > for years. Usually there's a runtime classpath with JDBC drivers, > maybe something from Apache Commons, and anything else I need to > deploy. There's also a dev classpath which includes everything on the > runtime classpath, plus libs that are only used during development or > are known to be provided by the app server (the core J2EE lib, for > example). This dev classpath has things that I need in order to > compile, test, etc., but that will not ultimately be deployed with the > app. With GWT applications, the dev classpath will also include any > client-only libraries (e.g., gwt-incubator.jar). Having all of this in > one classpath definition causes GEP to generate warnings. There's an > "ignore the fact that this won't be available on the server" feature > in GEP to remove these warnings, but I think turning that into a more > explicit runtime vs. dev configuration would be beneficial. Solving > the source control issue is then pretty simple: the plugin would copy > all static content, GWT compiler output, and anything on the runtime > classpath into a configurable exploded webapp dir where either the > bundled Jetty or an external ("-noserver") app server can serve the > app. I can check into source control any libraries that I choose and > reference the others as Eclipse libraries, classpath variables, etc. > > > > On Sat, Apr 25, 2009 at 10:45 PM, Allen Firstenberg <[email protected]> > wrote: > > > > There has also been some similar discussion in this thread: > > > http://groups.google.com/group/google-appengine-java/browse_thread/thread/67cb7cdaefc8429f?tvc=2 > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
