Re: Maven-ization Status

[Thomas Broyer]

[please follow-up to gwt-contrib]

OK, another trap: Window (WindowImplIE) uses TextResources, Resources (ExternalTextResource) uses JsonpRequestBuilder, which needs Timer, which in turn needs Window (and specifically the thing that needs TextResources); the loop is closed.

I'll have to cut the Jsonp dependency on Timer the same way I already cut the dependency between RequestBuilder and Timer, except that XHR generate an event themselves when the page unloads so it wasn't a problem, but I don't think there's an equivalent for json-p. The alternative would be to move ExternalTextResource to its own artifact, separate from gwt-resources; BTW, moving CssResource and ImageResource out of gwt-resources would also remove the dependency on i18n; not sure what's best…

Sigh…

On Fri, Mar 15, 2013 at 11:56 AM, Thomas Broyer <t.br...@gmail.com> wrote:

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.

+1

 

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

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Andy Stevko]

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.

-- A. Stevko

===========

"If everything seems under control, you're just not going fast enough." M. Andretti

[Thomas Broyer]

On Sunday, March 17, 2013 6:26:20 PM UTC+1, Abraham Lin wrote:

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.

The problem with a "shared lib" producing 2 artifacts is that your non-gwt code doesn't need a dependency on a gwt-jar, whereas your gwt code needs it. For instance, requestfactory depends on events and autobeans; on Android you only need the "VM" implementations, whereas on GWT you need the gwt-jars; even if you depend on requestfactory with classifier=gwt or type=gwt-jar, you won't have an automatic dependency on event or autobean with the same classifier or type. That's just not the Maven Way™ or doing things (rule of thumb: one POM == one artifact).

The way I do it is to have requestfactory depend on event and autobean, and a requestfactory-gwt depend on requestfactory, event-gwt and autobean-gwt (and thus transitively on event and autobean). It gives you a "diamond" dependency graph.

Not sure if this is really the best way to handle the situation, but maybe there are some ideas that are worth considering.

That's what I'm doing in my gwt-maven-plugin: gwt-lib and gwt-app packagings.

[Thomas Broyer]

On Sunday, March 17, 2013 6:52:06 PM UTC+1, Stevko wrote:

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.

It won't have any impact on code splitting. It *should* help with compile time in some cases (reducing the size of the classpath, which GWT scans; depending on what you use), but could have the reverse effect if you use many libs (explosion of the number of libs, slowing done the classpath scanning; but if that's the case we could add workarounds: unpack all dependencies into a folder and only use that folder for the classpath of the GWT compiler)

[Thomas Broyer]

Status update before I go to bed (it's 1:50 AM over here):

• the latest push to GitHub compiles OK (mvn clean install -DGWT_TOOLS=/home/tbr/Projets/gwt/tools -DskipTests)
• tests pass until gwt-junit (but user modules are untested), which fails (I haven't investigated yet).
  
• modules "past" gwt-junit (according to the Maven build plan) include gwt-jsonp, gwt-safecss-client and gwt-safecss-server, gwt-resources and gwt-mockutilities.
• I excluded AutoDirectionHandler from gwt-i18n-client as it depends on user.ui (HasText, HasKeyUpHandler, etc.)

I cleaned up the commit history a bit, but it's still quite messy (that's probably not a problem, as I suppose we'll either squash everything to one or a few big commits, or replay the changes)

Note: we quickly discussed with Brian on G+ about how to integrate those changes to GWT proper in the end: https://plus.google.com/113945685385052458154/posts/Sf6bg55vXsa

That's something in the hand of Google though, as we don't want to break their builds; but we're not there yet!

On Sun, Mar 17, 2013 at 1:06 PM, Thomas Broyer <t.br...@gmail.com> wrote:
> [please follow-up to gwt-contrib]
>
> OK, another trap: Window (WindowImplIE) uses TextResources, Resources
> (ExternalTextResource) uses JsonpRequestBuilder, which needs Timer, which in
> turn needs Window (and specifically the thing that needs TextResources); the
> loop is closed.
> I'll have to cut the Jsonp dependency on Timer the same way I already cut
> the dependency between RequestBuilder and Timer, except that XHR generate an
> event themselves when the page unloads so it wasn't a problem, but I don't
> think there's an equivalent for json-p. The alternative would be to move
> ExternalTextResource to its own artifact, separate from gwt-resources; BTW,
> moving CssResource and ImageResource out of gwt-resources would also remove
> the dependency on i18n; not sure what's best…

I ended up splitting Resources into gwt-resources-core (ClientBundle, GwtDotCreateResource, TextResource, DataResource) and gwt-resources (ExternalTextResource, ImageResource, CssResource).

I haven't upstreamed the change yet (introduces a ResourcesBase.gwt.xml inherited by Window.gwt.xml); it might be a good idea to split Resources.gwt.xml further (CssResources.gwt.xml and ExternalTextResources.gwt.xml with their specific configuration properties), and possibly split the modules at the Maven level too (so that if you don't use ExternalTextResource you're not forced to have Jsonp on your classpath, and similarly if you don't use CssResources you're not forced to have W3C SAC and W3C Flute in your classpath –I assume you'll have I18N anyway–)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Brandon Donnelson]

