Thanks everyone. Since we don't really have much of a consensus on this, perhaps we can take some middle ground here?
I certainly agree that we want people to move away from generators in general, though without finished solutions for some of the tricks generators can do, this will be tricky. Additionally, APT is not exactly a terribly user-friendly option - while I have managed to port a very small GWT generator, I wasn't enjoying myself, and am unsure how a larger project would be addressed and sanity retained. I have heard great things about JavaPoet, but have not yet had the time to learn enough of it to make another attempt. Neither, apparently, has anyone else - AutoBeans/RequestFactionr, I18n, UiBinder, ClientBundle, and even the base UserAgent wiring are all generator-based - in fact, my SafeHtmlTemplates <https://github.com/niloc132/gwt-safehtml-templates> generator is the only one that I'm aware of that has been ported, at least publicly. If weren't not prepared to set an example on how to generally solve this, I'm unsure how strong of a position we can hold. Along the same lines, I agree that official work toward generators doesn't make any sense, and that instead work generally should be directed toward general solutions to our property/permutation and linker problems (features which will vanish with APT and J2CL as far as I can tell, with nothing yet set up to replace them). I'll generally agree that we should stop updating GWT-provided generators, though we certainly haven't yet stopped - over the past 12 months at a very brief glance at history, Thomas made changes in a year ago and in October, Julien made changes in June, October, December, I made changes in Feb. Some of these were purely bug-fixes, but about half of the changes actually appear to be introducing new features. It doesn't appear to be our position that further enhancing generators is contrary to our message. My proposal is that first, the change I've submitted only removes unneeded (and arguably broken/meaningless) code - I don't see a position where it makes sense to keep it and refuse the patch. Second, future work can be discussed, but actively forbidding contributions for fixing or improving existing code would require deprecating these classes and aiming to have them moved to their own jars, perhaps to be maintained externally. As opposed to my first point, I can see some wiggle room in this policy, but refusing changes merely because they improve a generator seems silly at best, especially when we have actively improved existing generators up until now. (Most of the examples I can come up with are pretty gratuitous and don't really make sense, but static or default methods in place of categories seems a natural fit for a hacked in feature that can be replaced with the real thing.) Finally, if we are to be serious about this, as a GWT user, contributor, and steering committee member, I have to expect to see usable solutions in the near future to move away from these tools. This has to include tutorials on setting up APT to play nicely with SDM in reasonable development environments, a pathway for non-GWT generators to move in, and clear evidence that we are not simply abandoning all existing generators that are part of GWT itself. More than any other thing we are doing around this topic, _this_ is our messaging problem, and efforts to solve it there will be a lot clearer for users than closing bugs as WONTFIX or refusing patches. The first is to allow the community the freedom to continue to improve before new tools are available, the second recognizes that contributor time is not a zero sum game whereby refusing commits will make other work magically work faster, and the third brings these new tools into the limelight as soon as possible. Ten years of constantly improving generators aren't going to be counteracted by ignoring fixes - we need a better approach. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6cc035bd-b89b-4079-ab8c-b03cf23241e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
