What's happening with GWT-Maven 1.3 vs GWT 2.0?

179 views
Skip to first unread message

Andrew Hughes

unread,
Jun 23, 2010, 10:05:27 PM6/23/10
to codehaus-mojo-gwt-...@googlegroups.com
Hi Guys,

Like most applications, GWT is a component of the stack. We don't have the time, budget (and to be honest skills) to mange our project standards, configuration, structure and build lifecyle - hence maven is extremely important!!!!!

But, our heads are getting awefully sore trying to get gwt-maven working with GWT 2.0's dev environment. I realize that the 2.0 created a lot of problems with maven. Google have more or less apologized for this and also kindly said in  Janurary/Feburary (2010) that they are going to help fix/resolve the problems maven users are experiencing. Evidently, this has either not occurred or has progressed in silence.

So, I guess the question is who know's what the deal is?

According to Jira 35/35 issues for gwt-maven v1.3 are resolved.

Major problems are:
  • run's via gwt:run, but fail's with the google eclipse plugin (java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/servlet/jsp/JspFactory).
    • ^indicates inconsistent launch configuration.
  • can't debug from eclipse due to error above
  • can't use the maven build:helper plugin to run "hot deploy" code from multiple maven modules in dev mode

Thanks for reading, if I could help I would! :)

nicolas de loof

unread,
Jun 24, 2010, 4:02:44 AM6/24/10
to codehaus-mojo-gwt-...@googlegroups.com
The issues you noticed are missing feature when integrating Maven with GWT and Google Eclipse plugin. Here is what happens under the hood :

GWT guys don't use maven, so they hardly understand our issues

They think a large "all the world" gwt-dev.jar, that includes other libs (apache commons, jetty, ...) and servlet-api java sources is a helper for developpers. It isn't as it introduces invisible compatibility issues. Seems GWT team don't write apps that uses any apaceh common lib on server side.

They think System.exit() is a nice way to end the compiler and free all resources. This makes embedding the compiler in another tool very hard

They don't use currentThread.contextClassLoader to load resources, considering they run in a standalone JVM Process

For such reasons the plugin code is not as simple as it should. 

They also don't publish GWT artifacts in maven repo, don't maintain a POM with project metadatas (I don't expect them to switch to maven, but publish project infos : license, dependencies, scm...)

GWT is not a nice Maven citizen, in fact it isn't a Maven citizen at all and I think they simply don't care about Maven. If this was the cas, they should have included a plugin in the SDK and wory more about packaging. The Google Eclipse Plugin provides a Async interface code generator that is redundant with the plugin generateAsync goal. Such code could be reused to avoid duplicated devs and incompatibilities. But it is not available as a standalone opensource component.

I'd be pleased to help add maven support in GWT SDK, and expected to see some when a fork of the plugin was deployed on GWT "svn" repository. But I'm still waiting for a diff to know what was changed in this "1.3.1.google" release. Anyway they don't plan to support this plugin, and the deployed artifacts have a minimal POM that wouldn't make it eligible to sync into Maven central

Hope this will change ...

Nicolas




2010/6/24 Andrew Hughes <ahhu...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "Codehaus Mojo gwt-maven-plugin Users" group.
To post to this group, send email to codehaus-mojo-gwt-...@googlegroups.com.
To unsubscribe from this group, send email to codehaus-mojo-gwt-maven-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.

Andrew Hughes

unread,
Jun 24, 2010, 12:11:02 PM6/24/10
to codehaus-mojo-gwt-...@googlegroups.com
Hi Nicholas,

Thanks for taking the time to answer this. This is endemic in the way non-maven users/project's understand maven's role in a software project.

Just in the hope some trawler at Google actually see's this...

Why I think Google Don't Get This...

At least from the outside, Google's a pretty unique engineering shop. You (Google) have access to some of the <link>brightest individuals on the planet (kudos). It's also very true to say that Google are incredibly succe$$ful </link>. Hence, finance/resourcing and ability are not issues that Google are exposed too like the rest of us. Consequently, Google can easily adsorb the overheads of managing and maintaining their project(s) code base + practices + configuration management and development infrastructure with a bespoke implementation. But Google's unique (more kudos)...

But why maven and thus gwt-maven?

The flip side to this is Google aren't exposed to what the rest of us are. The majority of our projects don't have the capability, resources, time or finances to implement and maintain disciplined "code base, practice, configuration management, e.t.c" to a level that maven provides out of the box. Consequently, we lean on maven. Maven helps our projects to live in a world that we could never replicate (mostly with ant, and eclipse does not even enter into this world). This is why we use maven, this is why it's important to us and this is the world we want/need to develop applications with greater potential.

In summary, GWT might be open source but the steering committee is not (AFAIK). A key feature of opensource is not just that you can get the source, but that you can contribute to it. I know and accept that's not possible, but I'd really like the situation UNDERSTOOD by the GWT steering committee and then maybe it'll get on their (active) radar.

Cheers :)