Good job!! :)

Have a good day,
Brandon Donnelson

+Follow Me

--

[Cristiano]

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?

Thank you,

Cristiano

[Thomas Broyer]

On Tuesday, September 24, 2013 2:41:10 PM UTC+2, Cristiano wrote:

Hi folks,

I read and hear about the Maven-ization of GWT, which is something I would love because I love maven.

I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle.

 

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?

See https://github.com/tbroyer/gwt-sandbox/

Unfortunately very out of date… 

If maven-ization is not moving the build system to maven, can you please kindly explain what it means?

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

[Cristiano Costantini]

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

 

See https://github.com/tbroyer/gwt-sandbox/

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.

Regards,

Cristiano

 

[John A. Tamplin]

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. 

YMMV of course.

--
John A. Tamplin

[Thomas Broyer]

On Tuesday, September 24, 2013 5:48:03 PM UTC+2, Cristiano wrote:

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

http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool/ is a good start. The main issues are the linear lifecycle, badly integrated with reactor builds, and lack of clean incremental builds (particularly with reactor builds, especially when you want to run tests rather than just package). Also, I came to dislike the src/main/java vs. src/main/resources dichotomy.

 

 

See https://github.com/tbroyer/gwt-sandbox/

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.

I stopped because I lack time, and I think the approach was wrong. Ongoing work is at https://gwt-review.googlesource.com/3741 (and previous patch): first cleanly "modularize" the gwt.xml without moving files, then only move files and mavenize.

The work done there is still valid though (and gwt-dev is ready).

[Thomas Broyer]

On Tuesday, September 24, 2013 5:51:33 PM UTC+2, John A. Tamplin wrote:

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.

+1

Except I don't think I ever had any issue loading projects in either Eclipse or IntelliJ.

 

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.

The problem is not Ant per-se, but how its been used for GWT. 

[Cristiano Costantini]

Hi Thomas,

I'm (part-time) having a look at your gwt-sandbox with maven build;

I like the way it is modularized:

gwt-dev-parent

gwt-jsni-parser

gwt-util-parent

gwt-shared

gwt-tools-api

gwt-dev-json

gwt-dev-ext

gwt-user-parent

gwt-core-shared

gwt-core-client

gwt-compiler

gwt-maven-plugin

gwt-regexp-server

gwt-http

gwt-safehtml-server

gwt-codegen

gwt-jetty-launcher

gwt-devmode

gwt-codeserver

gwt-i18n-shared

gwt-i18n-server

gwt-core-server

gwt-regexp-client

gwt-bindery-parent

event

event-gwt

gwt-event-shared

gwt-event-client

gwt-event-logical-shared

gwt-event-logical-client

gwt-safehtml-client

gwt-dom

gwt-i18n-client

gwt-rpc-shared

gwt-rpc-api

gwt-rpc-client

gwt-rpc-server

gwt-browsermanager

gwt-resources-core

gwt-window

gwt-timer

gwt-junit

gwt-jsonp

gwt-resources

gwt-mockutilities

gwt-safecss-server

gwt-safecss-client

autobean-shared

autobean-vm

autobean-gwt

gwt-user

requestfactory-shared

requestfactory-client

requestfactory-server

requestfactory-gwt

requestfactory-apt

gwt-dev

gwt-user

gwt-codeserver

gwt-legacy-parent

I think it is a very precious piece of work!

The build process fails however in resolution of a pugin, 

com.google.gwt.maven:gwt-maven-plugin:jar:2.6.0-SNAPSHOT 

but it is not the 

org.codehaus.mojo:gwt-maven-plugin:jar:2.6.0-SNAPSHOT

is that the one at https://github.com/tbroyer/gwt-maven-plugin ? (maybe it can me moved inside the reactor build of the project).

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 trunk

having 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 require 

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

Have a nice day,

Cristiano

2013/9/24 Thomas Broyer <t.br...@gmail.com>

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

[Thomas Broyer]

No, it's the <module>maven</module>. It's a snapshot/copy of the one linked above.

 

I don't like that it is still required to have the gwt-tools in the environment path;

This is a temporary step in the migration process. The goal is to migrate to non-patched/non-repackaged dependencies whenever possible, and deploy the third-party deps on Central otherwise.

 

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 trunk

having 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 require 

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

There's a "download" section next to each "patch set" giving you the Git commands to checkout, pull or cherry-pick the changes.

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.

Feedback is always welcome! I'd particularly appreciate a review of the POMs (not much which modules I created and what I put into them, more about how each module is built and who module dependencies are managed). I tried to follow The Maven Way™ as much as possible.

