Announcing GWT 2.1

[David Chandler]

GWT 2.1 is here!

http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release-of-gwt-21.html

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/

[Christian Goudreau]

Hell yeah !

Good work !

Cheers,

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Christian Goudreau

www.arcbees.com

[Travis Camechis]

AWESOME!!!!

[Christian Goudreau]

How come do I get this message ? The doc hasn't changed about MenuBar, even content assist of eclipse propose MenuItem inside MenuBar.

Widget com.google.gwt.user.client.ui.MenuItem is not a subclass of GWTs Widget class

Cheers,

[Christian Goudreau]

Btw, it seem to be an eclipse plugin problem... Since I can run the app even with those ... 30 errors. It's kinda anoying though.

Cheers,

--
Christian Goudreau

www.arcbees.com

[Travis Camechis]

might be one a similar to a problem I had where you get a pile of errors but they didn't really effect anything.  Turned out it was something with the GWT-USER.jar that came with eclipse plugin.  Swapped it out with one from maven and all the errors went away.

[David Chandler]

sounds like http://code.google.com/p/google-web-toolkit/issues/detail?id=5503

Please follow up on the bug tracker with more info. Are you seeing
this in hosted mode, full compile, or Google Plugin for Eclipse?

Thank you,

/dmc

On Thu, Oct 28, 2010 at 2:42 PM, Christian Goudreau

[Christian Goudreau]

Yeah that was my issue, but no need to come back to RC1, we just have to ignore it.

Cheers,

[tim.m...@gmail.com]

This is very exciting news.

I think I've run into a small obstacle that maybe someone could help
with. Upon updating my maven build dependencies for gwt, my build now
errors on com.google.gwt:gwt-soyc-vis:jar:2.1.0 not found in the maven
central repo. Is this something I'm doing incorrectly?

Congratulations on the release!
Tim Mecklem

On Oct 28, 2:12 pm, David Chandler <drfibona...@google.com> wrote:
> GWT 2.1 is here!
>

> http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...

[David Chandler]

Correct. This is only an issue with Google Plugin for Eclipse. Sorry
for the inconvenience.

/dmc

On Thu, Oct 28, 2010 at 3:08 PM, Christian Goudreau

[David Chandler]

Hi Tim,

gwt-soyc-vis.jar is intentionally not in the maven repo because all
the functionality has been moved into gwt-dev.jar. You should be able
to remove the dependency on gwt-soyc-vis from your POM.

Thank you,
/dmc

> --
> 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-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--

[tim.m...@gmail.com]

Thanks for your quick response! I needed to update the gwt-maven-
plugin version which was previously pointing to a version that
expected gwt-soyc-vis.

On Oct 28, 3:45 pm, David Chandler <drfibona...@google.com> wrote:
> Hi Tim,
>
> gwt-soyc-vis.jar is intentionally not in the maven repo because all
> the functionality has been moved into gwt-dev.jar. You should be able
> to remove the dependency on gwt-soyc-vis from your POM.
>
> Thank you,
> /dmc
>

> On Thu, Oct 28, 2010 at 3:31 PM, tim.meck...@gmail.com

>
>
>
> <tim.meck...@gmail.com> wrote:
> > This is very exciting news.
>
> > I think I've run into a small obstacle that maybe someone could help
> > with. Upon updating my maven build dependencies for gwt, my build now
> > errors on com.google.gwt:gwt-soyc-vis:jar:2.1.0 not found in the maven
> > central repo. Is this something I'm doing incorrectly?
>
> > Congratulations on the release!
> > Tim Mecklem
>
> > On Oct 28, 2:12 pm, David Chandler <drfibona...@google.com> wrote:
> >> GWT 2.1 is here!
>
> >>http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...
>
> >> --
> >> David Chandler
> >> Developer Programs Engineer, Google Web Toolkithttp://googlewebtoolkit.blogspot.com/
>
> > --
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.

[David Chandler]

You're welcome, Tim. Thanks for posting back.

/dmc

> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Giuseppe La Scaleia]

Hi all ,
great work. A simple question i have my maven project with gwt-maven-plugin 1.2 version. I have upload to gwt 2.1.0 and for plugin at version 1.3.2.google but i have the follow error

You're project declares dependency on gwt-user 2.1.0. This plugin is designed for version 2.1-SNAPSHOT
java.lang.NullPointerException
    at org.codehaus.mojo.gwt.AbstractGwtMojo.getClasspath(AbstractGwtMojo.java:220)
    at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo$JavaCommand.withinScope(AbstractGwtShellMojo.java:284)
    at org.codehaus.mojo.gwt.shell.CompileMojo.compile(CompileMojo.java:186)
    at org.codehaus.mojo.gwt.shell.CompileMojo.doExecute(CompileMojo.java:178)
    at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMojo.java:118)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

What version must i use??
Thanks Giuseppe

2010/10/28 David Chandler <drfib...@google.com>

--
Giuseppe La Scaleia
CNR - IMAA
geoSDI - NSDI
Sviluppo Software

C.da S. Loja
85050  Tito Scalo - POTENZA (PZ)
Italia

phone:  +39 0971427305
fax:      +39 0971 427271
mob:    +39 3804697436
mail:     giuseppe....@geosdi.org
skype:  glascaleia

web:     http://www.geosdi.org
 

[arriv...@gmail.com]

Hi Giuseppe,

I had a similar problems, and found out that late that my browser
(i.e. chrome) had cache the previous info, try to clean the temp data
in the browser.

Also, check which GWT version you specified within your plugin
reference in pom.xml. Here is my example pom.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3.2.google</version>
<configuration>
<logLevel>INFO</logLevel>
<style>PRETTY</style>
<gwtVersion>${gwt.version}</gwtVersion>
<webappDirectory>${basedir}/war</webappDirectory>
<module>${project.groupId}.isearch.ISearch</module>
<runTarget>ISearch.jsp</runTarget>
<copyWebapp>true</copyWebapp>
</configuration>
<executions>
<execution>
<id>gwtcompile</id>
<phase>prepare-package</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</plugin>

