> > Usually, internal APIs are in a package named "internal" because they are > subject to change and the architecture is still not clear (the first > iterations usually). >
IMHO it is totally irrelevant if a package is named internal or not. If the API in that package is public then its public and if that API is useful it will be used no matter what. Just imagine GWT would open up the possibility for custom UiBinder parsers so that custom widgets can provide advanced UiBinder elements. I am pretty sure that 3rd party UI libraries will use such an API even if its "internal" just to provide better experience for users of such libraries. And I am also pretty sure that users of such libraries will not realize (maybe they are not even told) that they now depend on GWT internals and that they can not update GWT if these internals have changed and the libraries they are using have not been updated yet. So you may guessed it: I believe that using access modifiers to lock down internals is a lot better. You can always unlock it if its reasonable. I was thinking about Ubuntu that raises the xx.04 versions that are > maintainable for some years and the xx.10 versions that are more > experimental. Having a similar model for GWT with the community releases > and the incubator releases might be an answer to permit both a stable and > head and a dynamic community move?... I wouldn't like to reinvent the > wheel, I'm wondering what can be done to allow the community to feel like > home on the GWT project. Ideally, people should be able to try patches > independently (somehow as plugins) and the GWT team can have visibility on > the most popular patches that might be candidates to the head version (or > are worth thinking on how to specify them cleanly). > Actually I think the best way to let people try features that are not in GWT trunk is to create a GWT fork at Github and let people know about it. This has already been done a few times (Java 8 support, proof of concept for improved GWT.create(), Gradle build script for project imports, ..). There is a gwt-sandbox project on Github that tries to bundle interesting ideas: https://github.com/WeTheInternet/gwt-sandbox Also a problem is the fact that the GWT team is actually smaller than you might think. A community patch that introduces a new feature must be maintained and if a community member looses interest in GWT and his/her feature the GWT team is probably the one to pick that up or it becomes unmaintained code like GWT's bean validation. That can become a burden and thats why they prefer new features as independent libraries. If a library is only possible with some changes in GWT then they will listen and see what can be done, however in your case you hit a bad spot with UiBinder. Take as an example what I'm adopting now (for the bug I submitted): I > prefer to change the GWT core code locally and maintain my code working on > the core code each time a pull a new version than copying the GWT classes > to my own library where I will have to do manual comparing of which class > became what in the next GWT version (loosing the git history of the files). > You should create a fork of GWT so you can rebase your patches onto a new GWT release / trunk commit. Thats a lot easier than copying source from GWT into your project. I have done both and the git rebase approach is a ton smoother. -- J. -- 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/3700becf-f884-489f-b625-d6afc2c4dc3c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
