Hi,

I just wanted to try out the gwt/spring/roo example presented at the
last Google I/O and utterly failed. First try was on my win7 64 bit
host-system environment. Now I am installing it into a VM using a
32bit XP. One thing I noticed, is that maven loads myriads of
depependencies when ressolving them at project setup. This is so
fucking annoying because in every new environment it takes me >20
minutes to setup a new test-project.

Furthermore it feels totally wrong. GWT made everything easier and
faster. E.g. they introduced Guice/Git for GWT to get rid off all
those nasty dependencies within your projects. They made compiling,
deploying and debugging very easy...and now they incorporate Maven
into the build-process which results in massive dependancy handling
since different dependencies rely on different builds of the same
artifact. So effectively you download way to much code and I fear the
risk of "re-importing" the dependency- and XML-configuration-hell you
had to face in big, heterogenous productive-environments. I bet the
amount of executed code (in the deployed app) is less than 10% of what
I am downloading now...most probably even less.

If GWT absorbs these flaws from Maven and Spring it would lose some of
its most significant benefits for me, i.e. being slim, effective and
easy to use.

just my $0.02

Kind regards
Matthias

On 7 Jun., 12:49, Thomas Broyer <[email protected]> wrote:
> On 6 juin, 22:14, Blessed Geek <[email protected]> wrote:
>
>
>
>
>
> > Maven is great when used as a "more capable Ant", but sucks when used
> > for everything else that it has been so far been used for (like
> > attempting to create the Universe in 7 days).
>
> > Maven as a build dependency and testing setup tool is not bad but the
> > way it has been misused for everything else so far sucks. Despite any
> > enthusiasm anyone else has for Maven as a all-in-one Swiss knife all-
> > purpose tool, my personal observation says that Maven is the wrong
> > tool to use to perform MVP/MVC building (as well as almost everything
> > else).
>
> > Maven is a good tool to be used in-house within great companies like
> > IBM or Google who have some spare change to hire someone to maintain
> > the scripts to perform esoteric tasks like MVP/MVC code preparations
> > and concoctions but not for small companies or contractors.
>
> > Therefore, it is a disappointment that GWT 2.1 decided to use Spring
> > which has a huge dependency on the abuse of use of Maven.
>
> > GWT MVP/MVC should get back to the basics of XML XSD, like what
> > smartgwt is doing. I am hoping the GWT architects will provide an XML
> > XSD client side exposure to ui widgets and provide the specs to it so
> > that I could write my own mavenless data-ui binding (for example in
> > groovy).
>
> You are confusing many things:
>  1. GWT 2.1 does not "use Spring", it "works with" Spring Roo, in that
> Roo generates Java code from server-side code that's suitable for your
> GWT client-side; but Roo is only a "helper": you can do the same by
> hand (this is an explicitly goal of the system)
>  2. What Roo generates has nothing to do with MVP or data-ui binding
> but with the RequestFactory which is just a way of performing CRUD
> operations on entity objects easily and efficiently (by that I mean
> "on the wire", not "in your code"); sure it generates a "scaffold" app
> but you're free to build from it or trash it and start from scratch
>  3. demos of the Roo/GWT integration never mentionned Maven, so I
> think this is either an implementation detail (which I doubt) or just
> a way of grabbing all the dependencies, and eventually run Roo as part
> of your build process (I don't know, I don't do Maven, and I haven't
> looked at Roo –neither do I intend to look at it anytime soon–)

-- 
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