Hope this helps.

Also, thank you so much for your hard work!! I had a question on
google's "gwt-maven-plugin." First, is there documentation available
for the different configuration available? I have questions on the
function for <hostedWebapp>, <webappDirectory>, <copyWebapp>? Thank
you again~!

Jay

On Oct 29, 6:02 am, Giuseppe La Scaleia

> 2010/10/28 David Chandler <drfibona...@google.com>

>
>
>
> > You're welcome, Tim. Thanks for posting back.
>
> > /dmc
>

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

> > >> > For more options, visit this group athttp://
> > groups.google.com/group/google-web-toolkit?hl=en.
>

> > >> --
> > >> David Chandler
> > >> Developer Programs Engineer, Google Web Toolkithttp://
> > googlewebtoolkit.blogspot.com/
>
> > > --
> > > 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-we...@googlegroups.com
> > .
> > > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

> > > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> > --
> > David Chandler
> > Developer Programs Engineer, Google Web Toolkit
> >http://googlewebtoolkit.blogspot.com/
>
> > --
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> --
> Giuseppe La Scaleia
> CNR - IMAA
> geoSDI - NSDI
> Sviluppo Software
>
> C.da S. Loja
> 85050  Tito Scalo - POTENZA (PZ)
> Italia
>
> phone:  +39 0971427305
> fax:      +39 0971 427271
> mob:    +39 3804697436

> mail:     giuseppe.lascal...@geosdi.org

[Giuseppe La Scaleia]

Thanks for replay , it works now.
Best regards Giuseppe La Scaleia

2010/10/29 arriv...@gmail.com <arriv...@gmail.com>

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Giuseppe La Scaleia
CNR - IMAA
geoSDI - NSDI
Sviluppo Software

C.da S. Loja
85050  Tito Scalo - POTENZA (PZ)
Italia

phone:  +39 0971427305
fax:      +39 0971 427271
mob:    +39 3804697436

mail:     giuseppe....@geosdi.org

[David Chandler]

Hi arrival123,

Google's gwt-maven-plugin is actually just a temporary fork of the
Codehaus gwt-maven-plugin. Configuration should be the same as
http://mojo.codehaus.org/gwt-maven-plugin-1.2/plugin-info.html. We
plan to contribute back the changes shortly.

/dmc

> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Thomas Broyer]

On 29 oct, 17:19, David Chandler <drfibona...@google.com> wrote:
> Hi arrival123,
>
> Google's gwt-maven-plugin is actually just a temporary fork of the

> Codehaus gwt-maven-plugin. Configuration should be the same ashttp://mojo.codehaus.org/gwt-maven-plugin-1.2/plugin-info.html. We

> plan to contribute back the changes shortly.

Could you expand a bit on the changes you made? if I only use it for
gwt:compile (using Eclipse with the GPE for DevMode), and possibly
unit tests, without AppEngine, do I *need* the Google version? or
could I use the Codehaus one just as well?

[Alejandro D. Garin]

Hi,

The Cell Widgets documentation at:

http://code.google.com/webtoolkit/doc/latest/DevGuideUiCellWidgets.html

at the bottom say:

To Update Data Range Changes from a Cell Widget:

1. Create a subclass of AsyncListViewAdapter.
2. Implement onRangeChanged(HasData display).
   1. Get the current range from the display
   2. Request the data from the server or data source
3. When the data is returned, call updateRowData() to push the data to the widgets

but AsyncListViewAdapter has been renamed to AsyncDataProvider, right?

[gcstang]

Excellent work! Some very nice changes.

Upon reading the documents I see that RPC has been replaced with the
RequestFactory will the old RPC's still work or does this mean that I
have to rebuild my whole project?

On Oct 29, 2:02 pm, "Alejandro D. Garin" <aga...@gmail.com> wrote:
> Hi,
>
> The Cell Widgets documentation at:
>
> http://code.google.com/webtoolkit/doc/latest/DevGuideUiCellWidgets.html
>
> at the bottom say:
>

> *To Update Data Range Changes from a Cell Widget:*
>
>    1. Create a subclass of
> AsyncListViewAdapter<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>
>    .
>    2. Implement onRangeChanged(HasData
> display)<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>
>    .
>       1. Get the current range from the display
>       2. Request the data from the server or data source
>    3. When the data is returned, call updateRowData()
> <http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>to

>    push the data to the widgets
>

> but AsyncListViewAdapte<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>r

> has been renamed to AsyncDataProvider, right?
>

> On Thu, Oct 28, 2010 at 3:12 PM, David Chandler <drfibona...@google.com>wrote:
>
> > GWT 2.1 is here!
>

> >http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...

>
> > --
> > David Chandler
> > Developer Programs Engineer, Google Web Toolkit
> >http://googlewebtoolkit.blogspot.com/
>
> > --
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[Subhrajyoti Moitra]

" RequestFactory does not use GWT-RPC and is not intended to replace it. It is designed specifically for implementing a persistence layer on both client and server. "

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Jeff Schwartz]

I haven't read up in detail on the new RequestFactory implementation except for the information I've read here on the group. I gather from what I've read then that RequestFactory is totally data specific and its only intention is to persist any data that has been changed on the client back to the server. It therefore seems, for example, that if it were required for security reasons, for instance, to validate that the request to the server is made with a valid session id and the session was still active that RequestFactory would not be the api to use and that instead the older RemoteService api would be the one to use, correct?

If my assumption is true are there any plans to incorporate security into RequestFactory in a future release? Factoring security into RequestFactory for this common use-case would be a good addition IMHO.

Jeff

--
Jeff

[Thomas Broyer]