[Ray Cromwell]

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 was 

a) fixing the spaghetti soup of cyclic dependencies so that IDEs would have less trouble modeling the project layout

b) 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-repo

IDE open-project some-repo

git branch

hack hack hack

run tests/debug in IDE

git commit

git push

Any more steps than that and I think you've lost.

--

[Brian Slesinsky]

As a stop-gap measure, can you clean up and check in your IDEA module(s)?

- Brian

[Thomas Broyer]

On Wednesday, September 25, 2013 6:20:19 PM UTC+2, Ray Cromwell wrote:

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 was 

a) fixing the spaghetti soup of cyclic dependencies so that IDEs would have less trouble modeling the project layout

b) having a cross IDE platform representation of the project

+1

 

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.

Looking at Gradle currently for work, support in Eclipse is rather good too. IDE support is much more easily done with Gradle than with Maven, because of their design. I'm writing a blog post about my issues with Maven that'll talk about that, will publish it soon.

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.

+1 to what Brian said re. checking the .iml et al. in the Git repo; and add Konstantin as a reviewer ;-)

IMHO, here should be how someone contributes to GWT:

git clone http://some-repo

IDE open-project some-repo

git branch

hack hack hack

run tests/debug in IDE

git commit

git push

Any more steps than that and I think you've lost.

+1

(OK, I wouldn't mind an intermediate "download dependencies once and for all" after the "git clone" if needed; oh, and you should probalby do a command-line build –or at least using "the build tool"– before pushing, but that's a detail, and the current state of the Ant build is the main reason I don't do it today)

[Cristiano Costantini]

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?

Tomorrow I will try to find time to take a look at the POMs. 

If there is something else I can do for you (i.e. test patches), let me know I will try to support you.

Cristiano

2013/9/25 Thomas Broyer <t.br...@gmail.com>

--

[Thomas Broyer]

On Thursday, September 26, 2013 1:47:22 AM UTC+2, Cristiano wrote:

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?

I'm running Ubuntu (13.04).

You have to do a symlink from gwt_tools to your GWT_TOOLS svn checkout, and build gwt-dev first using Ant. Then you should be able to "buck build //user:user". I'll add that to the commit message when I'll update the review.

[Ray Cromwell]

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

--

[Jens]

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

Shouldn't it be the other way around? A Gradle plugin that generates Google build files sounds more logical to me as you have more freedom to adjust the generated files to your internal system. Outside Google no one will really use these buck/internal build scripts anyways (lack of IDE support).

-- J. 

[Ray Cromwell]

It really depends on what Thomas or contributors are going to do, I don't think we have any bandwidth on the GWT team to work on this right now ;-)

--

[Brian Slesinsky]

I don't think direct IDE support for the build system is necessary so long as we can generate correct IDEA and Eclipse projects via commands that everyone can run, sort of like the webAppCreator command. The real question is what language we want the project definitions to be in; it should be something easy to understand, edit, and generate other representations from.

[Goktug Gokdogan]

I have been in favor of Buck because that is what most contributors are already familiar with and can bring their expertise. It is already proved to work well with gwt.

Also the compiler speed optimizations are done and experimented based on the architecture of Buck; especially new stuff that John is working on. That might be another advantage as our assumptions may or may not hold for other systems like maven.

[Ray Cromwell]

Direct IDE still has benefits. Anytime a change is made to the build file that requires regenerating the project, you run the risk of not preserving project settings by overwriting stuff that is stored in those files that is not part of the build, unless your generator has surgical capabiltiy (like the IDE does).

IntelliJ has surgical Maven capability. If you import some dependency, it can automatically offer to add it to a pom file, and if you edit the pom file, it can automatically update the build dependencies in the IDE file. It's just faster roundtripping.

That said, I am not opposed to writing a plugin or genrule for Buck to do this. I would only say that if we are going to move to Buck, a prerequisite is that we restructure the code the way Thomas has been moving to work more like it does in Google3. Instead of one 'dev' dir and one 'user' dir, each subdirectory that houses a major component should have a build file in it. I should be able to rebuild say, the javac/jdt stuff without rebuilding all of gwt-dev while developing. Things need to be more modular.

On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky <skyb...@google.com> wrote:

[Thomas Broyer]

On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:

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.

It would of course be possible, but would a priori require duplicating a bunch of code from Buck (search for all BUCK files, exec them with custom implementations of the build rules, find the "source root" using the .buckconfig's java.src_roots config)

"buck targets --json --type java_library" wouldn't work as it "resolves" the glob() calls, so you'd have to call the tool every time you create a file so it updates the Gradle files to include the new file)

That said, based on Shawn Pearce's experience on Gerrit, I'm not sure having the IDE configured the same way as the build is a requirement (for Gerrit, there's a single Eclipse project with all the sources)

If Buck is like Google's BUILD, then a genrule could be used to download dependencies from Maven repos. ;-)

That's what Gerrit is doing ;-)

(they also “hack the IDE stuff” that way, generating Eclipse .project and .classpath; Buck has built-in support for IntelliJ but it only work if you have BUCK files spread within your project's source tree, rather than a single BUCK file like I did)

Ivy would also work, used as a standalone tool. And a small tool could produce a BUCK file with prebuilt_jar rules for the downloaded dependencies, without the need to handle transitive dependencies manually.

Ivy would also help deploy the generated JARs to Central.

The more I think about it, the more I like the Buck+Ivy combo idea, but it requires building a few additional tools… (IDE configuration, release script, etc.)

I'm just starting to try Gradle for a project at work, if it goes well, maybe I'll experiment with it on GWT (first step: replace Ant with Gradle, then possibly modularize in the same way I did it with Buck, without moving files, then we could decide the best file/folder layout for both Gradle and Google)

[Thomas Broyer]

It would only work reliably if you stick to hard rules in the Gradle files (i.e. nothing fancy). Buck has a much simpler model than anything else, declarative at a (relatively) high level (a java_library has srcs, resources and deps and produces a JAR) and imperative (hard-coded in Buck) at a lower level (to build a java_library, compile the srcs with the deps in the classpath, then package the resulting classes and the resources).

[Thomas Broyer]

On Tuesday, September 24, 2013 5:48:03 PM UTC+2, Cristiano wrote:

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

For reference, here are my gripes with Maven: http://blog.ltgt.net/maven-is-broken-by-design/

[Ray Cromwell]

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?

--

[Cristiano Costantini]

For reference, here are my gripes with Maven: http://blog.ltgt.net/maven-is-broken-by-design/

 Yes I've seen, I'm preparing a reply ;-)

[Thomas Broyer]

On Friday, September 27, 2013 1:33:10 AM UTC+2, Ray Cromwell wrote:

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?

For now I only used Buck for the de-tangling dependency work. To use it, you still have to build gwt-dev using Ant; that's because I didn't want to duplicate in Buck what I already did with Maven, as I didn't intend to keep Buck as the build tool for GWT. I also used a single BUCK file to make it easier to edit (just open it in a text editor and use search to navigate within it, vs. having to chase down BUCK files sprinkled all over the source tree)

I don't think it would be possible currently to have one BUILD/BUCK file for each "piece" of gwt-dev (and similarly for gwt-user, to a lesser extent) without moving files, as we'd probalby want one "piece" to include classes from several packages under com.google.gwt or com.google.gwt.dev. So we'd basically either live with a big BUILD/BUCK file in dev/core that builds the various pieces of gwt-dev, or move files so we can have one BUILD/BUCK file per "piece", or we could build even smaller pieces (a bunch of BUILD/BUCK files would still probably have several java_library, as we're going to need to "split" packages into different JARs, unless we also rename classes) and assemble them into slightly bigger ones.

As much as I wouldn't mind using Buck for GWT (and most probably like it), I still think we should try other things first (such as Gradle) if our goal is to make it easier for new contributors to jump in (or for existing contributors configuring new dev environments). Gradle support in Eclipse is surprisingly good (OK, not for editing build.gradle files, but most contributors wouldn't have to deal with them anyway).

