On Wednesday, March 13, 2013 5:31:25 PM UTC+1, Ray Cromwell wrote:Hey guys,Google I/O is almost upon us, and it's been a year since we started GWT steering. I feel like if there's one big thing we could announce this year that people would love, it would be the opening of the external commits combined with mavenization.+1It seems like we have a number of people interested in rolling up sleeves, and I think if we could finish dis-entanglement, then we could actually work in parallel in doing poms for many of the pieces of it and finish rather quickly. I volunteer to spend some late nights helping out.Maybe someone could produce a quick status / overview of the current state and what the remaining problems are.My goal was to get gwt-junit so we can run the tests in other modules (create gwt-core-tests, gwt-rpc-tests, etc. and for the other modules not used *by* gwt-junit then simply depend on gwt-junit and run the tests in the module itself). I'm almost done but my working tree is a bit of a mess (with other things started but unfinished, etc.) Let me get to a clean state this week-end and push everything to my gwt-sandbox GitHub repo, then we can work in parallel on the remaining modules.Last I checked, the remaining issue was with gwt-i18n; there are intricate dependencies: i18n depends on safehtml, but the SafeHtmlTemplates generator uses a base generator that depends on GwtLocale (oh, and SafeHtmlUtils depends on c.g.g.http.client.URL, under a GWT.isClient() check). I had a discussion with John Tamplin about it back in December (Ray you were in copy, it was a private follow-up to the "Disentangle module dependencies" review) and he was proposing having I18N (and SafeHtml and RequestBuilder, or at least URL) in gwt-core. I'm not opposed to it and that would probably simplify a few things; what do you think?The next step will be the tools, samples and the SDK distrib (and of course continuous integration).One thing that can be done in parallel with my ongoing work right now is to deal with the external dependencies and possibly start deploying the missing ones to Central (or another Maven repo as a sandbox), so we can reconcile them with the current POMs that use scope=system dependencies.As a side-note, I have a new gwt-maven-plugin written from scratch that provides gwt-lib and gwt-app packaging with (what I hope are) sensible defaults for GWT projects. I would like to move it to GWT proper and use it for GWT's own modules *and* release it at the same time as GWT for global consumption.One feature I've added recently is a way to automatically generate a gwt.xml file from the Maven dependencies (based on a META-INF/gwt/mainModule found in these dependencies), with optional "extra inherits" (for those dependencies that don't have the mainModule file or that provide more than one module), rename-to and entry-point class. The remaining open question is where to put the rest of the module configuration: either have a src/main/module.gwt.xml and merge the "inherits from dependencies" in it (and remove the "extra inherits" and entry-point from the POM configuration; the "short module name" can still be useful for application packaging), or put everything in the POM. For now I generate a minimal gwt.xml, and if you want more you just disable the generation and provide the full module yourself (and lose the "inherits from dependencies" feature).You can check it out at https://github.com/tbroyer/gwt-maven-plugin and I intend to release an alpha this week-end so people can start evaluating it. The earlier we use it in GWT, the simpler the POMs will be, saving us a few hours of work (and we'll have an official Maven plugin, even if experimental in the first few releases).Also, one thing to discuss asap is where to put the sources: say I have lib-shared and lib-client, would you bundle the sources of lib-shared into the lib-client JAR or rather just have a dependency from lib-client to the lib-shared:sources? Would there be an impact on compilation time? For now, I used the maven-dependency-plugin to unpack the lib-shared sources into lib-client and bundle them in the lib-client JAR; and I have a similar thing done automatically in the gwt-maven-plugin (just use a dependency with type=java-source and it'll be unpacked and bundled; type=java-source dependencies are not transitive, contrary to classifier=sources ones, whereas resolving to the same JAR in the repository). Moving to the gwt-maven-plugin would simply the POMs a lot, but if we prefer not bundling them in the lib-client JAR, then we can simplify the POMs without necessarily using the gwt-maven-plugin, and I can possibly removing the feature from the plugin.Anyway, we're getting technical, so we should move that discussion to gwt-contrib so others can contribute (note to non-steering-members reading this: if you want to chime in, follow-up directly to gwt-contrib)--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit Steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-steering...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Sunday, March 17, 2013 8:06:00 AM UTC-4, Thomas Broyer wrote:Also, one thing to discuss asap is where to put the sources: say I have lib-shared and lib-client, would you bundle the sources of lib-shared into the lib-client JAR or rather just have a dependency from lib-client to the lib-shared:sources? Would there be an impact on compilation time? For now, I used the maven-dependency-plugin to unpack the lib-shared sources into lib-client and bundle them in the lib-client JAR; and I have a similar thing done automatically in the gwt-maven-plugin (just use a dependency with type=java-source and it'll be unpacked and bundled; type=java-source dependencies are not transitive, contrary to classifier=sources ones, whereas resolving to the same JAR in the repository). Moving to the gwt-maven-plugin would simply the POMs a lot, but if we prefer not bundling them in the lib-client JAR, then we can simplify the POMs without necessarily using the gwt-maven-plugin, and I can possibly removing the feature from the plugin.
For my company, I created a new "gwt-jar" packaging type that contains both the compiled class files and the source files. In addition, I created two new artifact types: gwt-module (for client code) and shared-module (for shared code). The former generates a gwt-jar, whereas the latter produces both a generic jar (i.e. no sources files) and a gwt-jar. Client modules then declare dependencies to the gwt-jar versions of shared dependencies, while server modules declare dependencies to the shared-module versions.The major drawback of this approach is that you need two dependencyManagement entries per shared module, but this could be worked around if the plugin automatically resolves the gwt-jar version of every shared-module dependency.
Not sure if this is really the best way to handle the situation, but maybe there are some ideas that are worth considering.
A question concerning the partitioning of the code... Will this exercise help allow for code splitting of the GWT libraries? Even with severe code splitting, I am not able to reduce the initial load size to below a megabyte which is prohibitive for a mobile device.
Hi folks,I read and hear about the Maven-ization of GWT, which is something I would love because I love maven.
However I've found it difficult to understand what does it means...I've checked out the latest source code and I see it is still based on ant build...On the repo there is only a "master" and "google/pu" branches and I don't see any trace of a pom.xml file.Where can I find a branch of a maven-ized GWT?
If maven-ization is not moving the build system to maven, can you please kindly explain what it means?
I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle.
It means two things:
- replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools)
- modularizing GWT in much smaller and non-overlapping parts than gwt-dev and gwt-user (and gwt-servlet, and requestfactory-*), those parts would also declare their dependencies on third-party tools rather than bundle them. This will make GWT easier to use as a "managed dependency" (Maven, Ivy, Gradle, SBT, etc.)
It means two things:
- replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools)
I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle.wow,I know it could cause issues if not used in the proper way, I have now addressed multiple issues and I'm very satisfied with maven even if I continue to improve it day after day. Apache Camel and Apache CXF are two open source projects with a very mature approach to Maven, and I've found many good practices and inspiration looking into their sources.
Do you mind telling me why you don't love it anymore? Hopefully, as I would love to sponsor Maven, I can give some good hint...
Unfortunately very out of date…cloned! it is big but I'll have a look at it.It means two things:
- replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools)
- modularizing GWT in much smaller and non-overlapping parts than gwt-dev and gwt-user (and gwt-servlet, and requestfactory-*), those parts would also declare their dependencies on third-party tools rather than bundle them. This will make GWT easier to use as a "managed dependency" (Maven, Ivy, Gradle, SBT, etc.)
Exactly what I mean for Maven-ization !I'm sorry you got to a dead end, I'm really curious to know what stopped you to see if I can help.
On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer <t.br...@gmail.com> wrote:It means two things:
- replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools)
Yeah, I guess that is why I spent half of yesterday getting a build to work in IntelliJ when it worked running from the command line. I have had similar issues with Eclipse before.Maven is great when it works, but you are just SOL when it doesn't. You resort to deleting your .m2/repository, re-importing maven in your IDE, deleting your IDE project and recreating it, etc and (hopefully) it just starts working again and you have superstitions about what actually fixed it (so asking others for advice you get totally different suggestions for how to fix it, none of which actually fix it by themselves). That is before you even get into all the useless work that Maven does, such as downloading stuff to find out there is no work to do.
On the contrary, I have never once had an issue with ant, so I have no idea why people say Ant is hard to maintain.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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-co...@googlegroups.com.
I don't like that it is still required to have the gwt-tools in the environment path;
referring to the your post ;-) for me the ultimate build tool is the one that allow you to build a project in two steps:[me@host]# ultimate-scm checkout http://my.project.org/source_code trunk[me@host]# ultimate-build-tool build trunkhaving to configure gwt-tools it is out of my ideal way of building a project: I don't know if it possible, but gwt-tools should be mavenized too in my opinion. Many libs found inside the gwt tools are available as maven artifacts in Maven Central Repo (for stability, I always try to avoid referring dependency not found on http://search.maven.org/) but this may requireLater I also want to try out your buck build files at https://gwt-review.googlesource.com/3741,(if I find out how the command line options to apply the patch :-D) so to compare the buck output.
Just let me know if you want me to continue providing feedback, here ore somewhere else, or I will make some tests by myself and only give news in case i achieve something useful.
--
The biggest problem with being a GWT contributor today is that it is hard, very hard, to set up an environment to develop. If you look at the original GWT instructions for Eclipse, and that was *with* already provided .project/.classpath files, it was ridiculous. Starting from scratch is even harder.My dream for mavenization wasa) fixing the spaghetti soup of cyclic dependencies so that IDEs would have less trouble modeling the project layoutb) having a cross IDE platform representation of the project
The way GWT exists today, after years of working with it, requires me to spend over an hour configuring a new IntelliJ project from scratch if I want to do it right, be able to develop both user and dev, be able to run unit tests in the IDE, be able to debug the compiler in the IDE, etc.Ant is fine for command line builds, but it sucks for a) and b), and its flexibility has allowed the GWT source tree to have a structure that would not be tolerated by other build tools -- sometimes too much power is bad. I don't have any particular love for Maven, I'd be fine with Buck or Gradle (IntelliJ seems to have some support for Gradle), but the biggest issue for me is, I don't want to spend an hour fiddling with IDE sub-projects, hand-adding library dependencies (oh wait, which project needs tomcat-jk2.jar?), etc.
Even on the GWT team at Google, members have taken to rather absurd techniques like creating one working set of IPR/IML files, and copy/pasting them everytime you start a new repository or branch because they have often forget the precise order of magic tricks they used to set up the build the first time.
IMHO, here should be how someone contributes to GWT:git clone http://some-repoIDE open-project some-repogit branchhack hack hackrun tests/debug in IDEgit commitgit pushAny more steps than that and I think you've lost.
--
Hi Thomas,
today I've tried to test the build with buck, but it has not worked for me...On the root, the command "buck build" asks to specify a build target, while "buck targets" prints lots of empty lines then it rise a "RuntimeException: Not an ordinary file: gwt_tools/lib/javax/validation/validation-api-1.0.0.GA.jar"while on the /user folder running "buck targets" gives a "No such build target: //:servlet-api."(I've used the latest "buck" compiled after a master clone of github, on a Mac OS X with a freshly installed jdk 7 as buck don't run on windows and I didn't had yet java 7 on the mac).Which operative system do you use to build GWT with buck?
--
In terms of Gradle vs Buck models, is there any possibility of writing a tool that takes a Buck build file and produces Gradle files? That would seem like a good option in lieu of waiting for Buck support in IntelliJ and Eclipse. This isn't to say I have anything against Buck, it is literally a clone of Google's BUILD system, and so that would actually help us to have just one set of build files for internal vs external. However, it would be nice not to have to hack the IDE stuff manually.If Buck is like Google's BUILD, then a genrule could be used to download dependencies from Maven repos. ;-)
--
Thomas,In terms of Gradle vs Buck models, is there any possibility of writing a tool that takes a Buck build file and produces Gradle files? That would seem like a good option in lieu of waiting for Buck support in IntelliJ and Eclipse. This isn't to say I have anything against Buck, it is literally a clone of Google's BUILD system, and so that would actually help us to have just one set of build files for internal vs external. However, it would be nice not to have to hack the IDE stuff manually.
If Buck is like Google's BUILD, then a genrule could be used to download dependencies from Maven repos. ;-)
I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle.wow,I know it could cause issues if not used in the proper way, I have now addressed multiple issues and I'm very satisfied with maven even if I continue to improve it day after day. Apache Camel and Apache CXF are two open source projects with a very mature approach to Maven, and I've found many good practices and inspiration looking into their sources.
Do you mind telling me why you don't love it anymore? Hopefully, as I would love to sponsor Maven, I can give some good hint...
--
At Google our BUILD files are distributed throughout the source directories as we try to make them as simple as possible with as strict dependencies as possible. I'd love to have a Buck file that could compile gwt-dev/user/servlet, but it would be even better if there was one for each and every module and important subsystem.The former is important because, we'd likely want to write a "gwt_module"/"gwt_application" plugin for Buck (What Google has internally, they are the equivalent of java_library/java_binary, but run GWT) and to make incremental compilation work, we'd want things modularized in smaller pieces. The latter because, there are parts of gwt-dev people would like to use that are not neccessarily needed in the jar.Is the Buck experiments you're doing working with the trunk as is, or on your de-tangling dependency work you've done as part of the mavenization attempt?
I have been in favor of Buck because that is what most contributors are already familiar with and can bring their expertise.