On 30 oct, 16:44, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> I haven't read up in detail on the new RequestFactory implementation except
> for the information I've read here on the group. I gather from what I've
> read then that RequestFactory is totally data specific and its only
> intention is to persist any data that has been changed on the client back to
> the server. It therefore seems, for example, that if it were required for
> security reasons, for instance, to validate that the request to the server
> is made with a valid session id and the session was still active that
> RequestFactory would not be the api to use and that instead the older
> RemoteService api would be the one to use, correct?

No.

The first thing the RequestFactoryServlet does is to (paraphrasing the
comment in the code) "check that user is logged in before
proceeding" (this is done by "getting" a UserInformation instance,
which has access to the servlet request through
RequestFactoryServlet.getThreadLocalRequest() so you're free to do
whatever checking you want; the actual implementation is given by the
userInfoClass servlet init parameter; see the Expenses sample for an
example using AppEngine's UserService), and return a 401 HTTP response
if it's not the case (which you can trap on the client-side).

On the client-side, RequestFactory uses by default a
DefaultRequestTransport, which you can extend (or even replace, I
think you could use WebSocket or Comet or whatever if you liked) to
send the "session id" in the request payload (for instance); similar
to the RpcRequestBuilder for GWT-RPC.

[Jeff Schwartz]

Excellent! Thank you for the information. I still however have to wait until support for DAOs & embeded objects is implemented in the MVP framework (I am using Objectify for my ORM as well ass a DAO) before I can cut over.

I am also concerned about the apparent reliance on Roo to generate the boilerplate code. It appears that Google is very much behind this combo. It isn't that I have anything against Roo, DI or generated code for that matter but I would have preferred a leaner solution. Applications targeting App Engine already experience enough latency on start-up and I am afraid that DI will just make matters worse; and as I still haven't been able to figure out how to get Roo and Objectify to work together my apprehension is that much more intensified.

But I am open minder. We developers have to be :) and as such I would very much like to be proven wrong on all these counts.

Again, thank you for the information on RequestFactory.

Jeff  

This is indeed great news.

--

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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

[Thomas Broyer]

On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Excellent! Thank you for the information. I still however have to wait until
> support for DAOs & embeded objects is implemented in the MVP framework (I am
> using Objectify for my ORM as well ass a DAO) before I can cut over.
>
> I am also concerned about the apparent reliance on Roo to generate the
> boilerplate code. It appears that Google is very much behind this combo.

We've been prototyping with RequestFactory for months and haven't ever
used Roo (our backend is Morphia+MongoDB, not too far from Objectify)

> It
> isn't that I have anything against Roo, DI or generated code for that matter
> but I would have preferred a leaner solution.

AFAIK, Roo is only a dev tool to generate and maintain boilerplate
code. There's nothing related to Roo in the generated code (have a
look at the Expenses sample, the domain objects and all Scaffold*
classes are those generated by Roo).

RequestFactory goes against DRY as you have interfaces extending
EntityProxy on the client-side, and "whatever" on the server-side; but
it's lighter weight than e.g. GWT-RPC at runtime: lighter payload
going on the wire (in most cases, and particularly on "upload"), and
much much lighter and faster on the client-side as parsing the payload
is just a matter of JSON.parse()

> Applications targeting App
> Engine already experience enough latency on start-up and I am afraid that DI
> will just make matters worse;

Huh!?!

Could you explain to me how DI slows things down? It's merely about
moving the place where you "new" objects, I don't see where there'd be
overhead re. start-up time.
Noteworthy: Roo generates GWT apps that use GIN for DI on the client
side, but there's no DI at all on the server-side. And DI is
absolutely not a requirement; only a best practice (that I'd encourage
*anyone* to follow)

[Jeff Schwartz]

Thomas,

It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on App Engine server cpu cycles are severely restricted by numerous quotas; the penalty for exceeding them cause cascading conditions of failure. If you aren't familiar with App Engine hosting and its quotas perhaps you should read up on it.

As for ROO not generating server side DI as part of its tooling in STS when used with GWT I will have to check that out for myself; I believe I had read that it generates a server side application context configuration file and if that is the case then I'd like to know why it would do that if DI wasn't employed on the server. If that is the case then DI would certainly cause heightened latency causing an increase in 500 errors on App Engine virtual server cold starts.