At this point though, I'm still open to anything that would make command-line builds easy and *fast*, and easy to maintain with a lot of small pieces to build. IDE automatic/easy configuration is also a requirement, but I wouldn't really mind building it manually (like they did for Gerrit).

[Cristiano Costantini]

Il giorno venerdì 27 settembre 2013, Goktug Gokdogan ha scritto:

I have been in favor of Buck because that is what most contributors are already familiar with and can bring their expertise. 

This is a good point which need to be taken into account.

But I've found frustrating buck cannot be built on windows, and no binaries are provided. Also, it required me to upgrade to JDK 7 on the mac before I can start to "try" building GWT...

If this is the way to start with contributing to GWT it could be a limitation...

[Brian Slesinsky]

I skimmed the Gradle manual and it looks pretty decent. While the syntax and terminology is different, it looks like the concepts map back to stuff I'm already comfortable with.

It has "tasks" which are basically build rules which are configured via Groovy (instead of Python macros). The tool builds and executes a dependency graph, and you can look at the dependency graph before running it. There is a dependency cache and it sounds like they care about both avoiding duplicate work and reproducible builds. It has Maven and Ant compatibility without actually being Maven or Ant. Also, Android is standardizing on it which is a plus.

Here's a good place to start reading:

http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html

- Brian

[Ray Cromwell]

I bit the bullet and came up with a set of gradle files that can generate IDEA projects which successfully import and then allow you to build dev/user in the IDE and launch compilation of the samples. It's non-ideal because the builtin IDEA support for importing gradle projects doesn't give enough control (need to add Java source to class path but exclude it from javac compile) However, running "gradle idea" generates the proper files from the command line and you just open them.

