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 <[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]<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].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to