As for DI being a best practice (that you'd encourage *anyone* to follow) well that is your opinion that is not shared by everyone. I encourage a more conservative approach to any engineering problem - use the right set of tools at the right time.

As for Huh!?! That is something best saved for your friends on Facebook. This is a technical news group where such antics of conversation are not appreciated regardless of difference of opinion.

Jeff 

--

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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

[Duong BaTien]

Hi:

Good to know your experience with Roo and the light weight approach.

A best-practiced example of RequestFactory with GIN at GWT side and
GUICE at server side may be what a mortal developer is looking for. It
is even better with Objectify if Jeff does it.

Thanks
BaTien

[Arthur Kalmenson]

Great job, you guys rock!

--
Arthur Kalmenson

On Thu, Oct 28, 2010 at 2:12 PM, David Chandler <drfib...@google.com> wrote:
> GWT 2.1 is here!
>

> http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release-of-gwt-21.html

>
> --
> David Chandler
> Developer Programs Engineer, Google Web Toolkit
> http://googlewebtoolkit.blogspot.com/
>

[Thomas Broyer]

On 31 oct, 13:40, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Thomas,
>
> It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on
> App Engine server cpu cycles are severely restricted by numerous quotas; the
> penalty for exceeding them cause cascading conditions of failure. If you
> aren't familiar with App Engine hosting and its quotas perhaps you should
> read up on it.

I never used AppEngine so I apologies for not knowing the quotas and
what impact could DI have.

> As for ROO not generating server side DI as part of its tooling in STS when
> used with GWT I will have to check that out for myself; I believe I had read
> that it generates a server side application context configuration file and
> if that is the case then I'd like to know why it would do that if DI wasn't
> employed on the server. If that is the case then DI would certainly cause
> heightened latency causing an increase in 500 errors on App Engine virtual
> server cold starts.

Not having tried Roo, I can only talk about what's visible in the
Expenses sample:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/
and what I understand from Roo's addon-gwt source code:
https://fisheye.springsource.org/browse/spring-roo/addon-gwt

And I don't see DI here (on the server-side)

> As for DI being a best practice (that you'd encourage *anyone* to follow)
> well that is your opinion that is not shared by everyone. I encourage a more
> conservative approach to any engineering problem - use the right set of
> tools at the right time.

Sure. I maintain what I said though: DI is a pattern that makes code
easier to test and to maintain. And I really mean DI, as a pattern,
I'm not talking about any tool here; you're free to implement DI
"yourself", it doesn't necessarily means Guice or Spring or JavaEE 6
or whatever (which means you could do it with very low overhead, if
any). I found DI really improved software quality overall.

That being said, let me paraphrase you: "I am open minder. We

developers have to be :) and as such I would very
much like to be proven wrong on all these counts."

> As for Huh!?! That is something best saved for your friends on Facebook.
> This is a technical news group where such antics of conversation are not
> appreciated regardless of difference of opinion.

Sorry, I'm not a native English speaker/writer, so I probably misuse
idioms sometimes.

[Thomas Broyer]

On 31 oct, 15:26, Duong BaTien <duong.bat...@gmail.com> wrote:
> Hi:
>
> Good to know your experience with Roo and the light weight approach.

I think I already said it: I have zero experience with Roo.

> A best-practiced example of RequestFactory with GIN at GWT side and
> GUICE at server side may be what a mortal developer is looking for.

To really benefit from Guice (or more generally DI) on the server
side, you'd first have to wait for GWT 2.1.1, as in 2.1.0
RequestFactory makes heavy use of static methods.
See http://code.google.com/p/google-web-toolkit/issues/detail?id=5482
(among others)

[Jeff Schwartz]

Hi Thomas,

No hard feelings, I assure you, and I think your English is very good so please don't feel insecure. I apologize if I came off with an attitude; I didn't mean to, but it was early in the morning and I didn't have my 1st cup of coffee :)

Roo is a Spring Source technology as is STS & Spring DI. Spring DI uses an application context XML file placed in the war which upon application start up is read. If its contents include declarative class nodes then those classes are instantiated and any additional parameters may also be assigned to their properties to bring them into a usable state. Within the application's code are DI attribute declarations that are used by Spring DI for injecting the objects into the application. Almost all of the Java based DI technologies work in a similar fashion.

The benefits of using DI can vary. It is handy when you want to mock classes for testing, for instance. It is also handy for providing the ability to switch among the numerous implementations of common APIs. These are very worthy capabilities and in the right situations are handy to have. I personally use Spring DI with Wicket and Hibernate. They work together very well.

But with the positive also comes the negative just like with most things in life. For instance, many developers view maintaining an application's context file as burdensome and often complicated. In truth, at least IMO, this is best served by tooling provided in an IDE which understands the XML schemas and which can provide some code completion as well as intelligent feedback. STS, Springs' added value release of Eclipse, does just that but not everyone is using STS. On App Engine, one has 30 seconds to complete an HTML request. While that may seem like a lot of time, it isn't when you consider that on App Engine the time allocated to starting up a new virtual server to service the request is also included in that 20 second quota. Exceed that quota and your request fails with a 500 error. As DI requires additional cpu cycles to do its magic, it may cause an application to exceed the 30 second quota and fail at start up which I am sure you would agree is something to be avoided.

So I am not opposed to DI at all, I just prefer to have the option of using it or not using it such as on App Engine.

In regard to GWT v2.1 MVP, it seems apparent to me that Google is championing Roo as their choice for developers to use when integrating MVP into their GWT applications. From the little I really know about it, Roo is able to generate a lot of the boilerplate code needed to keep the views, models and presenters in sync. This is fine but I would have preferred if Google had also provided options such as extending the code refactoring ability in Eclipse to provide this support. I imagine this wouldn't be a trivial effort but what is when it comes to developing applications? As an example of what I mean, currently when adding a RemoteService using Eclipse all the bindings between the service interface, the service async interface and the service implementation are automatically generated. If I add a method to the service interface and forget to add its implementation it is flagged as an error. This type of 'built in' support is very intuitive as well as productive since the developer is already familiar with their IDE. I can imagine this can also be done with MVP in Eclipse and would eliminate the need for Roo altogether.

Options are a developer's best friend IMO.

Have a great day.

Jeff





 



 

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

[Stephen Haberman]

> As DI requires additional cpu cycles to do its magic

I'd be interested to hear if you have any profiling results specifically
showing DI is responsible for the bad startup perf.

My assertion is that if you startup Hibernate + Wicket + whatever
without DI, just configuring them by hand, it will take 90%+ of the time
it took with DI. E.g. DI should be negligible.

I could very well be wrong, but I do agree with Thomas that, in theory,
DI should be cheap. "Some cycles", yes. But there is no I/O, not a huge
computational task to be done--it should be fast.

Hibernate itself is notoriously slow to startup, so, yeah, any stack
change you make that involves changing Hibernate to Objectify will get a
great startup boost, regardless of whether DI is involved.

That being said, I'm not a Spring (nor Guice) fan, so would actually
enjoy seeing numbers that show, say, your stack w/Spring takes x% more
time than the same stack w/o Spring.

(...it sucks this conversation is happening on the "Announcing GWT 2.1"
thread. Whoever started this tangent, new thread next time.)

- Stephen

[Shawn Brown]

> That being said, I'm not a Spring (nor Guice) fan, so would actually
> enjoy seeing numbers that show, say, your stack w/Spring takes x% more
> time than the same stack w/o Spring.

Here's what I read...

"I’ve been able to reduce my cold start time on AppEngine from an
average of 8.1s to 2.5s, a 69% reduction" ..."by eliminating DI
frameworks and using Objectify for persistence".
http://turbomanage.wordpress.com/2010/03/26/appengine-cold-starts-considered/

"Spring MVC added around 6 seconds to the cold start time"
http://blog.listry.com/2010/03/google-app-engine-cold-start-guide-for.html

Shawn

[Shawn Brown]

>> That being said, I'm not a Spring (nor Guice) fan, so would actually
>> enjoy seeing numbers that show, say, your stack w/Spring takes x% more
>> time than the same stack w/o Spring.

One more:

http://www.streamhead.com/google-appengine-java-loading-request-analysis/

Shawn

[Stephen Haberman]

Hi Shawn,

Thanks for the links.

Moving off JDO and Spring MVC (the web framework, not DI) seemed to be
the biggest startup time wins, which is in line with my assertion that
DI itself is not typically the bottleneck.

That being said, the streamhead link:

> http://www.streamhead.com/google-appengine-java-loading-request-analysis/

Was the most interesting because he truly did DI/no-DI comparison
(trusting his approach anyway), and saw base DI adding 1s overhead.

That is more than I would have guessed, but given it's Spring, I guess
I can believe it.

I do enjoy seeing startup time highlighted--way too many pointy haired
managers (or architects) don't think 10s+, 30s+, 60s+ app startups times
affect their developers' productivity. It's terribly frustrating.

Thanks again,
Stephen

[Jeff Schwartz]

When targeting App Engine it isn't developer productivity I am so concerned about but rather user experience as well as cascading failures caused by an initial request failure should the additional time required to fire up Spring DI cause the initial request to go over the allotted total time as per the request quota; Google will throttle back starting up new servers to service requests. Like I said previously, this causes cascading failures.

My mantra for targeting App Engine is Lean & Mean!
 
Jeff

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

[shinde...@rediffmail.com]

These mails being mark to me

Kindly avoid
Sent on my BlackBerry® from Vodafone

[shinde...@rediffmail.com]

These mail r been coming to me and I am not a part of this.
Please take a note of this.

Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Duong BaTien <duong....@gmail.com>
Sender: google-we...@googlegroups.com
Date: Sun, 31 Oct 2010 08:26:38
To: <google-we...@googlegroups.com>
Reply-To: google-we...@googlegroups.com
Subject: Re: Announcing GWT 2.1

[shinde...@rediffmail.com]

Ur mails r getting wrongly marked to me.
Please avoid

Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Thomas Broyer <t.br...@gmail.com>
Sender: google-we...@googlegroups.com
Date: Sun, 31 Oct 2010 09:39:42
To: Google Web Toolkit<google-we...@googlegroups.com>
Reply-To: google-we...@googlegroups.com
Subject: Re: Announcing GWT 2.1

[rahul vijay shinde]

These mail are been wrongly marked to me

Please avoid.

Regards
Rahul Shinde


On Mon, 01 Nov 2010 11:01:25 +0530 Stephen Haberman wrote

>Hi Shawn,
>
>Thanks for the links.
>
>Moving off JDO and Spring MVC (the web framework, not DI) seemed to be
>the biggest startup time wins, which is in line with my assertion that
>DI itself is not typically the bottleneck.
>
>That being said, the streamhead link:
>
>> http://www.streamhead.com/google-appengine-java-loading-request-analysis/
>
>Was the most interesting because he truly did DI/no-DI comparison
>(trusting his approach anyway), and saw base DI adding 1s overhead.
>
>That is more than I would have guessed, but given it's Spring, I guess
>I can believe it.
>
>I do enjoy seeing startup time highlighted--way too many pointy haired
>managers (or architects) don't think 10s+, 30s+, 60s+ app startups times
>affect their developers' productivity. It's terribly frustrating.
>
>Thanks again,
>Stephen
>

>--
>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-we...@googlegroups.com.
>To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
>For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

[rahul vijay shinde]

These mail are been wrongly marked to me

Please avoid.

Regards
Rahul Shinde

On Mon, 01 Nov 2010 10:04:12 +0530 Shawn Brown wrote

[Thomas Broyer]

On 31 oct, 18:57, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Hi Thomas,
>
> No hard feelings, I assure you, and I think your English is very good so
> please don't feel insecure. I apologize if I came off with an attitude; I
> didn't mean to, but it was early in the morning and I didn't have my 1st cup
> of coffee :)

