Re: Maven users survey
In case anyone on this thread missed the announcement, the Google Plugin for Eclipse 1.3 preview is now available: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/981bae88b387b2a6/468ca0d8e04532cb Keith On Tue, Mar 2, 2010 at 2:02 PM, bkbonner brian.bon...@paraware.com wrote: Cool. Thx On Mar 1, 2:56 pm, Keith Platfoot kplatf...@google.com wrote: We're working on integrating our last few changes today, so look for an announcement and download link sometime tomorrow or Wednesday. :-) Keith On Mon, Mar 1, 2010 at 2:46 PM, bkbonner brian.bon...@paraware.com wrote: Keith, any news on the plugin update? Brian On Feb 4, 2:33 pm, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installation http://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more
Re: Maven users survey
Cool. Thx On Mar 1, 2:56 pm, Keith Platfoot kplatf...@google.com wrote: We're working on integrating our last few changes today, so look for an announcement and download link sometime tomorrow or Wednesday. :-) Keith On Mon, Mar 1, 2010 at 2:46 PM, bkbonner brian.bon...@paraware.com wrote: Keith, any news on the plugin update? Brian On Feb 4, 2:33 pm, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and
Re: Maven users survey
Keith, any news on the plugin update? Brian On Feb 4, 2:33 pm, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when
Re: Maven users survey
We're working on integrating our last few changes today, so look for an announcement and download link sometime tomorrow or Wednesday. :-) Keith On Mon, Mar 1, 2010 at 2:46 PM, bkbonner brian.bon...@paraware.com wrote: Keith, any news on the plugin update? Brian On Feb 4, 2:33 pm, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App
Re: Maven users survey
Hi Keath, Great initiative, thank you for looking in to maven support !!! I'm using maven for some years now and introduced it at a number of companies... I can really recommend it, it's great to see google giving it more attention, please continue the good job! I just (last week) finished migrating our maven gwt projects from gwt 1.5 to 2.0. It turned out to be a challenge to get it right, but it seems almost everything is working as supposed to. (Just using mvn gwt:run isn't working at this time, might be a bug in our configuration...) What is the typical workflow of a GWT developer using Maven? - We create gwt projects from (our own) archetype. - Generate eclipse metadata/project files using mvn eclipse:m2eclipse (It's not clear if we need de -Dwtpversion=2.0) - During development in eclipse we use Run as Debug as Webapplication (so app runs in hosted browser / firefox + gwt plugin) - We use standard maven directory layout - We create war using a gwt profile in our pom (we use a profile so it won't build by default when eclipse triggers a build): mvn -Dgwt=true clean install - We package sources in our libraries so we can use them in our gwt apps Pain points: - After I compile my gwt project, there are lots (6000 of (html...etc) files created in target directory. The problem we are facing is that eclipse start validating these generated files and gets verry slow... - When launching my gwt app there is no longer a key shortcut available, I would like to use something like ctrl+alt+x G This used to work, but doesn't seem to work for latest plugin. - The war dir is verry painful, currently I don't use it during development. It is created by gwt-maven- plugin when I gwt compile my project to create a war. After this I delete it, so it can't cause any harm (sry, can't remember the exact problems is was causing at this time...) - Building our apps takes verry long (3 - 15 minutes). We would like to precompile our libraries before adding them to our artifactory. It would be nice if our gwt project won't compile these imported libraries, but could use precompiled versions... -In order for our projects to run in hosted browser, we need to add the servlet definitions to our gwt.xml file, but in our production (war) version these definitions shouldn't be there in order to run successfully: servlet class=org.springframework.web.context.support.HttpRequestHandlerServlet path=/services/user/personGwtService.gwt / As a workaround we use App.gwt.xml and App4HostedBrowser.gwt.xml. The 4HostedBrowser version inherits the App version and adds the servlets : (( - Currently when we try to use appengine it complains about not finding the file 'appengine-web.xml'. When I put this in src/main/webapp/WEB-INF/ it isn't found. It has to be in war/. - Documentation about where to put your sources, etc would be of great help... (libs needs sources...). When I migrated to gwt 2.0 I discovered class files for all my libs were placed in target/.../WEB- INF/classes but jars of these libse were in target/.../WEB-INF/lib so runtime these classes were found twice :( Causing spring to get confused about finding same class twice... - It would be nice if there was an easy way we could use something like mvn jetty:run after creating the gwt war Have fun, Raymond Domingo Telecats On Feb 5, 4:22 pm, Keith Platfoot kplatf...@google.com wrote: Hi Olivier, GPE 1.3 should be compatible with WTP/Eclipse EE. For example, you'll be able to easily add GWT and/or App Engine to an existing Dynamic Web Project, and then debug the application using the GPE Web Application launch configurations. For GWT projects that have a separate backend (e.g. an existing Tomcat or Jetty instance), you will be able to launch your GWT font-end in the existing server, so you can debug both client-side code and server-side code simultaneously. If you change your GWT code during a debugging session, you can refresh to get the updates immediately, and of course do the same for server-side code and static resources changes as well (if your server adapter supports it). Keith On Fri, Feb 5, 2010 at 3:17 AM, olivier nouguier olivier.nougu...@gmail.com wrote: Thx a lot for all this, it will clearly simplify GWT with Maven, but did you plan to add some WTP support in the next GEP release ? On Thu, Feb 4, 2010 at 8:33 PM, Keith Platfoot kplatf...@google.comwrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any*project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR
Re: Maven users survey
Keith, this sounds great! I look forward to the plugin drop. Maybe a News Noteworthy in the spirit of the other Eclipse modules would be helpful. It wasn't clear to me. Will this plugin release solve this issue: 1. Maven standard is using the src/test/java folder for test cases. Mvn eclipse:eclipse then generates this folder as a source folder. Since the GWTTestCase is not part of the user jar and is part of the dev jar when running the application from eclipse we always get the following error: 12:16:37.315 [ERROR] [] Line 12: No source code is available for type com.google.gwt.junit.client.GWTTestCase; did you forget to inherit a required module? Brian On Feb 4, 2:33 pm, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is
Re: Maven users survey
Hi Keith, Great great !!! In fact currently it may works but it is need some twix in the WTP metadata project file. BTW it a very comfortable environment, where it is easy and efficient to test general integration (WEB1 + WEB2). Very efficient, because you can choose or not to debug client/server part, so it can (re)start very quickly. The only small issue I have is that I have to add the extra gwt.codesvr parameter to use the dev mode, will it be still the case with GEP 1.3 or could we activate/force the usage of dev mode without altering the url ? Many many thx for GWT. Best regards, Olivier On Fri, Feb 5, 2010 at 4:22 PM, Keith Platfoot kplatf...@google.com wrote: Hi Olivier, GPE 1.3 should be compatible with WTP/Eclipse EE. For example, you'll be able to easily add GWT and/or App Engine to an existing Dynamic Web Project, and then debug the application using the GPE Web Application launch configurations. For GWT projects that have a separate backend (e.g. an existing Tomcat or Jetty instance), you will be able to launch your GWT font-end in the existing server, so you can debug both client-side code and server-side code simultaneously. If you change your GWT code during a debugging session, you can refresh to get the updates immediately, and of course do the same for server-side code and static resources changes as well (if your server adapter supports it). Keith On Fri, Feb 5, 2010 at 3:17 AM, olivier nouguier olivier.nougu...@gmail.com wrote: Thx a lot for all this, it will clearly simplify GWT with Maven, but did you plan to add some WTP support in the next GEP release ? On Thu, Feb 4, 2010 at 8:33 PM, Keith Platfoot kplatf...@google.comwrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any*project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input * and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.comwrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try
Re: Maven users survey
Thx a lot for all this, it will clearly simplify GWT with Maven, but did you plan to add some WTP support in the next GEP release ? On Thu, Feb 4, 2010 at 8:33 PM, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.comwrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for
Re: Maven users survey
Hi Olivier, GPE 1.3 should be compatible with WTP/Eclipse EE. For example, you'll be able to easily add GWT and/or App Engine to an existing Dynamic Web Project, and then debug the application using the GPE Web Application launch configurations. For GWT projects that have a separate backend (e.g. an existing Tomcat or Jetty instance), you will be able to launch your GWT font-end in the existing server, so you can debug both client-side code and server-side code simultaneously. If you change your GWT code during a debugging session, you can refresh to get the updates immediately, and of course do the same for server-side code and static resources changes as well (if your server adapter supports it). Keith On Fri, Feb 5, 2010 at 3:17 AM, olivier nouguier olivier.nougu...@gmail.com wrote: Thx a lot for all this, it will clearly simplify GWT with Maven, but did you plan to add some WTP support in the next GEP release ? On Thu, Feb 4, 2010 at 8:33 PM, Keith Platfoot kplatf...@google.comwrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any*project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input * and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.comwrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google
Re: Maven users survey
Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
And hopefully (Nir mentioned this prior), there will be a way to exclude a specific set of classes via some 'ant matcher' from the module. We keep the path the same and it looks like GWT looks at both directories and throws errors which I don't believe affect execution, but are confusing: Validating newly compiled units [ERROR] Errors in 'file:/C:/work/bigproject/src/test/java/com/ example/gwt/client/ui/SampleUiTest.java' [ERROR] Line 43: No source code is available for type org.mockito.Mockito; did you forget to inherit a required module? [ERROR] Line 48: No source code is available for type org.mockito.Matchers; did you forget to inherit a required module? In our module we have: source path=client/source source path=common/source where client holds the UI code and common holds DTO classes between the RPC Server and Client. The common is probably redundant to a dto package, but nevertheless. If I move my test out of the package specified by client, the error goes away. gwt compile or specify ant expressions for gwt compile. Our convention (and I believe a maven convention) is for test cases to exist in the src/test tree with the same path as the class under test in the tree: src/main. Hopefully that makes sense. Brian On Feb 4, 12:55 pm, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.com wrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and
Re: Maven users survey
Any improvements in GWT-Maven support from Google would be excellent! Google are 'maven friendly' :) THANKS KEITH AND OTHERS! I can't speak highly enough of Maven. It's an instant injection of mature engineering practices for projects and companies alike. It's a shame it has becoming increasingly difficult to work with GWT (2.0) in this (widely accepted) lifecycle manager / project config. If I was to give Google an example of what they're missing (not just for GWT) I'd ask them to please have a look at this: http://appfuse.org/display/APF/Home http://appfuse.org/display/APF/HomeCheers and looking forward to future :) p.s. thanks again Keith :) On Fri, Feb 5, 2010 at 6:03 AM, Keith Platfoot kplatf...@google.com wrote: Yes, I've been meaning to reply back to this thread. Thanks for reminding me, Brian! :-) Our plans for the next release of the Google Plugin for Eclipse (1.3) include 4 changes designed to make integration with Maven and J2EE projects easier: 1. The WAR directory can now be configured to be *any* project-relative path (e.g. src/main/webapp if you're using Maven). You'll also be able to specify whether that directory is source-only (typical Maven/J2EE scenario), or whether it should also function as the WAR output directory from which to run/debug or deploy to App Engine. If your WAR directory is input *and* output (which will remain the default for new Web App projects), the plugin will manage synchronizing the contents of WEB-INF/lib WEB-INF/classes with your project's build path and compiled output. Otherwise, we'll leave your WAR source directory alone and you'll need to specify your WAR output location when launching, deploying, etc (the plugin will remember the location once you set it the first time). 2. The Web App launch configuration UI is being redesigned to allow you to see, and if necessary change, *any* of the launch arguments. Previously, we were waiting until launch time to set many of these arguments based on heuristics that were invisible and inaccessible to you. Now you'll be in full control of how your projects get launched. Also, we're adding the capability to automatically migrate your launch configurations when necessary, for example, updating the -javaagent flag when changing App Engine SDKs. 3. GWT/App Engine projects will no longer require our SDK library on the classpath. This means Maven users will be able to pull in JAR files from their M2 repository as they're accustomed to and the plugin won't mind a bit. 4. The severity of any problem marker generated by the plugin will be fully customizable via an Errors/Warnings preference page (similar to the Java Errors/Warnings page), letting you specify either Error, Warning, or Ignore. We'll also be including a few smaller features and bug fixes as well. What does everyone think about the 4 changes outlined above? We've been testing the plugin against various Maven and J2EE configurations to try to ensure that we've eliminated the most critical roadblocks. However, we're very interested in also having you folks take it for a spin before the official release date (slated for next month). We're not quite ready yet, but stay tuned for a 1.3 preview build to be made available hopefully in a few weeks. We'll distribute it as a zip file for dropin installationhttp://code.google.com/eclipse/docs/install-from-zip.html so it will come with the standard warnings and caveats (use with a clean Eclipse install and workspace, use at your risk, etc.). However, it will hopefully give you a chance to give us any last-minute feedback about our changes before the final release. Thanks, Keith On Thu, Feb 4, 2010 at 12:55 PM, bkbonner brian.bon...@paraware.comwrote: Keith, are you going to give the folks who replied to your message some sort of thoughts on what you're going to implement and hopefully let us try it before you end up releasing the next release of the plugin? Brian On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a
Re: Maven users survey
Hi all, from the current version IMHO there are 2 issues. 1- layout issue (as you mention) src/main/webapp or equivalent must be input only. 2- classloader issues when using spring namespace handlers with DevMode. A working workaround is to work with WTP (without jetty server) and let WTP deploy the GWT generated stuff (JS). - I let maven share to same class output folder but I maintain the src/main/webapp in only: build outputDirectorywar/WEB-INF/classes/outputDirectory /build - I'm adding this in wtp deployement descriptor (.settings/org.eclipse.wst.common.component): wb-resource deploy-path=/search source-path=war/search/ In this case the GWT module is named search, and its GWT resources are deployed in WTP server, without polluing the src/main/webapp folder. Then: - the server side code must run under WTP. - the client side (GWT) code can: - run compiled under WTP - run not compiled with dev mode *without* jetty. - maven build process(gwt-maven-plugin:1.2) is not impacted. I'm working (on my free time) on a plugin to detect GWT module and customize the WTP descriptor without by-hand intervention on the .settings/org.eclipse.wst.common.component file. HIH On Wed, Jan 13, 2010 at 5:35 PM, Keith Platfoot kplatf...@google.comwrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- A coward is incapable of exhibiting love; it is the prerogative of the brave. -- Mohandas Gandhi -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at
Re: Maven users survey
Hi, From our perspective, we managed to get things working somewhat adequately as follows: 1. use maven for automated builds and awesome dependency management 2. use eclipse and maven eclipse plugin 3. use gwt and gae plugins (where SDK must point to the same versions as those declared in pom.xml) Our biggest challenge was the assumption that the war lives in a directory named war. We got around this on *ix by using a symbolic link to point to the actual build directory in target. The second issue was with the run configurations loading the hosted mode from a non-sdk directory due to the order JAR files are included. We got around this using the -Dappengine.sdk.root parameter. So for us the big wins: 1. better integration of gwt and gae SDKs with maven dependency management 2. flexibility to override all the parameters passed to the HostedMode launcher (in this case we could override -war) cowper On Jan 13, 8:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
On Tue, Jan 26, 2010 at 12:01 AM, cowper iamco...@gmail.com wrote: Hi, From our perspective, we managed to get things working somewhat adequately as follows: 1. use maven for automated builds and awesome dependency management 2. use eclipse and maven eclipse plugin 3. use gwt and gae plugins (where SDK must point to the same versions as those declared in pom.xml) Our biggest challenge was the assumption that the war lives in a directory named war. We got around this on *ix by using a symbolic link to point to the actual build directory in target. The second issue was with the run configurations loading the hosted mode from a non-sdk directory due to the order JAR files are included. We got around this using the -Dappengine.sdk.root parameter. So for us the big wins: 1. better integration of gwt and gae SDKs with maven dependency management 2. flexibility to override all the parameters passed to the HostedMode launcher (in this case we could override -war) For GPE 1.3, there will be no magic arguments in launch configurations. In other words, the program args and VM args will be explicitly listed in the launch configuration and you can modify them as you see fit. cowper On Jan 13, 8:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- Miguel -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hi Keith, Thanks for offering to help us maven users. I wish you guys did use maven :) On the development workstation, we use STS (for our purposes, Eclipse Ganymede with m2eclipse plugin). We use the Google Plugin for Eclipse for Development mode. We run development mode from the launch menu (by manually configuring an Eclipse Debug/Run configuration with the -- noserver mode set. For our continuous integration environment, we use Hudson and Maven 2.2.1. We compile our code with the Google Eclipse Plugin and copy our code over to src/main/webapp/app-name for debugging with our server. We use Tomcat as our dev server. I might like using Jetty, but there need to be more instructions for configuring the embedded Jetty in the Google Plugin for Eclipse. I think you are on the right track re: the impedance mismatch between Google Plugin for Eclipse (GWT) and Maven. Maven does typically look to src/main/webapp. We use org.codehaus.mojo gwt-maven-plugin as configured here: plugin groupIdorg.codehaus.mojo/groupId artifactIdgwt-maven-plugin/artifactId version1.2/version configuration inplacefalse/inplace runTargetindex.html/runTarget webXmlsrc/main/webapp/WEB-INF/web.xml/webXml logLevelINFO/logLevel warSourceDirectory/war/warSourceDirectory /configuration executions execution goals goalcompile/goal goalgenerateAsync/goal !-- goaltest/goal -- /goals /execution /executions /plugin Our project is a multi-module project with the GWT portion as a specific module dependent upon a backend module (which has services and DAOs). We have another module which handles a web services layer (separate from GWT). We copy our GWT code into src/main/webapp so it can be hosted by the WTP (m2 eclipse integration with Tomcat) We don't fire up Jetty. We launch Tomcat from Eclipse WTP (Debug On Server). To debug GWT, in development, we launch our app with --noserver and specify the startup URL to point to the WTP app. It connects to the GWT plugin debugger. Our front end testing leaves a lot to be desired. We're trying to use mvp and mocking to better test them. We don't have it working smoothly yet. Our build code for our WAR isn't really working well, yet either. I'm happy to do a webex/dimdim to show you what we have working (and not working). One thing I've noticed from the responses so far is that some folks use mvn eclipse:eclipse and others use m2eclipse (from sonatype). The sonatype piece seems to have better WTP integration and is part of the IAM project as I understand it. It seems more integrated if you use eclipse. The sonatype guys are the folks to talk to, specifically Jason Van Zyl and Eugene Kuleshov (http://www.sonatype.com/people/ category/m2eclipse/) I also agree with Nir Feldman's comments. I see these as well: 1. Maven standard is using the src/test/java folder for test cases. Mvn eclipse:eclipse then generates this folder as a source folder. Since the GWTTestCase is not part of the user jar and is part of the dev jar when running the application from eclipse we always get the following error: 12:16:37.315 [ERROR] [] Line 12: No source code is available for type com.google.gwt.junit.client.GWTTestCase; did you forget to inherit a required module? 2. Support for coverage reports. When using cobertura plugin the reports does not contain the GWTTestCase tests. Brian Bonner On Jan 13, 11:35 am, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run
Re: Maven users survey
6. In eclipse we just start Debug as Web application. (with all libraries manually copied into war/WEB-INF/lib) This is our main problem, and I don't think it is related to only maven builds. Instead of using the project's class path including references to other projects and external jars like any other Eclipse runner would do, Google's plugin decides to skip all of this and insists on using the jars in WEB-INF/lib. Quite against what I expected tbh, and the run configurations don't hint that either. What would really help us is for the plugin to use the class path as it is defined for the project, and not use the jars in WEB-INF/libs at all. This way, you can break your project up in modules which themselves are eclipse projects, so that you don't have to do a complete jar build and copy the results to the WEB-INF/lib dir of the GWT project, but instead can just keep working. This would help us develop more efficiently, and it would also be more 'correct' in the sense that there is no difference between what the project uses to compile and run. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
As a complement I like to say that when using noserver mode - using a classic WTP deployment approach for server side component - GEP in this case manage only the GWT (client) code In this case, it works perfectly as you expected. It is just the embedded jetty server classpath that doesn't fit. On Wed, Jan 20, 2010 at 6:04 PM, Eelco Hillenius eelco.hillen...@gmail.comwrote: 6. In eclipse we just start Debug as Web application. (with all libraries manually copied into war/WEB-INF/lib) This is our main problem, and I don't think it is related to only maven builds. Instead of using the project's class path including references to other projects and external jars like any other Eclipse runner would do, Google's plugin decides to skip all of this and insists on using the jars in WEB-INF/lib. Quite against what I expected tbh, and the run configurations don't hint that either. What would really help us is for the plugin to use the class path as it is defined for the project, and not use the jars in WEB-INF/libs at all. This way, you can break your project up in modules which themselves are eclipse projects, so that you don't have to do a complete jar build and copy the results to the WEB-INF/lib dir of the GWT project, but instead can just keep working. This would help us develop more efficiently, and it would also be more 'correct' in the sense that there is no difference between what the project uses to compile and run. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- A coward is incapable of exhibiting love; it is the prerogative of the brave. -- Mohandas Gandhi -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
On Wed, Jan 20, 2010 at 12:04 PM, Eelco Hillenius eelco.hillen...@gmail.com wrote: 6. In eclipse we just start Debug as Web application. (with all libraries manually copied into war/WEB-INF/lib) This is our main problem, and I don't think it is related to only maven builds. Instead of using the project's class path including references to other projects and external jars like any other Eclipse runner would do, Google's plugin decides to skip all of this and insists on using the jars in WEB-INF/lib. Quite against what I expected tbh, and the run configurations don't hint that either. What would really help us is for the plugin to use the class path as it is defined for the project, and not use the jars in WEB-INF/libs at all. This way, you can break your project up in modules which themselves are eclipse projects, so that you don't have to do a complete jar build and copy the results to the WEB-INF/lib dir of the GWT project, but instead can just keep working. This would help us develop more efficiently, and it would also be more 'correct' in the sense that there is no difference between what the project uses to compile and run. From a user perspective, you want dependent projects to be accounted for when using a Web App launch configuration. That is perfectly reasonable. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- Miguel -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hi We, at my work, use a different approach, than others I see mentioned here. Development: We are developers using eclipse and Intellij. Important for us is IDE indenpendent usage, so I have created a Launcher.java file which actually starts HostedMode.java with appropriate arguments. That way the setup in eclipse and Intellij is the same, as developing e.g a swing client. Build process. For the build process it self we use maven2, but do NOT use any gwt plugins. Our build consists of many jar files and war files. Everythings gets build by maven2 except for the UserInterface modules. Here we use the maven-antrun-plugin to wrap the build.xml, and still get the benefit of maven2 dependencies management. Actually it is working quite great for us. Our appliction sofar has lived for 1.5 years, and I expect the lifetime to be bigger than 7-10 years. (our previously strus app, sofar has been used for almost 10 years). comments are welcome! /Flemming On Wed, Jan 13, 2010 at 5:35 PM, Keith Platfoot kplatf...@google.comwrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . 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 google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
First of all I would like to thank You for taking time to address the issues which Maven users have. My comments might be slightly off topic since my project doesn't use Eclipse and the Google plugin for Eclipse but relies heavily on Maven, the wonderful gwt-maven-plugin (http:// mojo.codehaus.org/gwt-maven-plugin/) and Netbeans. I do not know what type of support You plan to add for Maven users but I think it would be nice if You provided Maven users with a plugin (something like gwt- maven-plugin, perhaps extending it) that could perform most (if not all) of the tasks that the Google plugin for Eclipse now performs for Eclipse users. This way You could attract more people that are not using Eclipse (but are using Maven) to the wonderful world of GWT. Now to answer the questions: - Create a new project? I think I created a Web application project using Maven and then manually added GWT support (the gwt-maven-plugin configuration). - Perform GWT compiles? GWT compiles are performed automatically during the project build (install) if the pom is configured properly. If needed the compile can be invoked with the goal gwt:compile - Debug with Eclipse? As I mentioned earlier I use Netbeans instead of Eclipse. For debugging the gwt-maven-plugin comes to the rescue. First you need to invoke the gwt:debug goal. It starts the GWT Development Mode which waits for a debugger to be attached. Then you just have to attach the Netbeans debugger to the port that was defined when the GWT Development Mode was started. Works like a charm. It also works works when You change some code save the .java file and reload in the browser (although not always). - Run your tests? Maven automatically runs tests as part of the build (if testing is not turned off). As Davis said most of the tests are pure JUnit tests. - Create a WAR for deployment? Maven automatically creates a War if it is so defined in the pom. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hi It's a great new - Create a new project? Just a maven process, I've never used the perhaps-existing maven-gwt-plugin archetype because I use very custom - Perform GWT compiles? With maven-gwt-plugin during packaging (clean install). Some time with GEP when I want to test integration with other JSP code. But IMHO when using spring the noserver mode is hightly preferable (classloader issues). - Debug with Eclipse? Simple Eclipse debug usage. With tomcat / WTP for server side code. - Run your tests? Maven - Create a WAR for deployment? Maven I've just commited my spring / security integration project where I encounter some classloading problem with the namespace handler of spring configuration file. IMHO this project is complicated enough to illustrate a GWT / WTP / Maven integration. http://code.google.com/p/orcades-gwt-spring/ There are two wiki pages to install test HIH On Wed, Jan 13, 2010 at 5:35 PM, Keith Platfoot kplatf...@google.comwrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- A coward is incapable of exhibiting love; it is the prerogative of the brave. -- Mohandas Gandhi -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
RE: Maven users survey
Some more stuff: 1. Maven standard is using the src/test/java folder for test cases. Mvn eclipse:eclipse then generates this folder as a source folder. Since the GWTTestCase is not part of the user jar and is part of the dev jar when running the application from eclipse we always get the following error: 12:16:37.315 [ERROR] [] Line 12: No source code is available for type com.google.gwt.junit.client.GWTTestCase; did you forget to inherit a required module? 2. Support for coverage reports. When using cobertura plugin the reports does not contain the GWTTestCase tests. 3. When compiling a GWT module the sources needs to be packaged as part of the jar. 4. There should be a gwt:eclipse plugin that will include the following features: a. Adding the generated sources (such as I18N ClientBundle) as a source folder in eclipse b. Adding the relevant natures to the project (depending if it is a module or a web application). Nir Feldman, HP Software From: google-web-toolkit@googlegroups.com [mailto:google-web-tool...@googlegroups.com] On Behalf Of Davis Ford Sent: Friday, January 15, 2010 2:55 AM To: google-web-toolkit@googlegroups.com Subject: Re: Maven users survey Hi Keith, this is fantastic that you are taking up this initiative. I built a GWT 1.7 app using maven and the codehaus plugin http://mojo.codehaus.org/gwt-maven-plugin/ There are a couple of different variants of maven gwt plugins, but the codehaus GWT plugin seems to be the best. That said, my pain points were more with the plugin documentation. I was able to get it to do everything I needed to after wrestling with it for a bit. The documentation isn't horrible, it is just lacking a few good examples. It does foce you to stray a bit from the maven webapp layout standard way of doing things, but I found this to not be a problem. I'm off working on something else non-GWT related, sadly, so I have not tried with GWT 2.0, but I know people are having success with it. Some good resources for you might be the codehaus plugin mailing list. http://mojo.codehaus.org/gwt-maven-plugin/mail-lists.html I've also got a couple of maven-ized GWT sample projects on my blog -- you can take a look at the pom.xml configuration of the GWT plugin. http://zenoconsulting.wikidot.com/blog:17 http://zenoconsulting.wikidot.com/blog:16 So, when I was developing a GWT app, I would almost always launch hosted mode via 'mvn gwt:run' -- and then do quick changes to the code/layout/css and refresh to see the changes. I tried not to use the debugger much, but when I did, I'd have to launch the app from w/in Eclipse using the GWT eclipse plugin in debug mode. The only downside to this is it took a really long time to compile and come up, but it worked. Unit testing was a no-brainer once I implemented all our code with MVP -- I was able to test 90% of all the UI logic this way with with pure JUnit tests -- not GWT tests...so this worked fine in Maven with CI (e.g. Hudson). Other standard stuff worked with maven: e.g. mvn package -- build war mvn clean install - clean, run tests, package, install war mvn eclipse:eclipse - create eclipse project that can be imported mvn jetty:run - run it in jetty mvn tomcat:run - run it in tomcat mvn cargo:deploy cargo:start - run it in container of choice configured via cargo plugin Hope that helps... Regards, Davis On Wed, Jan 13, 2010 at 11:35 AM, Keith Platfoot kplatf...@google.commailto:kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... * Create a new project? * Perform GWT compiles? * Debug with Eclipse? * Run your tests? * Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin
Re: Maven users survey
On Wed, Jan 13, 2010 at 5:35 PM, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to ... Great news. If you discover the way maven handles your dependencies you will never use ant again :) One thing however: Do not forget the people that use the App Engine for Java + GWT Plugin = Maybe it's better to talk to the App Engine Project and team up to provide a Maven based solution for both App Engine development and GWT development... Raphael -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hi Keith,
We are in the process of upgrading to GWT 2.0.0, so what our best
practices are is an interesting question right now, but here goes:
1. Our main pain point is the /war conundrum you spoke of.
- We configure the maven-war-plugin with webappDirectory${basedir}/
war/webappDirectory (new step that became required when we upgraded
to GWT 2.0.0 gwt-maven-plugin 1.2)
- We do this in both the single war and the multiple jar projects (see
#3 below)
2. We use Eclipse but not the GWT Eclipse plugin (haven't had time to
look at it yet)
- We build with 'mvn install' (includes gwt:compile), and generate
Eclipse project files with 'mvn eclipse:eclipse' goal
- We are able to remote debug in Eclipse using 'mvn gwt:debug' goal
3. In order to assemble a WAR file we define a maven war project that
assembles 3 separate GWT modules, each of which is defined in a maven
jar project.
- This might be a bit of an oddity in that each of the GWT module
*jar* projects includes a src/main/webapp folder that contains a
web.xml file.
That web.xml file is used only for gwt:run of the individual module.
- In order to gwt:run an individual module we must first 'mvn
war:explode' it (new step that became required when we upgraded to GWT
2.0.0 gwt-maven-plugin 1.2)
- A master web.xml file that supports all of the modules at once is
defined in war project src/main/webapp folder.
The master web.xml file works for both gwt:run of the assembled WAR,
and for when the WAR is bundled into an EAR for live deployment.
Cheers,
Dale
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hello, I know, this is GWT thread, but as I understand you are on Google Plugin for Eclipse team, so I assume, I can bother you regarding both GWT and GAE. The problem with gwt-maven-plugin is that when running GAE project locally, as described by other people above, GAE is not initialized and persistence doesn't work. Follow these instructions to create GAE project using maven-gae-plugin (http://maven-gae-plugin.googlecode.com): 1. Create project: mvn archetype:create -DarchetypeGroupId=net.kindleit - DarchetypeArtifactId=gae-archetype-gwt -DarchetypeVersion=0.5.0 - DgroupId=net.kindleit -DartifactId=maven-gae-example - DremoteRepositories=http://maven-gae-plugin.googlecode.com/svn/ repository Next commands must be run from project's root directory (type cd maven-gae-example) 2. download and unpack GAE SDK to your repository (You need to do this only once.. Also we are now working on automating this step): mvn gae:unpack 3. create Eclipse project files: mvn eclipse:eclipse After this you should be able to Import your project in Eclipse. The problem is that trying to enable Google Plugin for Eclipse on this project fails. If you'd manage to patch the Google Plugin, so everything works fine - all Maven users would be happy :) More commands: 4. building and running the project locally: mvn package gae:run (you can also use gae:debug instead of gae:run for running in debug mode) 5. deploying project to appspot: mvn gae:deploy P.S. I've also tried to set up project with war directory in project root, but run into some weird errors: http://groups.google.com/group/maven-gae-plugin/browse_thread/thread/497e2dd1ee252650 On Jan 13, 6:35 pm, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hello, I know, this is GWT thread, but as I understand you are on Google Plugin for Eclipse team, so I assume, I can bother you regarding both GWT and GAE. The problem with gwt-maven-plugin is that when running GAE project locally, as described by other people above, GAE is not initialized and persistence doesn't work. Follow these instructions to create GAE project using maven-gae-plugin (http://maven-gae-plugin.googlecode.com): 1. Create project: mvn archetype:create -DarchetypeGroupId=net.kindleit - DarchetypeArtifactId=gae-archetype-gwt -DarchetypeVersion=0.5.0 - DgroupId=net.kindleit -DartifactId=maven-gae-example - DremoteRepositories=http://maven-gae-plugin.googlecode.com/svn/ repository Next commands must be run from project's root directory (type cd maven-gae-example) 2. download and unpack GAE SDK to your repository (you need to do this only once.. also we are now working on automating this step): mvn gae:unpack 3. create Eclipse project files: mvn eclipse:eclipse After this you should be able to Import your project in Eclipse. The problem is that trying to enable Google Plugin for Eclipse on this project fails. If you'd manage to patch the Google Plugin, so everything works fine - all Maven users would be happy :) More commands: 4. building and running the project locally: mvn package gae:run (you can also use gae:debug instead of gae:run for running in debug mode) 5. deploying project to appspot: mvn gae:deploy P.S. I've also tried to set up project with war directory in project root, but run into some weird errors anyway: http://groups.google.com/group/maven-gae-plugin/browse_thread/thread/497e2dd1ee252650 On Jan 13, 6:35 pm, Keith Platfoot kplatf...@google.com wrote: Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Maven users survey
Hi Keith,
basically my issues re described here:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/de0941a7c657c8f0/cbbf6292588041f8?#cbbf6292588041f8.
1. We have gwt as a maven 2 project where you can find these plugins
in pom file. Plus dependencies to other modules(ommited)
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdgwt-maven-plugin/artifactId
version1.1/version
configuration
output${basedir}/war/output
logLevelINFO/logLevel
styleOBF/style
sourcesOnPathtrue/sourcesOnPath
extraJvmArgs-Xmx512m -Xss2048k/extraJvmArgs
runTargetProject.html/runTarget
modules
modulecom.project.Project/module
/modules
inlinetrue/inline
/configuration
executions
execution
goals
goalcompile/goal
!-- goalgenerateAsync/goal --
/goals
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
delete dir=${basedir}/src/webapp/
drguirpm /
delete dir=${basedir}/src/webapp/
gxt /
copy todir=${basedir}/src/webapp
fileset
dir=$
{project.build.directory}/${artifactId}-${version}
exclude name=*gwt-tmp//
exclude name=*-aux//
/fileset
fileset
dir=${basedir}/war
include name=gxt/** /
/fileset
/copy
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorsrc/main/assembly/assembly.xml/
descriptor
/descriptors
/configuration
executions
execution
idmake-assembly/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
/plugin
/plugins
2. We use m2eclipse plugin (http://m2eclipse.sonatype.org/update/)
3. For importing GWT project to eclipse I choose Import Maven project
in eclipse. I get project set up with all possible maven dependencies
etc.
4. I have to mark project as GWT Project. Properties-Google-Web
toolkit- Use google web toolkit. Then I can start project as GWT web
application. But with the result mentioned in my previous post.
5. We compile whole thing with maven 2, but as I said we are in phase
where we don't have some concrete routines for packing our GWT GUI
layer with our existing app(struts based). but I believe generated
pages and jar will be in the same web app package as other stuff - so
not as a special GWT web app.
6. In eclipse we just start Debug as Web application. (with all
libraries manually copied into war/WEB-INF/lib)
7. UNIT tests: We haven't come so far ;)
So far we learned gwt principles, we managed to integrate it with
spring, managed to integrate it into our existing struts GUI, managed
to build with maven etc. - so more like infrastructure tasks. Now we
want to use our existing modules with screens we created in GWT.
8. WAR for deployement: see 5.
So our major problem with GWT is that we have to copy all maven
dependencies manually to war/WEB-INF/lib in hosted mode. Quite a issue
for modules that changes quite often. Without this need, I believe, we
would consider GWT-maven integration as very good.
Hope you get an idea how do we work.
Regards,
milan
On Jan 13, 5:35 pm, Keith Platfoot kplatf...@google.com wrote:
Hi folks,
For the next release of the Google Plugin for Eclipse, we're planning on
making a few tweaks to make life easier for Maven users. That's right: we've
seen the stars on the issue tracker, and have decided it's time to act. I
Maven users survey
Hi folks, For the next release of the Google Plugin for Eclipse, we're planning on making a few tweaks to make life easier for Maven users. That's right: we've seen the stars on the issue tracker, and have decided it's time to act. I would say, we feel your pain, but the problem is, we don't. Which is to say, nobody on the plugin team actually uses Maven (everybody around here uses Ant). However, I've been researching Maven to determine exactly what changes we should make to allow it to work more seamlessly with the Google Eclipse Plugin. I've read the relevant issues and groups postings, so I think I have a rough idea of what needs to happen. However, before we go and make any changes, I wanted to ask for the community's advice. So, here are some questions for you. What is the typical workflow of a GWT developer using Maven? I've installed Maven and the gwt-maven-plugin 1.2-SNAPSHOT and managed to create a GWT 2.0 app with the provided archetype. After some tweaking, I'm able to GWT compile, debug with Eclipse (though not via our Web App launch configuration), create a WAR, etc. However, I'm more interested in how you all are doing things. For example: How do you... - Create a new project? - Perform GWT compiles? - Debug with Eclipse? - Run your tests? - Create a WAR for deployment? What specific pain points do Maven users run into when using the Google plugin? I know one major obstacle is that our plugin currently treats the war directory as both an input (e.g. static resources, WEB-INF/lib, WEB-INF/web.xml) and output (WEB-INF/classes, GWT artifacts like nocache.js and hosted.html) . Maven convention, however, says that /src/main/webapp should be input only, which means that hosted mode (or development mode, in GWT 2.0) needs to run from a staging directory (e.g. gwt:run creates a /war folder on demand). This mismatch results in the plugin creating spurious validation errors and breaks our Web App launch configuration. Another incompatibility is that Maven projects depend on the GWT Jars in the Maven repo, whereas our plugin expects to always find a GWT SDK library on the classpath. Are my descriptions of these pain points accurate? If so, one possible solution would be for the plugin to allow the definition of an input war directory (e.g. src/main/webapp) separate from a launch-time staging directory, and for us to relax the requirement that all GWT projects must have a GWT SDK library. So tell me: would these changes adequately reduce the friction between Maven and the Google plugin? Also, are there other problems Maven users are running into when using the plugin? Thanks in advance for all feedback, Keith, on behalf of the Google Plugin for Eclipse team -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
