Maven is obfuscating and GWT2.1 should not depend on it
3 views
Skip to first unread message
Blessed Geek
Jun 6, 2010, 4:14:54 PM6/6/10
to Google Web Toolkit
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).
I would like to request GWT architects to provide an alternative to
Spring for data-ui binding, with a more direct xml xsd route.
I am also writing this to encourage people to stop misusing maven,
because it spews out a lot of entrails and unlike a compilation error
in java or c++ from which you can easily spot the error, maven is like
Perl - because when you write in Perl, you don't need an obfuscater.
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).
I would like to request GWT architects to provide an alternative to
Spring for data-ui binding, with a more direct xml xsd route.
I am also writing this to encourage people to stop misusing maven,
because it spews out a lot of entrails and unlike a compilation error
in java or c++ from which you can easily spot the error, maven is like
Perl - because when you write in Perl, you don't need an obfuscater.
Alan Chaney
Jun 6, 2010, 6:43:05 PM6/6/10
to google-we...@googlegroups.com
+1
Giuseppe La Scaleia
Jun 7, 2010, 1:56:03 AM6/7/10
to google-we...@googlegroups.com
Il 07/06/10 00.43, Alan Chaney ha scritto:-1 for me
Thomas Broyer
Jun 7, 2010, 6:49:32 AM6/7/10
to Google Web Toolkit
On 6 juin, 22:14, Blessed Geek <blessedg...@gmail.com> 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).
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–)
Matthias Groß
Jun 13, 2010, 7:19:20 PM6/13/10
to Google Web Toolkit
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
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
Blessed Geek
Jun 20, 2010, 4:43:07 PM6/20/10
to Google Web Toolkit
What I wrote to initiate this discussion may confuse things a little,
but I do realise that I do not have to use Spring Roo. I was simply
too lazy to micro-manage that detail.
I must confess that I am confused by Spring's use of Maven.
When I tried Spring Roo, perhaps, I was confused with all the entrails
that Maven was spewing out. There were error messages and I had no
idea what to do with those diagnostics. Imagine using Ant to write a
web app - of course you could do that. But wouldn't be better if I
wrote it in Java or Python?
May be, Spring was attempting to build the Maven project for me by
dynamically constructing the pom for me.
Alright, perhaps, the intertwining of Maven is to provide and escape-
path flexibility for people to choose to use or not to use GWT for
presentation. Ok, then forget it, because I am intent on using GWT or
SmartGWT and uibinder with them. Giving me the flexibility not to use
them is introducing dependency and consequently points of failure I do
not wish to deal with.
Alright again, perhaps, the intertwining of Maven is to provide an
opportunity for me to insert a process to inspect a database schema
and then automate the production of the data model and then automate
the production of data stream template.
When I use Microsoft Visual Studio with ADO.NET life is simple. I
don't have command line statements to type in. Why can't it be as
simple as using Visual Studio? Why can't all this complexity be hidden
behind Eclipse?
Oh yes, I remember now, you are providing me with yet another
flexibility - the option not to use Eclipse.
What I need is a smooth spontaneous path from my data model to view/
presentation. I just do the JPA/JDO objects and their interaction with
the data repository, then I present the objects to the client which
autonomously and spontaneously decides how to present the data or
solicit inputs at the GWT client.
How complicated can that be? Why do you need involving a dependency
tool like Maven or Ant to do that? Like a sledge hammer on a nail?
Oh, oops, I missed this one - that Maven is involved because it is
trying to template the auto-build process for me, which I could pick
and stick by my own to improve it. If I have to manually pick and
stick an automation template - is that even called automation because
I don't even know what to pick and where to stick on the template that
Spring Roo has created for me.
Trying to achieve so much flexibility with such unsuitable a tool like
Maven. That is too ambitious to do everything with Maven. My lack of
understanding of how to use Spring Roo "properly" finds it a
monolithic fascistic tool that tries to be a socialist grand-daddy to
every entity in the build process.
Well defined autonomous modular steps can flexibly build the world.
The general rule of industrial practice - A tool that introduces more
complexity in an attempt at simplification, or introduces more point
of failures requiring manual intervention, in an attempt at automation
is NOT to be used at all.
It is highly probable that I don't know how to use Spring Roo
"properly". In fact, I don't know what it does within that food
chain ...
Why do you even bother to construct the pom for me? Just help me
construct the pathway from schema to model to presentation and let me
decide if I wish to and how to use Maven. Can't it be done the way
DataNucleus does it for me? Why involve Maven? Decouple Maven from
that pre-build process and leave the Maven glue-ification decision to
me.
I consider DataNucleus a very usable tool. The guys who wrote it have
my every accolade as professionals. Every diagnostic it spews out, I
know what to do with them - even when the first time I used it. The
usability of Spring Roo is no where near DataNucleus'. Couldn't Spring
Roo be architected to be operated like DataNucleus? Actually, couldn't
GWT team recommend something else that is operated like DataNucleus?
Sorry for the outburst, and perhaps to Maven mavens and Spring havens
I sound like an incompetent programmer - so my apologies about that,
but ...
So I am considering a project where the utility would inspect an
entity class and its annotation, builds uibinder template. we could
write a GWT client-side code that runs similarly to SmartGWT
datasource, which inspects the RPC'd objects and decides what widgets
to use to present them. The client-side datasource would also be fed
with a json config where we would specify preferences to affect the
data presentation. It's that simple - why get Spring or Maven
involved?
but I do realise that I do not have to use Spring Roo. I was simply
too lazy to micro-manage that detail.
I must confess that I am confused by Spring's use of Maven.
When I tried Spring Roo, perhaps, I was confused with all the entrails
that Maven was spewing out. There were error messages and I had no
idea what to do with those diagnostics. Imagine using Ant to write a
web app - of course you could do that. But wouldn't be better if I
wrote it in Java or Python?
May be, Spring was attempting to build the Maven project for me by
dynamically constructing the pom for me.
Alright, perhaps, the intertwining of Maven is to provide and escape-
path flexibility for people to choose to use or not to use GWT for
presentation. Ok, then forget it, because I am intent on using GWT or
SmartGWT and uibinder with them. Giving me the flexibility not to use
them is introducing dependency and consequently points of failure I do
not wish to deal with.
Alright again, perhaps, the intertwining of Maven is to provide an
opportunity for me to insert a process to inspect a database schema
and then automate the production of the data model and then automate
the production of data stream template.
When I use Microsoft Visual Studio with ADO.NET life is simple. I
don't have command line statements to type in. Why can't it be as
simple as using Visual Studio? Why can't all this complexity be hidden
behind Eclipse?
Oh yes, I remember now, you are providing me with yet another
flexibility - the option not to use Eclipse.
What I need is a smooth spontaneous path from my data model to view/
presentation. I just do the JPA/JDO objects and their interaction with
the data repository, then I present the objects to the client which
autonomously and spontaneously decides how to present the data or
solicit inputs at the GWT client.
How complicated can that be? Why do you need involving a dependency
tool like Maven or Ant to do that? Like a sledge hammer on a nail?
Oh, oops, I missed this one - that Maven is involved because it is
trying to template the auto-build process for me, which I could pick
and stick by my own to improve it. If I have to manually pick and
stick an automation template - is that even called automation because
I don't even know what to pick and where to stick on the template that
Spring Roo has created for me.
Trying to achieve so much flexibility with such unsuitable a tool like
Maven. That is too ambitious to do everything with Maven. My lack of
understanding of how to use Spring Roo "properly" finds it a
monolithic fascistic tool that tries to be a socialist grand-daddy to
every entity in the build process.
Well defined autonomous modular steps can flexibly build the world.
The general rule of industrial practice - A tool that introduces more
complexity in an attempt at simplification, or introduces more point
of failures requiring manual intervention, in an attempt at automation
is NOT to be used at all.
It is highly probable that I don't know how to use Spring Roo
"properly". In fact, I don't know what it does within that food
chain ...
Why do you even bother to construct the pom for me? Just help me
construct the pathway from schema to model to presentation and let me
decide if I wish to and how to use Maven. Can't it be done the way
DataNucleus does it for me? Why involve Maven? Decouple Maven from
that pre-build process and leave the Maven glue-ification decision to
me.
I consider DataNucleus a very usable tool. The guys who wrote it have
my every accolade as professionals. Every diagnostic it spews out, I
know what to do with them - even when the first time I used it. The
usability of Spring Roo is no where near DataNucleus'. Couldn't Spring
Roo be architected to be operated like DataNucleus? Actually, couldn't
GWT team recommend something else that is operated like DataNucleus?
Sorry for the outburst, and perhaps to Maven mavens and Spring havens
I sound like an incompetent programmer - so my apologies about that,
but ...
So I am considering a project where the utility would inspect an
entity class and its annotation, builds uibinder template. we could
write a GWT client-side code that runs similarly to SmartGWT
datasource, which inspects the RPC'd objects and decides what widgets
to use to present them. The client-side datasource would also be fed
with a json config where we would specify preferences to affect the
data presentation. It's that simple - why get Spring or Maven
involved?
Jaroslav Záruba
Jun 20, 2010, 5:02:45 PM6/20/10
to google-we...@googlegroups.com
2010/6/14 Matthias Groß <f0r7...@googlemail.com>
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 to make things clear, I hope you're describing your experience with Roo, right? Why would GWT "absorb flaws from Maven" then? I'm using GWT2.1m1 w/o Roo and I don't use/need Maven.
???
In fact, if Roo requires Maven then I'm not interested anymore. I don't want to pile bazillion of layers or omni-potent frameworks every time I install new version of Eclipse. (Not speaking about potential for things blowing up with more "intelligent" sub-systems wired together.)
I know Roo only from the presentation video and the impression has been good, but Maven would be 'deal-breaker'.
--
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.
Chris Boertien
Jun 20, 2010, 11:05:31 PM6/20/10
to google-we...@googlegroups.com
@Blessed Geek
If your serious about starting up a project like your describing I'm
interested in working on it. I have a need for just such a tool and
have been meaning to sit down and actually do some planning for it.
Let me know if you'd like to bounce some ideas around and when is good
for you.
2010/6/20 Jaroslav Záruba <jarosla...@gmail.com>:
Blessed Geek
Jun 23, 2010, 2:51:22 AM6/23/10
to Google Web Toolkit
Chris, I am working on it now because I need that feature really badly
- it's a do or die situation because I have so many forms to crud.
Please write to my gmail id: blessedgeek.
- it's a do or die situation because I have so many forms to crud.
Please write to my gmail id: blessedgeek.
Reply all
Reply to author
Forward
0 new messages