OK, no problem.

> Roo is a Spring Source technology as is STS & Spring DI. Spring DI uses an
> application context XML file placed in the war which upon application start
> up is read. If its contents include declarative class nodes then those
> classes are instantiated and any additional parameters may also be assigned
> to their properties to bring them into a usable state. Within the
> application's code are DI attribute declarations that are used by Spring DI
> for injecting the objects into the application. Almost all of the Java based
> DI technologies work in a similar fashion.

Well, except that Guice for instance (and I believe JavaEE 6 too, as
it's based on JSR 330, lead by Bob Lee, creator of Guice) does not use
an XML file.

> The benefits of using DI can vary. It is handy when you want to mock classes
> for testing, for instance. It is also handy for providing the ability to
> switch among the numerous implementations of common APIs. These are very
> worthy capabilities and in the right situations are handy to have. I
> personally use Spring DI with Wicket and Hibernate. They work together very
> well.
>
> But with the positive also comes the negative just like with most things in
> life. For instance, many developers view maintaining an application's
> context file as burdensome and often complicated. In truth, at least IMO,
> this is best served by tooling provided in an IDE which understands the XML
> schemas and which can provide some code completion as well as intelligent
> feedback.

That's why Guice does not use XML but only plain old Java with
annotations. It's in some situations not as flexible as Spring though:
http://code.google.com/p/google-guice/issues/detail?id=167 (for
instance)
See also: http://code.google.com/p/google-guice/wiki/SpringComparison

