Being that it's very simple to create a project on the google project
hosting, we use that to track issues. I just went and created a
project gwt-issues where we could all post to (along w/ real code
snippets and files).
Honestly, I don't have any intention of moderating it and there is no
code associated with this particular project, but I would strong
encourage google to please take control of this project and actively
At least this would provide developers a temporary outlet to organize
The URL to submit issues:
you have touched on a core issue that enables us all to observe a
number of related tension points.
>The URL to submit issues:
why stop there?
cause: there are people in this group that want to report defects with
complete test-cases (see Mat Gessel's largely unrecognised, yet
effect: MG publishes a executable test script on his site and then
posts a codified test-case to this group. (should all MVP volunteers
suffer such pain?). then us old time gwt'ers poll the gwt group
regularly for posts by MG with included test-cases.
preferred-effect: give MG commit rights to a community branch of a
gwt-commons::gwt-user library subsystem
cause: there are people in this group that make hacks into the runtime
library b/c they _need_ to fix problems or need to develop new features
in order for their deployed solutions to run effectively for their
effect: there are now many widget libraries and/or framework extensions
(including yours, robs, mine etc - http://www.gwtpowered.org/#Widgets).
whilst we all have different motivations, we mostly share common goals,
and we all suffer port issues for each gwt release. our consumers rely
on us to have resolved dependency issues, and for things to just work!
preferred-effect: there is a great pool of talent in this group, yet
our only effective collaboration is this forum. imho, this represents a
resource that is uncoordinated, self-driven, and its lack of
orchestration least benefits the overall gwt community.
i believe we should form a team. that team should be committers to a
gwt-commons project. that project may spawn several sub-projects, but
all are coordinated and managed releases. one sub-project should be the
gwt runtime where the team can make fixes or key enhancements to
gwt-user library. this gwt-user library is what all gwt-commons
projects should have a dependency on. the google gwt-user library team
can run diff reports and we can enter into concrete discussions with
the google team on modifications/enhancements with sample code, _real_
projects and/or test-cases that exercise these requirements. this team
should be able to collaborate with the gwt team to know when upcomming
gwt release's with compiler or emulation subsystem updates will cause a
forced gwt and gwt-commons sycnhronised release.
finally there are those that have either 1. identified an issue and
want some sort of response, or 2. currently lack the experience or have
no bandwith to develop gwt extensions for new features.
effect: post to this group raising an issue or feature request and hope
that it gets picked up in someones roadmap.
preferred-effect: know googles roadmap for gwt-user and be very clear
about the concerns/scope that the gwt team intends on addressing. eg.
is the google gwt team planning on developing a complete rich set of
widgets (eg. Coolbar, CTab, etc). is there going to be a gwt gui
builder etc. know what the gwt-commons project roadmap is and be very
clear about the concerns/scope their sub-projects intend on addressing.
once the community is clear about scope boundaries, the issues and
enhancements can be discussed with people that care and plan to address
it within a known time window. how many more GWT OSX posts do we need
to see in order to realise that this concern is not a priority on
anyones roadmap. yet, clearly there are people in this group that are
self-motivated to resolve this issue but nothing has been done -
another example of not harnessing the talent in this group.
just as you created http://code.google.com/p/gwt-issues/issues/list to
address a community issue, i created
http://code.google.com/p/gems-gwt-user/ some time ago address the
issues i discussed above. however, what i have discovered is that an
issues list, or codebase is not enough. what is needed is an
orchestrated team that shares the same goals and whose scope boundaries
are coordinated with the gwt team.
best wishes ash
Let's face it, we haven't been doing a good job of managing issues,
particularly in the area of public visibility. I totally understand
and respect your desire to underscore how important this problem is to
So what are we doing? We're are (big surprise!) migrating our issue
tracking to Google Code project hosting in the very near future. This
will give you all the ability to report issues more directly, and we
are hoping it will resolve many of these visibility/transparency
You may know that at Google we're not in the habit of pre-announcing
things that aren't done, but since you guessed, I figured I might as
well let the cat out of the bag. We expect to make the transition in
the next couple weeks, and we will keep you posted here.
Thank you, Scott.
While I generally agree with this strategy - it is one of the hallmarks
of making a good first impression - not all aspects of a project's
evolution qualify as announcements. Things of interest to the
community, I think, include:
1) Aspects or features that are understood by the GWT team to be
desirable but not within the scope of the project due to resource
restrictions or time constraints. This is a perfect place to encourage
community projects since the GWT team would implicitly support such
efforts without having to commit to them.
2) A general roadmap, though this doesn't have to be very explicit - it
could just be a wish list in order of priority - with no timeline
commitments. Some things of potential strategic value may be ommited or
simply declared as 'secret way of dealing with X'. A casual post that
says something like, we are working on a few things, including A, B, C
in the near future is not an announcement in my opinion but
communicates intention to the community, which can then plan accordinly
and engage in project that are synbiotic rather than uncoordinated.
3) Real open source, with a meritocracy of committers. This is a touch
problem but Sun's community licence approach and transparency in J2EE
and Java 6.x seems to be working well, while allowing them to retain
the necessary IP protection they need from a business standpoint.
Arguments for or against asside, a similar model would help expedite
bug fixes if nothing else.
To be fair, I'm still personally pleased with the quality of design and
releases in GWT, though perhaps less so with architectural
documentation, but the main point of this thread that I think deserves
emphasizing is that the community consists of some pretty savvy
individuals that are motivated to help and they should be leveraged to
maximum effect. If I were part of the GWT team, I'd be working very
hard to get that brain trust working on my problems instead of
dissipating energy into the ether.
The third point, however, I am not sure. Sure, I like the idea of a
meritocracy of committers, but the Sun example is bad in my view. Sun
itself has decided that they should license their work under a real
open-source license and are in the process of doing this, therefore
admitting that the current approach should be improved.
Having said that, I think things should be done in small steps. And the
GWT team is moving in the right direction from what I can see. Sure, it
still seems like when it comes to plans, they won't say anything until
several people ask the same question repeateadly. But, maybe once they
migrate their issues to the public tracker, this situation will
improve. By the way, does anyone knows what is being worked on for the
next release? ;)
Perhaps some features can be tested via an open source development
process that folds valid desings into the core, as approved by the GWT
team at Google. Maybe somthing like 'Friends of GWT' would be
sufficient to accomplish these goals.
A clear example is support for Drag and Drop, whcih was listed as a
requested feature on the first day and has remain unimplemeneted on the
todo list. I'm not saying it needs to be (I've already written my own)
but I'd be willing to refine it, open it up, align it with a more
standard Swing and/or SWT model and then propose it for eview as an
addition to GWT, in order to aleviate the work on Google's side if I
knew there was even a remote chance that it would not just end out
outside the framework, only to be reinvented ad nauseum.
My goal is merely to stimulate a dialog not to criticize. As I've said
before, the GWT team is doing an admirable job. Nothing is ever
perfect. I'd just like to jump in an help more effectively meet common
goals for the framework, perhaps as an extended team member (as I'm
sure others would be willing to do). Maybe we need to send our resumes
to Google ;-).
> standard Swing and/or SWT model and then propose it for eview as an
> addition to GWT, in order to aleviate the work on Google's side if I
lately i been rethinking the widget component library. ive spent a lot
of time investigating josson's work on http://j2s.sourceforge.net/
which essentially lets you build a swt application and render it in
that lets you remap swing api to an alternate implementation (in his
case swt). finally there is chris's work on
http://swtswing.sourceforge.net/main/index.html that lets you go in the
with two well established widget frameworks already available in the
java realm and with two open source projects that have abstracted both
of those frameworks and provided alternative implementations, can't it
be argued that we could avoid re-building all the widgets and
drag/drop, drag/dock already available in the desktop world and have
them ported to gwt?
but then again you could be a cynical bugger like me that has never
enjoyed java gui development since their delphi days and prefers to
port a different component model. perhaps im the only one that wants
gwt development to be as simple as client/server development a decade
The other key difference is a mixed metaphor, I think. Web apps are not
desktop apps and so idioms like flowing columns should probably be
retained while attempts at conforming to desktop idioms are often
counter-productive and end up looking boxy or constrained. I for one,
really dont want to re-invent Windows 3.0 for the browser. Think that's
the wrong way to go. A windowing system is good, but not one that tries
to be too desktop-ish if it's at the exclusion of recognizing that you
are still running in a browser. We still have to shape this generation
of applications, I suspect.
I agreee with all your other points WRT duplication of projects and
unnecessary re-invention though.
> The other key difference is a mixed metaphor, I think. Web apps are not
> desktop apps and so idioms like flowing columns should probably be
good point! i do however feel that there are two sterotypical kinds of
rich internet apps (ria); 1. enterprise ria and 2. public ria.
the key difference in my mind is that the enterprise ria is domain rich
and is rendered more along the lines of a traditional desktop
application. in contrast, the public ria is domain simplified and
strikes a balance between broshureware and desktop.
> retained while attempts at conforming to desktop idioms are often
> counter-productive and end up looking boxy or constrained. I for one,
> really dont want to re-invent Windows 3.0 for the browser. Think that's
> the wrong way to go. A windowing system is good, but not one that tries
> to be too desktop-ish if it's at the exclusion of recognizing that you
perhaps your seeing and developing a public ria or a different
stereotype of application. the two gwt applications that ive been
involved with fit the enterprise ria stereotype which may well be
clouding my views. however, i am interested in whether you have used
the google portal (see. http://www.google.com/ig) and its gadgets. now
when we consider the classic "drag and dock" desktop concept and the
gadget portal, there is little difference in my mind. I feel that there
is a real convergence, and the realisation is differentiated by the ria
> are still running in a browser. We still have to shape this generation
> of applications, I suspect.
i agree. there is so much that is similar to the past but with
differences. there are new constraints and a higher expectation on
> I agreee with all your other points WRT duplication of projects and
> unnecessary re-invention though.
good luck with your application at google :-)
In an enterprise environment, there is typically more control over the
technology deployment scenario, so I would be more inclined to use
Swing, a more mature and capable technology. Most of the problems that
GWT adresses have to do with low-bandwidth, ubiquitous deployment at
the consumer level. I'm not saying this can't be applied in-house, but
the arguments are not as compelling.
> the google portal (see. http://www.google.com/ig) and its gadgets. now
> when we consider the classic "drag and dock" desktop concept and the
> gadget portal, there is little difference in my mind. I feel that there
> is a real convergence, and the realisation is differentiated by the ria
This re-enforces my point. You'll notice that Google's Gadgets,
pageflakes.com, netvibes.com, etc all use a columnar format, consistent
with the web idiom, while adding windows for hosting content. This is
more like a rich portal interface than a desktop application. One key
difference is a limited use of the z-axis in web apps, no window tiling
or cascade functions.
The browser environment needs to co-exist with a real desktop and
unless you can drag across the browser-desktop boundary, there is no
real integration and thus too much user-confusion if they become too
much alike. I"m not saying this is a good thing, but it is a fact of