On Monday, May 9, 2016 at 5:39:36 AM UTC+2, Colin Alworth wrote:
>
> 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.
>

JavaPoet is orthogonal to that; it's a tool to help generate Java code; it 
can be used in GWT Generators today, or in annotation processors, or in any 
other tool that needs to generate Java code (e.g. generate Java classes 
from protobuf definitions, from the command-line or a Maven 
plugin: https://github.com/square/wire )
If you want tools to make it easier to work with/in annotation processors, 
I'd recommend Auto-Common from Google: https://github.com/google/auto
 

> Neither, apparently, has anyone else - AutoBeans/RequestFactionr,
>

I've been thinking about this for years (literally), but don't have the 
bandwidth and motivation (part of the work would also be to replace dynamic 
java.lang.reflect.Proxy in the JVM with generated implementations; reusing 
client-side code as much as possible; that was my main motivation initially 
actually, to make it easier to debug things in the JVM, not to replace the 
GWT generator)
 

> I18n, UiBinder, ClientBundle,
>

Those have dependencies on non-Java files, so annotation processing is not 
really a good fit; it can (and would) work, but incremental build tools 
would need to re-trigger Java compilation when non-Java files change. This 
is the tricky part (easy with Gradle –a one-liner–, trickier with Maven for 
instance)
 

> and even the base UserAgent wiring are all generator-based
>

That one would likely move to JSNI/JsInterop and system properties 
actually; but it's currently too linked to the concept of "permutations" to 
be efficiently refactored I believe.
 

> - in fact, my SafeHtmlTemplates 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fniloc132%2Fgwt-safehtml-templates&sa=D&sntz=1&usg=AFQjCNF69qn-tG4gP-umaRzPu9ed1oPrRQ>
>  generator 
> is the only one that I'm aware of that has been ported, at least publicly.
>

Also https://github.com/tbroyer/gwt-places (announced 
here: 
https://groups.google.com/d/topic/google-web-toolkit/jbOWVAYGwqU/discussion)
 

> 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.
>

+1

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f00d1b23-530c-49f0-be84-ddca78764e97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to