But Spring can also be used without an XML configuration:
http://blog.springsource.com/2009/12/22/configuration-simplifications-in-spring-3-0/
(it's much like "DI by hand")

> STS, Springs' added value release of Eclipse, does just that but
> not everyone is using STS. On App Engine, one has 30 seconds to complete an
> HTML request. While that may seem like a lot of time, it isn't when you
> consider that on App Engine the time allocated to starting up a new virtual
> server to service the request is also included in that 20 second quota.
> Exceed that quota and your request fails with a 500 error. As DI requires
> additional cpu cycles to do its magic, it may cause an application to exceed
> the 30 second quota and fail at start up which I am sure you would agree is
> something to be avoided.

Isn't that somehow due to Spring insisting in "everything should be a
singleton" (and eagerly instantiating them)?

> So I am not opposed to DI at all, I just prefer to have the option of using
> it or not using it such as on App Engine.

So I assure you RequestFactory does not imply DI; much the contrary
actually (in 2.1.0) ;-)

> In regard to GWT v2.1 MVP, it seems apparent to me that Google is
> championing Roo as their choice for developers to use when integrating MVP
> into their GWT applications. From the little I really know about it, Roo is
> able to generate a lot of the boilerplate code needed to keep the views,
> models and presenters in sync. This is fine but I would have preferred if
> Google had also provided options such as extending the code refactoring
> ability in Eclipse to provide this support. I imagine this wouldn't be a
> trivial effort but what is when it comes to developing applications? As an
> example of what I mean, currently when adding a RemoteService using Eclipse
> all the bindings between the service interface, the service async interface
> and the service implementation are automatically generated. If I add a
> method to the service interface and forget to add its implementation it is
> flagged as an error. This type of 'built in' support is very intuitive as
> well as productive since the developer is already familiar with their IDE. I
> can imagine this can also be done with MVP in Eclipse and would eliminate
> the need for Roo altogether.

I don't know exactly what Roo generates, but there are two parts:
- validation: EntityProxy re. their @ProxyFor counterpart, and
RequestContext re. their @Service counterpart, and Editor<?> re. the
edited object: yes having validation right in the IDE would be great,
but it can only be done one way (an EntityProxy/RequestContext method
doesn't match any method on the @ProxyFor/@Service class, Editor
trying to edit a property that doesn't exist on the object; or type
mismatch; but you won't want e.g. the EntityProxy being flagged
because it doesn't map a method of the @ProxyFor object, as that could
very well be by-design in your code). Apart from type mismatch I can't
see a very useful "quick fix" apart from removing the method/property.
- maintainance: AFAICT, Roo only maintains in sync the "scaffold"
activities and views it has itself generated; that's the job of Roo
really (from what I know about it, including with other kind of
projects, e.g. Spring Surf), and I'm not sure I'd want it in my IDE,
if it'd be possible at all (I mean, unless I "opt-in", as with STS,
which AFAIK automates the launch of Roo to sync things, through
AspectJ).

> Options are a developer's best friend IMO.

I cannot agree more!
(and I think the GWT team agree too, their partnership with VMWare is
about choice: http://code.google.com/cloudportability/ )

[Jeff Schwartz]

On Mon, Nov 1, 2010 at 8:22 AM, Thomas Broyer <t.br...@gmail.com> wrote:

Well, except that Guice for instance (and I believe JavaEE 6 too, as
it's based on JSR 330, lead by Bob Lee, creator of Guice) does not use
an XML file.

Yes however I was specifically speaking to Spring DI.

Isn't that somehow due to Spring insisting in "everything should be a
singleton" (and eagerly instantiating them)?

 

I believe so, yes.

My concerns aren't with MVP; from what I have read I think MVP is a very good design pattern & I am eager to incorporate it. My concerns are more aligned with the dependency on Roo & STS (which I use for Groovy and for Grails development & which I really like) to accomplish syncing Views & Presenters. I would have preferred a pure Java solution such as relying on the compiler and code refactoring to generate binding code where needed.

Jeff

[Thomas Broyer]

On 1 nov, 14:04, Jeff Schwartz <jefftschwa...@gmail.com> wrote:

> On Mon, Nov 1, 2010 at 8:22 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > Well, except that Guice for instance (and I believe JavaEE 6 too, as
> > it's based on JSR 330, lead by Bob Lee, creator of Guice) does not use
> > an XML file.
>
> Yes however I was specifically speaking to Spring DI.
>
> Isn't that somehow due to Spring insisting in "everything should be a
>
> > singleton" (and eagerly instantiating them)?
>
> I believe so, yes.

So the issue is not DI (the pattern), but the Spring framework ;-)

(and to answer my remark re. DI "that I'd encourage
*anyone* to follow", I wouldn't recommend using Spring for DI, unless
you want "configurability" through XML application contexts)

[Jeff Schwartz]

On Mon, Nov 1, 2010 at 10:54 AM, Thomas Broyer <t.br...@gmail.com> wrote:

On 1 nov, 14:04, Jeff Schwartz <jefftschwa...@gmail.com> wrote:

> On Mon, Nov 1, 2010 at 8:22 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > Well, except that Guice for instance (and I believe JavaEE 6 too, as
> > it's based on JSR 330, lead by Bob Lee, creator of Guice) does not use
> > an XML file.
>
> Yes however I was specifically speaking to Spring DI.
>
> Isn't that somehow due to Spring insisting in "everything should be a
>
> > singleton" (and eagerly instantiating them)?
>
> I believe so, yes.

So the issue is not DI (the pattern), but the Spring framework ;-)

I think I have already stated what my concerns are, Thomas, & I feel that you want me to say something that would confirm to you - in your mind at least - that I agree with. I don't and just to be clear I will offer my concerns one more time:

1) Reliance on Roo/STS if one wants to sync changes between Presenters & Views.
2) Roo adding Spring DI - one only has to look at the generated app context file to confirm this.

