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 <[email protected]> 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 <[email protected]
>
> > 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 <[email protected]>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 <[email protected]>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 <[email protected]> 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 [email protected]
> >>> .
> >>> To unsubscribe from this group, send email to
> >>> [email protected]<google-web-toolkit%[email protected]>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/google-web-toolkit?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Google Web Toolkit" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]<google-web-toolkit%[email protected]>
> >> .
> >> 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 [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<google-web-toolkit%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
