Re: [gwt-contrib] Re: Maven-ization Status
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.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :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.bro...@gmail.com 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.comwrote: 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. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?
I'm a little bit late in this discoussion, i see there is a lot of work already on going. But +1 for this. SASS or LESS would be a big plus. For me I think supporting OOCSS is more important than supporting CSS3 without workarounds. Thank you guys! Sam On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote: Hello. How could I refuse? :) SGTM. We will of course, still have to maintain all of the GWT-isms. Actually, I've been wondering if we shoudn't just adopt LESS or SASS extensions too. Yes, please. Greetings, Michael -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Setting up Eclipse for Contributing to GWT
Hi to all contributors I'm developing with GWT since two years and now i want to contribute to GWT. I checked out the GWT Source Code with git clone https://gwt.googlesource.com/gwt trunk But I don't understand how to setup my eclipse project. Does somebody have some hints for me? Sam -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Setting up Eclipse for Contributing to GWT
Have you tried following the eclipse/README.txt? BTW, you also need to svn checkout http://google-web-toolkit.googlecode.com/svn/tools; On Wednesday, September 25, 2013 11:13:06 AM UTC+2, Samuel Schmid wrote: Hi to all contributors I'm developing with GWT since two years and now i want to contribute to GWT. I checked out the GWT Source Code with git clone https://gwt.googlesource.com/gwt trunk But I don't understand how to setup my eclipse project. Does somebody have some hints for me? Sam -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Setting up Eclipse for Contributing to GWT
No i did't saw that. Thanks for the hint. I'll check this and come back if I stuck. Sam On Wednesday, September 25, 2013 12:15:27 PM UTC+2, Thomas Broyer wrote: Have you tried following the eclipse/README.txt? BTW, you also need to svn checkout http://google-web-toolkit.googlecode.com/svn/tools; On Wednesday, September 25, 2013 11:13:06 AM UTC+2, Samuel Schmid wrote: Hi to all contributors I'm developing with GWT since two years and now i want to contribute to GWT. I checked out the GWT Source Code with git clone https://gwt.googlesource.com/gwt trunk But I don't understand how to setup my eclipse project. Does somebody have some hints for me? Sam -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
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. On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer t.bro...@gmail.com wrote: On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote: 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.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin ? No, it's the modulemaven/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_**codehttp://my.project.org/source_codetrunk [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 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
Re: [gwt-contrib] CSS3 support in CssResource: Closure Stylesheets?
Its never too late - I don't know how far Julien has gotten, but I've been distracted by other work, as well as trying to nail down conceptually where GSS meets ClientBundle. For my part, SASS or LESS are a major step down from what we already have - the purpose of GWT in general is to let you write maintainable code that compiles to well-performing code, but not expose features that will perform badly (consider the lack of java.text, reflection support). The scoping feature that sass/less/compass has (allowing you to nest rules within other rules) makes for much longer selectors in the compiled out code, which equates pretty directly to worse performance (longer selectors take longer to find/track what they apply to). In contrast, Closure Stylesheets gives us the same sorts of variables, mixins, and @if syntax, but puts as much of this work on the compiler rather than adding more classes at runtime. It is a little more limited (and I'm not sure how we can even achieve things such as @def and @eval... which current CssResource has), but those limitations seem designed to provide better runtime performance. On a different note, less/sass are implemented in Ruby, not Java, so either they must be made to work in JRuby or we'd need to require an existing Ruby installation. OOCSS could be worth looking at - I don't know anything about it yet but would be interested in learning. At a glance, it *appears* to be more of a philosophy about writing html/css and a single set of starting structural css, rather than a more 'useful' css language - do I have it right? Also, just as GssResource can be added as a new ResourcePrototype type, you could just as easily create a LessResource or OocssResource with its own generator to perform the required transformations. I hang out in ##gwt on freenode, and would love to talk more about this whole task with anyone who is interested, otherwise i'd be open for a hangout to chat too. On Wednesday, September 25, 2013 2:24:06 AM UTC-5, Samuel Schmid wrote: I'm a little bit late in this discoussion, i see there is a lot of work already on going. But +1 for this. SASS or LESS would be a big plus. For me I think supporting OOCSS is more important than supporting CSS3 without workarounds. Thank you guys! Sam On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote: Hello. How could I refuse? :) SGTM. We will of course, still have to maintain all of the GWT-isms. Actually, I've been wondering if we shoudn't just adopt LESS or SASS extensions too. Yes, please. Greetings, Michael -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
As a stop-gap measure, can you clean up and check in your IDEA module(s)? - Brian On Wed, Sep 25, 2013 at 9:20 AM, Ray Cromwell cromwell...@google.comwrote: 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. On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer t.bro...@gmail.com wrote: On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote: 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.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin ? No, it's the modulemaven/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_**codehttp://my.project.org/source_codetrunk [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/3741https://gwt-review.googlesource.com/3741 , (if I find out how the command line options to apply the patch
Re: [gwt-contrib] Re: Maven-ization Status
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) -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] GWT 2.6 Release Plan (google-web-toolkit-contributors@googlegroups.com)
I've shared an item with you: GWT 2.6 Release Plan https://docs.google.com/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit?usp=sharing It's not an attachment -- it's stored online. To open this item, just click the link above. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
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.bro...@gmail.com On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote: 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.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin ? No, it's the modulemaven/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_**codehttp://my.project.org/source_codetrunk [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 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. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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
Re: [gwt-contrib] Re: Maven-ization Status
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. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
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. ;-) On Wed, Sep 25, 2013 at 10:26 AM, Thomas Broyer t.bro...@gmail.com wrote: 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) -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