And in the interest of clarity, my preference to the above is:
1) Rely on Java and refactoring to provide a similar ability to sync Presenters & Views even if it only flags errors indicating a discrepancy between an interface & its implementation.

And no, I have nothing against Spring nor their DI implementation. Quite to the contrary in fact. As a company I think very highly of them. They have made numerous contributions to OS and I am grateful to them for that. As for their DI, I will use it when I feel it is the best solution. I don't want to use it because it is the only solution.

(and to answer my remark re. DI "that I'd encourage
*anyone* to follow", I wouldn't recommend using Spring for DI, unless
you want "configurability" through XML application contexts)

I wouldn't recommend to anyone to use any type of DI because it is the only option available. If it were the only option available I'd question my choice of development stack including framework and language. Fortunately, the situations where DI is the only answer are rare - I have never encountered one myself. I'd only recommend DI after carefully evaluating all the alternatives and concluding that DI is the best solution.

I hope this lays to rest any questions you may have had. I think in the interest of the group this end the public track of this conversation. You can email me should you desire but like I said, I believe I have been very forthcoming and clear with my comments.

Jeff

>
> My concerns aren't with MVP; from what I have read I think MVP is a very
> good design pattern & I am eager to incorporate it. My concerns are more
> aligned with the dependency on Roo & STS (which I use for Groovy and for
> Grails development & which I really like) to accomplish syncing Views &
> Presenters. I would have preferred a pure Java solution such as relying on
> the compiler and code refactoring to generate binding code where needed.
>
> Jeff

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

[David Chandler]

Hi Jeff,

GWT 2.1 has no dependency on Roo. It is very much our intent that you should be able to create GWT apps with or without Roo. The latter offers some conveniences for certain types of apps like CRUD apps where you have, say, 40 entities, each with corresponding CRUD screens, and a view, presenter, RequestContext, DAO, etc. for each. In this example, the need for concrete classes per entity ultimately results from the fact that code generation (whether via GWT generator or Roo) is GWT's alternative to reflection. GWT 2.1 does not require much boilerplate and 2.1.1 will require even less. And yes, improved tooling in Google Plugin for Eclipse is definitely on radar.