p.s. the number of gwt-maven projects found in googlecode and sourceforge is more than enough evidence to support my rant.

William Ferguson

unread,
Jun 24, 2010, 7:02:47 PM6/24/10
to codehaus-mojo-gwt-...@googlegroups.com
Perhaps the easiest path forwards would be to take the gwt-dev source code and mavenize it such that it produces all the existing artifacts ("all the world" gwt-dev.jar etc) as well as the expected maven artifacts. If that could be offered back to gwt-dev then perhaps not only do we have a way of moving forward but would hopefully gain some Maven supporters within Google.

Its a crying shame that one of the most innovative companies around is using such medieval build technology and forcing those of us who are trying to build on their frameworks into the wasteland too.

As Andrew pointed out, most of us can't afford (monetarily or mentally) the cost of archaic build systems, which is why we use Maven to reduce the complxity down to a manageable level. Lowering the cost of entry is just as important and providing new capability. Many of us are solo developers. We want to be able to focus on developing and delivering innovative products using GWT, not on managing a build system.

William


From: Andrew Hughes <ahhu...@gmail.com>
To: codehaus-mojo-gwt-...@googlegroups.com
Sent: Fri, 25 June, 2010 2:11:02 AM
Subject: Re: What's happening with GWT-Maven 1.3 vs GWT 2.0?

Milen Dyankov

