Re: [gwt-contrib] Re: Elemental 2?
+1 for hacky prototype to play with. this is the top search result for 'gwt elemental2' +4 months since last post On Monday, November 30, 2015 at 10:42:23 PM UTC-8, James Nelson wrote: > > +1 for hacky prototype to play with. > > Collide was built with hacky pre Elemental1, and it was rescuable, > and I may have a use case to upgrade it again to Elemental2 (plus a little > other top secret magic). > > https://github.com/cromwellian/gwt-sandbox was where I got the hacky pre > java 8 version. > Maybe a quick push and we can start the Elemental2 bake off. v 0.0.1 :-) > >> -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8937f964-2f16-43a7-bb14-42c7f943d5d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Maven-ization Status
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. On Sat, Nov 2, 2013 at 7:02 AM, Cristiano Costantini cristiano.costant...@gmail.com wrote: 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 northrup.ja...@gmail.com * 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 idgwt-maven-rewraps/id urlhttp://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. On Wednesday, October 2, 2013 9:29:46 AM UTC-7, Thomas Broyer wrote: 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. 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. -- 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
Re: [gwt-contrib] Re: Maven-ization Status
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. On Sat, Nov 2, 2013 at 8:53 AM, Cristiano Costantini cristiano.costant...@gmail.com wrote: 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 -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Jim Northrup * (408) 837-2270 * -- 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
* 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 idgwt-maven-rewraps/id urlhttp://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. On Wednesday, October 2, 2013 9:29:46 AM UTC-7, Thomas Broyer wrote: 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. 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. -- 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] mavenization of gwt.. some progress... (cross posted from g+)
cross posted from https://plus.google.com/u/0/112159826230131242033/posts/UZmATUKyMRg https://docs.google.com/document/d/1JCWTtZqvXQlPyCMbllGAcFaCuGd89UGEBYdLhsqUkiM/edit steps 3-5 have been done, outlined in a g+ post We are in a situation where anyone with greater knowledge of gwt workings than myself might see ways to counter most or all of the unit tests based on matching up the right POM imports or at least identifying the wrong ones. No source code was harmed in the making. 8 -- cut [...] With the steadying hand of +Colin Alworthhttps://plus.google.com/117292705672170699891I have been able to bring the mavenized gwt tree to a level of compilation that supports an effort of fixing unit tests. Tests run: 1275, Failures: 251, Errors: 13, Skipped: 0 see https://gist.github.com/jnorthrup/5039787 this may be as simple as a few mis-guessed +IntelliJ IDEAhttps://plus.google.com/104653401767241115426pom imports which allow the tree to compile nicely but behave in a way the tests aren't built for. the mavenized branch of gwt on github is at https://github.com/jnorthrup/gwt/commit/999b04b7850ac2c86d9382056f93cb27d4f510d0 [INFO] BUILD SUCCESS -DskipTests [INFO] Reactor Summary: [INFO] [INFO] gwt-parent SUCCESS [0.404s] [INFO] gwt-core .. SUCCESS [2.572s] [INFO] gwt-dev_core .. SUCCESS [19.284s] [INFO] gwt-user .. SUCCESS [32.481s] [INFO] gwt-distro-source . SUCCESS [0.046s] [INFO] gwt-distro-source_core SUCCESS [0.044s] [INFO] gwt-doc ... SUCCESS [0.045s] [INFO] gwt-reference_Microbenchmarks . SUCCESS [1.409s] [INFO] gwt-tools_api-checker . SUCCESS [2.906s] [INFO] gwt-tools_benchmark-viewer SUCCESS [1.485s] [INFO] gwt-tools_cldr-import . SUCCESS [2.431s] [INFO] gwt-tools_datetimefmtcreator .. SUCCESS [1.054s] [INFO] -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit 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: RFC: sharded linking
there's a fairly large repository based elephant in the room named maven. On Feb 10, 2010, at 7:58 AM, John Tamplin wrote: On Wed, Feb 10, 2010 at 10:45 AM, Lex Spoon sp...@google.com wrote: What you describe, Alex, is available via the Compiler entry point, though it hasn't been particularly well documented. There is a PermutationWorkerFactory that can create CompilePerms workers. The default worker factory spawns Java VMs on the same machine, but it is possible to write a replacement worker that uses ssh or whatnot to do the work on a separate machine. The way to plug in a replacement worker factory is to set the Java property gwt.jjs.permutationWorkerFactory . That said, I thought the reason for existence of Precompile, CompilePerms, and Link is to get the best build time but at the expense of needing extra configuration. We are finding that by spending a few seconds copying source code over, we save 10+ minutes in Precompile and 10+ minutes in Link. Is copying source code so inconvenient that it would be worth having a slower build? I would have thought any of the following would work to move source code from one machine to another: 1. rsync 2. jar + scp 3. svn up on the slave machines Do any of those seem practical for your situation, Alex? Overall, it's easy to provide an extra build staging as an option, but we support a number of build stagings already What does make it difficult is that you can't have a pool of worker machines that can build any project that are asked of them without copying the sources to the worker for each request. For a large project, this can get problematic especially when you have to send the transitive dependencies. Besides, what is gained by having the user have to arrange this copying themselves rather than the current method of sending it as part of the compile process? For example, distributed C/C++ compilers send the preprocessed source to the worker nodes, so they don't have to have the source or the same include files, we currently send the AST which is a representation of the source, etc. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
i'm only chiming in on the 3 letters RFC in the topic. the usecases being described as a point of deliberation, defining dependancies, repository access, and bundling automation, are well solved items in the maven stable. how hard can it be to define a multiproject descriptor, assign channels of build-stage progression, and have a top-level project build coordinated by one maven instance publish artifacts to sucessive build-channels served elsewhere by daemons which trigger maven sub-builds? even if a GWT build is not in itself a maven project, there's very few reasons why a synthetic maven pom cannot be fashioned for a build-node graph to unify conventions of scm, artifact, versioning, and build hooks to prior documented art and tools. On Feb 10, 2010, at 8:12 AM, John Tamplin wrote: On Wed, Feb 10, 2010 at 11:01 AM, James Northrup northrup.ja...@gmail.com wrote: there's a fairly large repository based elephant in the room named maven. I'm not sure what that has to do with sharding a compile of a GWT application across a build farm. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