As far as DI is concerned, DI proper is not the cause of cold start latency on App Engine, but rather one particular scenario in which singletons are created eagerly at startup time. I wrote about this on my personal blog (http://turbomanage.wordpress.com) linked above. This should become much less of an issue shortly (per http://code.google.com/p/googleappengine/issues/detail?id=2456), as it appears the GAE team is close to releasing warmup requests, and reserved instances are on the roadmap.

Best,

/dmc

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--

[Jeff Schwartz]

Thanks, David, for clarifying this.

If at any time it may have seemed that I was implying that there was was any static dependency between Roo or Spring DI and GWT let me say that I know there isn't. There is, though, an implied dynamic dependency between Roo, Spring DI & MVP if one wants to synchronize their views and presenters during development as per the Expenses example project. I say implied because at this time it appears that the only available option to achieve this is by using Roo but I am sure that there will be additional options coming down the pike:).

I am also very pleased to know that there will be improved tooling in the Eclipse plugin. I spend more time using Eclipse than I do with my family lol so it is reassuring to know that this will evolve.

Again, thank you.

Jeff

Jeff

[David Chandler]

Hey Jeff,

Can you elaborate on what you mean by syncing views and presenters
during development? Are you saying there's too much boilerplate such
that Roo is the only practical alternative? If so, which boilerplate
classes most concern you? We welcome discussion on ways to simplify.
We definitely aim to make place mapping easier.

Thanks,
/dmc

[John O'Malley]

This works for me but the GWTTestCases are taking forever. Each one
is starting up dev mode on a different port. I don't think that was
happening before:

[ERROR] log4j:WARN Please initialize the log4j system properly.
[INFO] Please navigate your browser to this URL:
[INFO] http://10.29.127.35:2984/{module}.JUnit/junit.html?gwt.codesvr=10.29.127.35:2980

Where {module} is the module for the GWTTestCase.

The test eventually completes but it's taking maybe 10 times as long
as it used to.

Anyone know what's going on? My configuration is below (gwt.version
is 2.1.0).

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3.2.google</version>
<configuration>
<module>{module}</module> <!-- actual module name is here -->
<buildOutputDirectory>target</buildOutputDirectory>
<generateDirectory>target/generated-sources/gwt</
generateDirectory>
<runTarget>StarUI.html</runTarget>
<gwtVersion>${gwt.version}</gwtVersion>
</configuration>
<executions>
<execution>
<id>gwt-compile</id>
<phase>prepare-package</phase>
<goals>
<goal>compile</goal>
</goals>
</execution>
<execution>
<id>run-gwt-tests</id>
<goals>
<goal>test</goal>
</goals>
<configuration>
<includes>**/*_GT.java</includes>
</configuration>
</execution>
</executions>
</plugin>


On Oct 28, 11:15 pm, "arrival...@gmail.com" <arrival...@gmail.com>
wrote:
> Hi Giuseppe,
>
> I had a similar problems, and found out that late that my browser
> (i.e. chrome)  had cache the previous info, try to clean the temp data
> in the browser.
>
> Also, check whichGWTversion you specified within your plugin
> reference in pom.xml. Here is my example pom.
>
> <plugin>
>         <groupId>org.codehaus.mojo</groupId>
>         <artifactId>gwt-maven-plugin</artifactId>
>         <version>1.3.2.google</version>
>         <configuration>
>                 <logLevel>INFO</logLevel>
>                 <style>PRETTY</style>
>                 <gwtVersion>${gwt.version}</gwtVersion>
>                 <webappDirectory>${basedir}/war</webappDirectory>
>                 <module>${project.groupId}.isearch.ISearch</module>
>                 <runTarget>ISearch.jsp</runTarget>
>                 <copyWebapp>true</copyWebapp>
>         </configuration>
>         <executions>
>                 <execution>
>                         <id>gwtcompile</id>
>                         <phase>prepare-package</phase>
>                         <goals>
>                                 <goal>compile</goal>
>                         </goals>
>                 </execution>
>         </executions>
> </plugin>
>
> Hope this helps.
>
> Also, thank you so much for your hard work!! I had a question on
> google's "gwt-maven-plugin." First, is there documentation available
> for the different configuration available? I have questions on the
> function for  <hostedWebapp>, <webappDirectory>, <copyWebapp>? Thank
> you again~!
>
> Jay
>
> On Oct 29, 6:02 am, Giuseppe La Scaleia
>
>
>
>
>
>
>
> <giuseppe.lascal...@geosdi.org> wrote:
> > Hi all ,
> > great work. A simple question i have mymavenproject withgwt-maven-plugin
> > 1.2 version. I have upload togwt2.1.0 and for plugin at version
> > 1.3.2.google but i have the follow error
>
> > You're project declares dependency ongwt-user2.1.0. This plugin is
> > designed for version2.1-SNAPSHOT
> > java.lang.NullPointerException
> >     at
> > org.codehaus.mojo.gwt.AbstractGwtMojo.getClasspath(AbstractGwtMojo.java:220 )
> >     at
> > org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo$JavaCommand.withinScope(Ab stractGwtShellMojo.java:284)
> >     at org.codehaus.mojo.gwt.shell.CompileMojo.compile(CompileMojo.java:186)
> >     at
> > org.codehaus.mojo.gwt.shell.CompileMojo.doExecute(CompileMojo.java:178)
> >     at
> > org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMo jo.java:118)
> >     at
> > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManag er.java:490)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif ecycleExecutor.java:694)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycl e(DefaultLifecycleExecutor.java:556)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLife cycleExecutor.java:535)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFai lures(DefaultLifecycleExecutor.java:387)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(Def aultLifecycleExecutor.java:348)
> >     at
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycl eExecutor.java:180)
> >     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> >     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> >     at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> >     at
> > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> >     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >     at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9)
> >     at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25)
> >     at java.lang.reflect.Method.invoke(Method.java:597)
> >     at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >     at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> >     at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> >     at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>
> > What version must i use??
> > Thanks Giuseppe
>
> > 2010/10/28 David Chandler <drfibona...@google.com>
>
> > > You're welcome, Tim. Thanks for posting back.
>
> > > /dmc
>
> > > On Thu, Oct 28, 2010 at 4:07 PM, tim.meck...@gmail.com
> > > <tim.meck...@gmail.com> wrote:
> > > > Thanks for your quick response! I needed to update thegwt-maven-
> > > > plugin version which was previously pointing to a version that
> > > > expectedgwt-soyc-vis.
>
> > > > On Oct 28, 3:45 pm, David Chandler <drfibona...@google.com> wrote:
> > > >> Hi Tim,
>
> > > >>gwt-soyc-vis.jar is intentionally not in themavenrepo because all
> > > >> the functionality has been moved intogwt-dev.jar. You should be able
> > > >> to remove the dependency ongwt-soyc-vis from your POM.
>
> > > >> Thank you,
> > > >> /dmc
>
> > > >> On Thu, Oct 28, 2010 at 3:31 PM, tim.meck...@gmail.com
>
> > > >> <tim.meck...@gmail.com> wrote:
> > > >> > This is very exciting news.
>
> > > >> > I think I've run into a small obstacle that maybe someone could help
> > > >> > with. Upon updating mymavenbuild dependencies forgwt, my build now
> > > >> > errors on com.google.gwt:gwt-soyc-vis:jar:2.1.0 not found in themaven
> > > >> > central repo. Is this something I'm doing incorrectly?
>
> > > >> > Congratulations on the release!
> > > >> > Tim Mecklem
>
> > > >> > On Oct 28, 2:12 pm, David Chandler <drfibona...@google.com> wrote:
> > > >> >>GWT2.1is here!
>
> > >http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...

>
> > > >> >> --
> > > >> >> David Chandler
> > > >> >> Developer Programs Engineer, Google Web Toolkithttp://
> > > googlewebtoolkit.blogspot.com/
>
> > > >> > --

> > > >> > 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-we...@googlegroups.com.
> > > >> > To unsubscribe from this group, send email to

> > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > > .

> > > >> > For more options, visit this group athttp://
> > > groups.google.com/group/google-web-toolkit?hl=en.
>
> > > >> --
> > > >> David Chandler
> > > >> Developer Programs Engineer, Google Web Toolkithttp://
> > > googlewebtoolkit.blogspot.com/
>
> > > > --

> > > > 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-we...@googlegroups.com
> > > .
> > > > To unsubscribe from this group, send email to

> > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > > .

> > > > For more options, visit this group at
> > >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> > > --
> > > David Chandler
> > > Developer Programs Engineer, Google Web Toolkit
> > >http://googlewebtoolkit.blogspot.com/
>
> > > --
> > > 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-we...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > > .

> > > For more options, visit this group at
> > >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> > --

> > Giuseppe La Scaleia
> > CNR - IMAA
> > geoSDI - NSDI
> > Sviluppo Software
>
> > C.da S. Loja
> > 85050  Tito Scalo - POTENZA (PZ)
> > Italia
>
> > phone:  +39 0971427305
> > fax:      +39 0971 427271
> > mob:    +39 3804697436
> > mail:     giuseppe.lascal...@geosdi.org
> > skype:  glascaleia
>
> > web:    http://www.geosdi.org