On Tue, Sep 4, 2012 at 11:53 PM, Ray Cromwell <cromwell...@google.com> wrote: > Thomas, thanks for all of the work on this, but we will have to delay > this until after we get the open-source git/gerrit repo up and > running.
No problem (no, really!) Someone had to do it and I was in the mood for it; and the patch should apply equally well even in 3 months from now. It was more a matter of preparing the work and just having to "press the button" when we think we're ready. > A preliminary investigation of internal Google apps shows a > bunch of them still relying on EventListener, so we'll have to create > an uber-patch to fix all of them or give internal teams a lead time to > fix their usages first (under the current 'Google builds everything > from trunk' process). When we move to the announced process, than > landing stuff like this should be easier. It would also be possible to produce 2 GWT versions (would be easier once we move to Maven), one with the legacy stuff and one without, similar to how Guice produces versions with and without AOP. Ideally, the "light" version would be the only one released as binaries, and Google could use the "legacy" version (given that you build from source anyway). Others who would like to use the legacy stuff would have to compile from source (as an incentive to really move away from deprecated APIs). It would only be a matter of compiling with or without the "legacy flag" (in Maven, using a different profile, even if that's not how profiles are intended to be used). As another alternative, the widgets could no longer implement Sources*Events/Fires*Events and the add*Listener/remove*Listener be removed, with the ListenerWrapper and all *Listener interfaces pushed to a dependent module. It would provide an easier upgrade curve for Google projects: replace all addClickListener with ListenerWrapper.WrappedClickListener.add, and similarly for other listeners, and replace methods that return or take a Sources*Listener as argument with generics and/or with Object and instanceof checks + casts. I suspect most of this could be automated (with the appropriate regexps). That however raises (once again, as I believe I already talked about it) the question of how we want to manage deprecation/removal of APIs/features. I kind-of like the rules used by Guava: @Deprecated features go away after 18 months, @Beta features (equivalent to our "EXPERIMENTAL" APIs) can go away at any time (though they generally are @Deprecated before that, but without the 18-months notice); https://code.google.com/p/guava-libraries/wiki/PhilosophyExplained#Iteration I don't really mind whether we choose 18 months, or 2 years, or 1 year, or 2 releases, or whatever; what I really like is that there are clear rules. But this is more a question for the Steering Committee. -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