I'm gonna work on adding support for building and running unit tests and adding SuperDevMode launch rules, then I'll put it up for review. Eclipse users will have to figure out their own gradle magic. ;-p

[Thomas Broyer]

On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:

I bit the bullet and came up with a set of gradle files that can generate IDEA projects which successfully import and then allow you to build dev/user in the IDE and launch compilation of the samples. It's non-ideal because the builtin IDEA support for importing gradle projects doesn't give enough control (need to add Java source to class path but exclude it from javac compile) However, running "gradle idea" generates the proper files from the command line and you just open them.

And now I regret not having (seriously) looked at Gradle before ;-)

IIUC, thanks to the Ivy backend, we could even remove the need to checkout the "tools" from SVN, and simplifying dependency management at the same time; with a combination of "client module dependencies" and an Ivy repository with custom patterns; maybe not worth the effort if we want to stop bundling our dependencies in the JARs (they'll have to be deployed to some Maven repo –Central– to support Maven).

I'm gonna work on adding support for building and running unit tests and adding SuperDevMode launch rules, then I'll put it up for review.

Would you mind publishing what you have already? (publish as a draft –refs/drafts/master instead of refs/for/master– and add me as a reviewer if you don't want to publicize it yet)

I'm curious how well Gradle will handle the fact that gwt-dev tests require gwt-user.jar (and includes the sources of the HelloWorld sample, but that's easy)

 

Eclipse users will have to figure out their own gradle magic. ;-p

I'll have a look at it then (yep, still mostly an Eclipse user)

[Ray Cromwell]

Here's a commit on my private fork containing the gradle stuff

https://github.com/cromwellian/gwt-sandbox/commit/8f26f05d78109d0d9a91871df9102c0b461bef90

--

[Cristiano Costantini]

Hello,

What do you think of having gradle (or something else) generating the pom.xml files?

I was thinking that as an approach to mavenizzation...

I'll try to elaborate more this concept if my laptop battery last enough.

Cristiano

[Brian Slesinsky]

I haven't tried it, but it says here that Gradle has support for publishing to Maven:

  http://www.gradle.org/docs/current/userguide/publishing_maven.html

[Cristiano Costantini]

Hello, 

Exporting maven artifacts from Gradle could be very interesting, but I would like to point out one aspect:

we should also create proper pom.xml files with dependencies defined in it rather than embedded in the jars, else there would be no benefit in adopting maven - from the GWT developer point of view.

Probably this is feasible with Gradle, but I expect it requires a lot of configuration to be achieve as the plugin probably outputs standards simple pom.xml.

This is much relevant to what I was meaning this morning:

I was re-thinking to the approach of "first" modularize GWT, "then" mavenize it. It seemed good to me at first glance, then I realized that "modularization" of GWT is the real missing aspect now, and when you get a good "modularization", maybe it is not "mavenization" that makes difference (publishing maven artifacts is _required_ but it could also be achieved in many other ways).
 
So, I asked myself why am I so inspired by Maven?
And I realized that it is thanks to Maven that I have been able to make the most modular projects in my career, so I would trust this tool to perform this modularization task and not a tool I just started to learn. Especially because modularization is not a matter of a tool, but a matter of the "mind" of the modularization's "architect".

Thomas seems to have a lot of experience with Maven and with GWT, so I want to suggest him, why not to start from "Mavenization" and then try doing "Modularization" with Maven?

To better explain my perspective, here what I would do. In maven central repo I see there are 5 jars plus a pom for GWT :

gwt-servlet -> is a jar
gwt-elemental -> is a jar
gwt-codeserver -> is a jar
gwt-user -> is a jar
gwt-dev -> is a jar
gwt -> is a pom

My "mavenization first" approach, would create a set of Maven projects which has exactly the above 5 artifacts as output.

I mean something different than doing (as we already have in maven subfolder of GWT src code)

> ant clean dist-dev

> maven/push-gwt.sh

I mean real maven projects that someone build by changing directory and launching "mvn install".

This should be automatized, Gradle or ant or even shell scripts could be used, and I the end it should be possible to build GWT with maven with something like:

> ant prepare-maven

> cd maven

> mvn clean install

(probably the pom.xml are written completely and the "prepare-maven" step copy source code into the maven folders).

The output of the maven build should be validated to be compatible with the one of the ant build, maybe something like "clirr" could be used for this. This will be a huge step, and the maven build would be 100% compatible, we should ask the community to move contributing to GWT using maven build. Then, if my thesis is right, start out the modularization, which with maven on the background could be easier. 

It seems a good approach to me, but I admit I am blind a lot about the whole GWT build and I will not be surprised if someone has already started blaming me for what I've written up to now.

I believe that doing modularization requires the lead of a deep "connoisseur" of GWT src code project, if I would modularize it, I would probably fail leaving legacy un-modularized code or throw away parts.

I would trust Thomas opinion on this most that everyone's else. He has done the most of the research on GWT and Maven and has also explored other roads with Buck and Gradle. I've achieved this idea only thanks to having studied his work (btw, I've not been able to make buck build work...)

I would like to have some feedback on this idea.

If Thomas want to try this way, I would be glad to help him, else, if I get at least some significant "+1", I can start making some test... then if I discover it is harder than I can achieve, it could hopefully provide at least some useful feedback for who will come after.

Regards,

Cristiano

2013/9/29 Brian Slesinsky <skyb...@google.com>

[Thomas Broyer]

On Sunday, September 29, 2013 10:24:42 PM UTC+2, Cristiano wrote:

Hello, 

Exporting maven artifacts from Gradle could be very interesting, but I would like to point out one aspect:

we should also create proper pom.xml files with dependencies defined in it rather than embedded in the jars, else there would be no benefit in adopting maven - from the GWT developer point of view.

Probably this is feasible with Gradle,

It is *obviously* possible.

 

but I expect it requires a lot of configuration to be achieve as the plugin probably outputs standards simple pom.xml.

No, it's built-in. Deploying to a Maven repo with a "naked" POM (without declared dependencies) would be a total nonsense.

See http://www.gradle.org/docs/current/userguide/maven_plugin.html and http://www.gradle.org/docs/current/userguide/publishing_maven.html

Don't forget that Hibernate and Spring (among others) are built with Gradle.

This is much relevant to what I was meaning this morning:

I was re-thinking to the approach of "first" modularize GWT, "then" mavenize it. It seemed good to me at first glance, then I realized that "modularization" of GWT is the real missing aspect now, and when you get a good "modularization", maybe it is not "mavenization" that makes difference (publishing maven artifacts is _required_ but it could also be achieved in many other ways).

We have several goals with this "build refactoring":

• lower the barrier to entry for contributors, by making it easier to get your dev environment (IDE, etc.) configured to hack on GWT.
• modularize GWT into smaller pieces (this, BTW, needs some preliminary refactoring work at the code level), for many reasons (both for people coding on GWT and people using GWT)
• because of #2 above, the Ant build script and maven/push-gwt.sh would quickly become an unmaintainable mess; we need something that's easier to maintain (declarative at the high level would be best, imperative at the low level even better)
• stop bundling dependencies and instead reference them from a repository.

I tried doing it all at once (except referencing deps as system deps), because I couldn't see another way to do it with Maven.

Note that I also tried to have a working build, and then reverse-engineer a transition path.

In retrospect, that was probably a mistake.

We hadn't discuss it earlier, but if we could also have a way to ensure the Google and open-source build definitions are in sync (e.g. generate one form the other), it would be the cherry on the cake!

So, I asked myself why am I so inspired by Maven?
And I realized that it is thanks to Maven that I have been able to make the most modular projects in my career, so I would trust this tool to perform this modularization task and not a tool I just started to learn. Especially because modularization is not a matter of a tool, but a matter of the "mind" of the modularization's "architect".

Unless the tool gets in your way.

 

Thomas seems to have a lot of experience with Maven and with GWT, so I want to suggest him, why not to start from "Mavenization" and then try doing "Modularization" with Maven?

The problem is that gwt-dev tests depend (at runtime) on gwt-user (which depends on gwt-dev).

So you'll want one Maven artifact with dev/core/src and dev/core/super (gwt-dev.jar), another one with user/* (gwt-user), and a third one with dev/core/test (gwt-dev tests, depend on both gwt-dev and gwt-user).

You can probably hack something with Maven, but it would be just that: an ugly big hack. It would probably not work in your IDE too (believe me, I tried).

I'm not even talking about gwt-dev tests importing the HelloWorld sample sources and all our dependencies that don't exist in a Maven repo (also get in your way).

 

To better explain my perspective, here what I would do. In maven central repo I see there are 5 jars plus a pom for GWT :

gwt-servlet -> is a jar
gwt-elemental -> is a jar
gwt-codeserver -> is a jar
gwt-user -> is a jar
gwt-dev -> is a jar
gwt -> is a pom

There also are requestfactory-* JARs in com.google.web.bindery.

 

My "mavenization first" approach, would create a set of Maven projects which has exactly the above 5 artifacts as output.

Possibly not as easy as it sounds. gwt-servlet should only contain "shared" and "server" code, but there are probably dependencies on classes from "client" packages with deep ramifications (I must say I can't remember if this is actually the case, or only theoretically possible).

 

I mean something different than doing (as we already have in maven subfolder of GWT src code)

> ant clean dist-dev

> maven/push-gwt.sh

I mean real maven projects that someone build by changing directory and launching "mvn install".

This should be automatized, Gradle or ant or even shell scripts could be used, and I the end it should be possible to build GWT with maven with something like:

> ant prepare-maven

> cd maven

> mvn clean install

(probably the pom.xml are written completely and the "prepare-maven" step copy source code into the maven folders).

The output of the maven build should be validated to be compatible with the one of the ant build, maybe something like "clirr" could be used for this. This will be a huge step, and the maven build would be 100% compatible, we should ask the community to move contributing to GWT using maven build.

How would that work? Would you also provide an Ant task to get the changes back to the current layout?

 

I would like to have some feedback on this idea.

If Thomas want to try this way, I would be glad to help him, else, if I get at least some significant "+1", I can start making some test... then if I discover it is harder than I can achieve, it could hopefully provide at least some useful feedback for who will come after.

That's an interesting approach, but I fear it's overly complex and would be a pain to build and maintain (even for a relatively short lifetime, particularly for a relatively short lifetime).

Feel free to try it out (on your own, sorry), but be prepared to spend hours on it, lose sleep, a bit of your sanity, probably some hairs too.

As far as I'm concerned, I think I'm done with Maven (and yes, that means gwt-maven-plugin might finally stay a "community/unofficial" project). I hadn't imagined a couple days ago that Gradle might be the "ultimate build tool" I was after. I'll start migrating projects from Maven to Gradle at work beginning tomorrow, and see how it goes; but from my first few tests this week-end, I'm very confident.

I'm rather confident we can move GWT to Gradle without moving files (like Ray started doing), and without losing build tasks, particularly tests, checkstyle, etc. (though possibly not playing very nice with IDEs)

It should then be easy to gradually move from GWT_TOOLS to Central, modularize the build (possibly with an intermediate step that doesn't move files, if IDEs can cope with it), etc.

The one thing I haven't yet looked at in detail is IDE integration. Given what Buck does, I believe it wouldn't be a problem for IntelliJ IDEA, but maybe Eclipse would be a different story (anyone uses netbeans?).

[Matthew Dempsky]

On Sun, Sep 29, 2013 at 3:55 PM, Thomas Broyer <t.br...@gmail.com> wrote:

The problem is that gwt-dev tests depend (at runtime) on gwt-user (which depends on gwt-dev).

So you'll want one Maven artifact with dev/core/src and dev/core/super (gwt-dev.jar), another one with user/* (gwt-user), and a third one with dev/core/test (gwt-dev tests, depend on both gwt-dev and gwt-user).

You can probably hack something with Maven, but it would be just that: an ugly big hack. It would probably not work in your IDE too (believe me, I tried).

Ugh, this is another one of my gripes with Maven.  In a separate project (error-prone), I wanted to move some of the test helper classes from core:test into a separate testhelpers package so they could be reused in other projects' tests.  Having a dependency path like "core:test" => "testhelpers:main" => "core:main" works fine in Google's BUILD system, but Maven throws a fit about it.  (If someone has a good solution to this, feel free to comment here: https://code.google.com/p/error-prone/issues/detail?id=62)

Anyway, I'm of the same opinion here as Thomas: I want to make it easy for developers to use GWT in their projects and to contribute to GWT itself.  I supported switching to Maven as a means to this end, but I'm no fan of it beyond that, and I don't think any other core GWT contributors are at this point.

To summarize: if anyone still feels strongly that GWT should use Maven, those individuals need to roll up their sleeves and work on making it happen.

[Ray Cromwell]

The @jar stuff isn't needed, I was just experimenting around in my patch.

--

[Geoffrey Wiseman]

On Sunday, September 29, 2013 8:51:47 PM UTC-4, Matthew Dempsky wrote:

Anyway, I'm of the same opinion here as Thomas: I want to make it easy for developers to use GWT in their projects and to contribute to GWT itself.  I supported switching to Maven as a means to this end, but I'm no fan of it beyond that, and I don't think any other core GWT contributors are at this point.

To summarize: if anyone still feels strongly that GWT should use Maven, those individuals need to roll up their sleeves and work on making it happen.

I neither love or hate Maven. It's one of the best supported build tools in Java, and I end up using it for that reason as much as anything else. It simplifies some things and makes other things more complex. If one of its alternatives got really popular, I would probably try it. In the end, I probably prefer Maven to Ant, mainly because Maven projects /tend/ to be a little more likely to work out of the box without configuration on an individual developer's machine, but that's more to do with how people use Ant than with Ant itself. 

That said, I agree with a bunch of the comments here that getting GWT to the point where someone can contribute to it without days of setup is key; I once tried to contribute a patch to something, but after a few hours of not getting the project fully set up, I gave up and went back to what I was actually working on. If you can reduce the barrier to entry so that it's not hard to contribute, even if that means installing Gradle or Buck, I think the problem is solved. If you moved to Maven and still had immense setup hurdles, the problem still isn't solved, AFAICS.

So, I'd just be happy if that barrier to entry could be reduced -- reduced setup, increased modularity, simpler out-of-the-box configuration, etc. That'd make it easier for people like me to be more involved.

[Thomas Broyer]

On Wednesday, October 2, 2013 4:48:14 PM UTC+2, Geoffrey Wiseman wrote:

On Sunday, September 29, 2013 8:51:47 PM UTC-4, Matthew Dempsky wrote:

Anyway, I'm of the same opinion here as Thomas: I want to make it easy for developers to use GWT in their projects and to contribute to GWT itself.  I supported switching to Maven as a means to this end, but I'm no fan of it beyond that, and I don't think any other core GWT contributors are at this point.

To summarize: if anyone still feels strongly that GWT should use Maven, those individuals need to roll up their sleeves and work on making it happen.

I neither love or hate Maven. It's one of the best supported build tools in Java, and I end up using it for that reason as much as anything else. It simplifies some things and makes other things more complex. If one of its alternatives got really popular, I would probably try it. In the end, I probably prefer Maven to Ant, mainly because Maven projects /tend/ to be a little more likely to work out of the box without configuration on an individual developer's machine, but that's more to do with how people use Ant than with Ant itself. 

That said, I agree with a bunch of the comments here that getting GWT to the point where someone can contribute to it without days of setup is key; I once tried to contribute a patch to something, but after a few hours of not getting the project fully set up, I gave up and went back to what I was actually working on. If you can reduce the barrier to entry so that it's not hard to contribute, even if that means installing Gradle or Buck, I think the problem is solved. If you moved to Maven and still had immense setup hurdles, the problem still isn't solved, AFAICS.

The main issue with Maven here is that the road is long to reach a state where setting up your dev env is a breeze:

* dependencies have to be deployed to a Maven repo

* code *has* to be modularized a bit (because, as I said, gwt-dev tests depend on gwt-user and the hello sample sources)

There might be some intermediary steps but we'd then lose "features" of the build (e.g. no gwt-dev tests), and/or it wouldn't solve the setup issue (if you don't deploy deps to a Maven repo)

So moving to Maven requires a "big bang" move, i.e. the easiest way to fail.

Gradle allows for "baby steps": 1) make it work 2) make it better 3) modularize, piece by piece.

Buck would require some work to setup IDEs, including hand-generating Eclipse .project/.classpath files "by hand".

[James Northrup]

>* dependencies have to be deployed to a Maven repo

I wanted to chime in here, the dependencies to build a splattered hierarchy of java with poms using intellij to back-fill dependencies is here, tested on 2.5.0--rc i beleive.

<repository>

            <id>gwt-maven-rewraps</id>

            <url>http://gwt-maven-rewraps.googlecode.com/git/</url>

</repository>

if intellij can backfill gradle builds the same way it backfills with maven deps, all the better.  

in my experience things reach a point of mvn clean install with poms if you cordone off unit test support to be last and then don't run the unit tests.

[Cristiano Costantini]

Hi James,

in the report of the latest GWT Contributor Hangout it is written that you want to work on Mavenization.

I would like to help in some way (if I have time and the right skills).

Can you tell us what it is your idea? 

It is written that you have shell scripts that do the conversion, can you share them?

Thank you,

Cristiano

2013/10/30 James Northrup <northru...@gmail.com>

--

[james northrup]

Hi

I have to figure out the gerrit instructions but you may fork this in the mean time.

the initial transform was chronicled on a  plus posting and is hopefully repeatable on current trunk to some degree at https://plus.google.com/u/0/112159826230131242033/posts/2vWKkHoiZZT

current most-effort sha1 for pre-2.5.0  is at 

https://github.com/jnorthrup/gwt/commit/36b079a550b2f6959750d1647766677b6207bb92

( https://github.com/jnorthrup/gwt/network )

Bhaskar has sent me a link to gerrit this week but other priorities have held me from it.  

it may be as simple as stealing the poms that are here since they link the custom gwt tools jars cdn entries.  It seems universally accepted that the unit tests will not survive this effort.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/MZRnJwCbKUM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Jim Northrup  *  (408) 837-2270 *

[Cristiano Costantini]

Ok,

thank you,

I will check it as soon as I find some extra time (this afternoon I fear I'll end up fighting other issues all the time)

I will try to give some useful feedback after that.

Did you participated to the hangout this week?

Do GWT 2.6.0 will be still released using Ant?

Any update about the Gradle approach (is it going on?)

thank you,

Cristiano 

[james northrup]

I'll parrot Ray as well as I can:

the gwt team doesn't really use maven so the current build will probably proceed as is.  Mavenized sources should be in gerrit (marked as review-only) because maven is not a bad thing, it's just not the gwt team's thing.  Thomas Broyer is looking into Gradle and Buck migration.  

Gradle is somehow closer to ant semantics so seems to offer more modularization conveniences.</Ray>

the repo work done by this effort carries over to Gradle as far as i know.  

this commit in this maven repo cdn project https://code.google.com/p/gwt-maven-rewraps/source/detail?r=9fc5649f06a86ff1c08a84f6239ae98ae39f2326 has the libs I pushed from GWT_TOOLS as maven repo format.  

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/MZRnJwCbKUM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.