unread,
Jun 25, 2010, 4:07:26 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
I have not used GWT for quite some time and have not experienced the
problem myself. However this post made me think if someone has
bothered to create an issue or add a feature request to GWT.
Quick search showed there are 27 maven related issues
(http://code.google.com/p/google-web-toolkit/issues/list?can=2&q=maven)
of which at least the following two may be related to this subject:
- Issue 4484: declare dependencies rather than embedding in
distribution JARs
(http://code.google.com/p/google-web-toolkit/issues/detail?id=4484)
- Issue 4673: GWT jars should be in the MAVEN repository ?
(http://code.google.com/p/google-web-toolkit/issues/detail?id=4673)

Surprisingly only 2 and 4 people respectively have voted for those
issues. Don't know how important is the number of votes for Google but
if it is considered in the same way as in most open source projects,
it clearly indicates low interest in this subject. Perhaps mobilizing
gwt-maven community to vote for above issues (create new ones if
needed) may be the signal Google needs in order to consider maven
compatibility,

Regards,
Milen

nicolas de loof

unread,
Jun 25, 2010, 4:18:36 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
You're right, we lack feedback to GWT team about the size of the maven user base

2010/6/25 Milen Dyankov <milend...@gmail.com>

William Ferguson

unread,
Jun 25, 2010, 5:42:14 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
OK, let's get busy and star those issues of most concern.



From: nicolas de loof <nicolas...@gmail.com>
To: codehaus-mojo-gwt-...@googlegroups.com
Sent: Fri, 25 June, 2010 6:18:36 PM

Jesse Farinacci

unread,
Jun 25, 2010, 8:30:30 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
Greetings,

On Fri, Jun 25, 2010 at 4:07 AM, Milen Dyankov <milend...@gmail.com> wrote:
> - Issue 4484: declare dependencies rather than embedding in
> distribution JARs
> (http://code.google.com/p/google-web-toolkit/issues/detail?id=4484)
> - Issue 4673: GWT jars should be in the MAVEN repository ?
> (http://code.google.com/p/google-web-toolkit/issues/detail?id=4673)

Also important is:

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

This type of problem where the Google developers are making things
easier for non-Maven enabled projects are really hurting the Maven
community. Bundling dependencies like javax.servlet.* is probably the
most classic issue. I think awareness and starring issues is good, but
it isn't like the GWT project is unaware of us. They've fixed many
issues in the past and overall I think support is improving.

The partnership with Spring should help too as they are quite keen on
Maven too. :-)

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

nicolas de loof

unread,
Jun 25, 2010, 9:26:41 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com

The partnership with Spring should help too as they are quite keen on
Maven too. :-)

-Jesse

I also hope so, but remember Spring itslef moved to Maven based on customer presure, not for internal developments. Spring core uses Ant and Ivy for a while and it's core developers don't like Maven (based on discution I've got with them at SpringOne 06). For this reason I can't see them as first ambassadors of Maven.

Jason Van Zyl is allready in near contact with Google and helped them to setup a maven repo to publish artifacts, but I still don't see changes in the way they publish releases.

Jesse Farinacci

unread,
Jun 25, 2010, 9:55:38 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
Hi,

On Fri, Jun 25, 2010 at 9:26 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> with them at SpringOne 06). For this reason I can't see them as first
> ambassadors of Maven.

Well, all the rage at Google IO was to use Spring Roo for creating
GWT-2.1+ applications. Spring Roo creates Maven projects, there may be
some option to create Ant projects too, I'm not familiar enough with
it. So while many Spring developers may have reluctantly provided
Maven support, I think it is inevitable. :-)

> Jason Van Zyl is allready in near contact with Google and helped them to
> setup a maven repo to publish artifacts, but I still don't see changes in
> the way they publish releases.

That's cool, I wasn't aware of that. I personally don't see any point
in converting GWT developers into Mavenites, but providing a proper
pom.xml with appropriate contact, license, and dependency information
seems both easy to do and good netizen. Perhaps as a requirement of
that final point is that GWT should split their dependencies properly,
or do some sort of jarjar renaming as was suggested by you or someone
else..

Andrew Hughes

unread,
Jun 25, 2010, 10:54:19 AM6/25/10
to codehaus-mojo-gwt-...@googlegroups.com
Voting seems like a logical process. Perhaps, we could add some of the "suggested votes" we would like to raise awareness of by putting these on the gwt-maven site?


--

Andrew Hughes

unread,
Jul 5, 2010, 9:33:54 AM7/5/10
to codehaus-mojo-gwt-...@googlegroups.com
There's some evidence to suggest that SpringRoo is making a difference.  The SpringRoo issue taker has several maven related issues, but I can't see what the "fix" is... I just hope it's a move in the right direction

Jason Thrasher

unread,
Jul 5, 2010, 2:33:01 PM7/5/10
to Codehaus Mojo gwt-maven-plugin Users
Ya, I'm playing with Roo with the hope if finding some faster
development methods. It seems that Google's strategy with GWT is
turning to aim more at the "enterprise" developer. Google I/O was
full of examples targeted at enterprise, and the words "roo" and
"enterprise" were often used in the same sentence. If you haven't
used it, it's worth a whirl, if at a minimum to make an assertive
rejection (which I haven't done yet).

More to this thread, is it possible to reach out to Google, rather
than have them come calling? I bet they are also strapped for time
internally with their own aggressive milestones. I don't get the
impression that they're sprinkling fairy dust and grown amazing
products. I think the best way to get GWT2.0+ and the plugins
working, and making everyone's life easier, is simply to get vocal and
involved. Giving everyone the benefit of the doubt helps too.

best regards,
Jason

Reply all
Reply to author
Forward
0 new messages