Re: [gwt-contrib] being cute with git describe
FYI, Gerrit just uses git describe and no special branch/tag dance: https://gerrit.googlesource.com/gerrit/+/stable-2.8/gerrit-war/BUCK https://gerrit.googlesource.com/gerrit/+/stable-2.8/tools/git.defs (note that I deliberately used a release branch rather than master; also note that the current master says v2.8-rc0-46-gc7ddde3, whereas the v2.8-rc0 tag was made on the stable-2.8 branch, but that branch was later merged back into master; and stable-2.8 said v2.7-1918-gea62148 just before v2.8-rc0 was tagged) An alternative would be to use --all and possibly process the output (use 0.0.0 when it says heads/master, or strip heads/ when it says heads/2.6; but then there's a risk of having two 2.6 referring to different things: refs/heads/2.6 and refs/tags/2.6). I think we should first ask ourselves: - do we really want to keep the 0.0.0 special version? (would it really hurt if master currently said 2.5.1-250-g4a00f1e?) - and do we really want to have a branch-specific version? (would it really hurt if a newly cut v2.6 branch said 2.5.1-250-g4a00f1e?) If we do want these, then it should be as easy as hard-coding the version in a file somewhere (About.properties or maybe rather the build script), and update this file just after we cut a release branch, so that master would have 0.0.0 and the v2.6 branch would have 2.6. That version could be used as a default value in case git describe fails (so that the hard-coded 2.6 version would only be used until we cut a 2.6-rc release; but then we would have to take great care not to make any tag on master, or merge to master any branch containing a tag; and thus is leads us to possibly discuss our git branching model), or be updated each time we cut a release (so it'd say 2.6-alpha when cut branch off master, then 2.6-rc when we cut the RC, etc.) The latter is what Maven does BTW (at least with the maven-release-plugin), except the version ends in -SNAPSHOT and is thus changed twice: once just before releasing, to use a non-SNAPSHOT version, and once just after to re-introduce the -SNAPSHOT suffix; the prefix used before and after a release is independent from the non-SNAPSHOT version used for release (how often did I have a 1.0-SNAPSHOT and then release 0.1.0 and moved to 0.2.0-SNAPSHOT; the only issue is if you need to resolve conflicts between the old 1.0-SNAPSHOT and the newer 0.2.0-SNAPSHOT –because Maven would choose the older one, with the higher number–, but then you probably have bigger problems than a version conflict!) On Monday, October 21, 2013 7:37:30 PM UTC+2, Stephen Haberman wrote: I was thinking about something like that too. I actually kinda like it, and it gives an easy monotonic counter for tracking master. Agreed. I don't think we're using proper git tags yet. The 'tags' currently in the tree for 2.5.1, etc that were imported from SVN are actually just regular git commits. I think the svn import was smarter than that...git tag -l shows tags for 2.5.0, 2.5.1, 2.5.1-rc1, etc. while intermediary development steps would still be 2.6rc1-42-blah. Yep, that makes sense. Hm, something to consider though, I was planning on creating the 2.6 branch and then immediately tagging as 2.6rc1. Since tags are independent of branches, I think that would actually cause the 2.6rc1 tag to be picked up by master too. Hm, true...you'd need at least one commit on the 2.6 branch to avoid it's tags getting picked up by git describe on master. I dunno. Looking at the DAG for the 2.5.1 branch, it looks like svn had a Cutting at r11495 for 2.5.1 RC1 commit at the start of that branch (granted, svn semantics require that). We could always make a similar dummy commit. Not great, but not horrible, I think. - Stephen -- 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: Where is gwt-customchecks.jar?
Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- 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: Where is gwt-customchecks.jar?
If only *all* of my changes were that easy to make... On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote: Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- 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: Where is gwt-customchecks.jar?
The changes may be small and easy, but consequences may be great. In this case, your change will save lots of useless google searches to newbie contributors ;-) - Andrés Testi El martes, 22 de octubre de 2013 10:32:43 UTC-3, Colin Alworth escribió: If only *all* of my changes were that easy to make... On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote: Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- 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] Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
Hi all, I'm going on with my analysis of the GWT source code, and I have achieved one of my first step, that is creating a jdepend report. However I had to exclude many classes because their package directive does not match the expected package. The classes affected by this problem are located in the following packages: com.google.gwt.core.translatable.* com.google.gwt.dev.jjs.intrinsic.* com.google.gwt.emul.* com.google.gwt.junit.translatable.* com.google.gwt.regexp.super.* com.google.gwt.rpc.super.* com.google.gwt.safecss.super.* com.google.gwt.safehtml.super.* com.google.gwt.typedarrays.super.* com.google.gwt.user.translatable.* com.google.gwt.validation.super.* com.google.web.bindery.autobean.super.* com.google.web.bindery.requestfactory.super.* I remember the com.google.gwt.emul.* packages are related to the JRE emulation, so in my intent of performing the dependency analysis I feel good to exclude them. How does GWT Build system (the actual one based on ANT) process the other sources? It would be long for me to dig into ant build files, which I'm not an expert of, just for understanding the impact of these sources into the dependencies with the full java code... FYI, I've uploaded the result here http://cristcost.net/gwtdepend/jdepend-report.html I have achieved it by moving all the java source code to a monolithic project and resolving all other dependencies with maven artifacts on central repo, with rebased dependencies using maven-shade-plugin or, for JDT and Closure Compiler, with artifact wrapped from GWT Tools. The analysis is related to commit 67fbd3cc714c81ea66c619c389692cc2d3552799 in date Mon Oct 21 20:14:36 2013 +0200 but the process is partially automated and I can repeat it easily for newer commits if someone need it (or I can publish the scripts to github). I'm doing this because I'm curious but hopefully this study will help a day in performing the work of GWT Modularization, take a look at the http://cristcost.net/gwtdepend/jdepend-report.html#cycles At last, I copy the detailed list of the packages giving their error. com.google.gwt.core.client.impl does not match the expected package com.google.gwt.core.translatable.com.google.gwt.core.client.impl com.google.gwt.core.shared.impl does not match the expected package com.google.gwt.core.translatable.com.google.gwt.core.shared.impl com.google.gwt.junit.client does not match the expected package com.google.gwt.junit.translatable.com.google.gwt.junit.client com.google.gwt.junit.client.impl does not match the expected package com.google.gwt.junit.translatable.com.google.gwt.junit.client.impl com.google.gwt.lang does not match the expected package com.google.gwt.dev.jjs.intrinsic.com.google.gwt.lang com.google.gwt.regexp.shared does not match the expected package com.google.gwt.regexp.super.com.google.gwt.regexp.shared com.google.gwt.rpc.client.impl does not match the expected package com.google.gwt.rpc.super.com.google.gwt.rpc.client.impl com.google.gwt.safecss.shared does not match the expected package com.google.gwt.safecss.super.com.google.gwt.safecss.shared com.google.gwt.safehtml.shared does not match the expected package com.google.gwt.safehtml.super.com.google.gwt.safehtml.shared com.google.gwt.typedarrays.shared does not match the expected package com.google.gwt.typedarrays.super.com.google.gwt.typedarrays.shared com.google.gwt.user.client.rpc.core.java.util does not match the expected package com.google.gwt.user.translatable.com.google.gwt.user.client.rpc.core.java.util com.google.gwt.user.client.rpc.impl does not match the expected package com.google.gwt.user.translatable.com.google.gwt.user.client.rpc.impl com.google.gwt.validation.client does not match the expected package com.google.gwt.validation.super.com.google.gwt.validation.client com.google.gwt.validation.client.impl does not match the expected package com.google.gwt.validation.super.com.google.gwt.validation.client.impl com.google.gwt.validation.client.spi does not match the expected package com.google.gwt.validation.super.com.google.gwt.validation.client.spi com.google.web.bindery.autobean.shared does not match the expected package com.google.web.bindery.autobean.super.com.google.web.bindery.autobean.shared com.google.web.bindery.autobean.shared.impl does not match the expected package com.google.web.bindery.autobean.super.com.google.web.bindery.autobean.shared.impl com.google.web.bindery.requestfactory.shared.impl does not match the expected package com.google.web.bindery.requestfactory.super.com.google.web.bindery.requestfactory.shared.impl java.beans does not match the expected package com.google.gwt.emul.java.beans java.io does not match the expected package com.google.gwt.emul.java.io java.lang does not match the expected package com.google.gwt.emul.java.lang java.lang.annotation does not match the expected package com.google.gwt.emul.java.lang.annotation java.lang.reflect does not match the expected package
[gwt-contrib] Re: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
The build script does not compile these source files to classes. Instead it just bundles them into the jar as resource files. These are super source packages, meaning that they won't get compiled to .class files but instead are bundled as source files into the jar. The GWT compiler then puts them on class path before anything else so you can override JVM classes with GWT specific implementations. -- 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] being cute with git describe
- do we really want to keep the 0.0.0 special version? (would it really hurt if master currently said 2.5.1-250-g4a00f1e?) FWIW I like 0.0.0 because it strongly differentiates hand-made/master releases vs. official/release branch releases. And it always sorts before release versions, which feels safer to me. Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. If we do want these, then it should be as easy as hard-coding the version in a file somewhere I see what you're saying, although from a workflow perspective that would mean branching is branch, edit version file, commit which is pretty close to branch, make a dummy commit, tag as 2.5.0-rc1. - Stephen -- 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: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
On Tuesday, October 22, 2013 5:39:34 PM UTC+2, Jens wrote: The build script does not compile these source files to classes. Instead it just bundles them into the jar as resource files. These are super source packages, meaning that they won't get compiled to .class files but instead are bundled as source files into the jar. The GWT compiler then puts them on class path before anything else so you can override JVM classes with GWT specific implementations. As part as a jdepend documentation effort, it would be great to have a report when using these sources instead of the non-super-source ones. Ideally, we'd also want to teach jdepend to read into JSNI. As far as modularization is concerned, we'd like to have dependencies always in the same direction: rebind-client-shared-server (or rebind-client-server-shared, depending on modules) so we can make a client artifact depending on a server artifact, or a client and server artifacts both depending on a shared artifact (but with no dependency between client and server). In some cases, we'll split packages into distinct artifacts (there are cycles at the package level, but not when looking only at the classes); e.g. c.g.g.user.client (Window, Timer, etc.) c.g.g.resources and c.g.g.junit to have a package not depending on I18N and other things, and another one (or several) with additional dependencies. -- 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: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
On Tue, Oct 22, 2013 at 12:11 PM, Thomas Broyer t.bro...@gmail.com wrote: As far as modularization is concerned, we'd like to have dependencies always in the same direction: rebind-client-shared-server (or rebind-client-server-shared, depending on modules) so we can make a client artifact depending on a server artifact, or a client and server artifacts both depending on a shared artifact (but with no dependency between client and server). In some cases, we'll split packages into distinct artifacts (there are cycles at the package level, but not when looking only at the classes); e.g. c.g.g.user.client (Window, Timer, etc.) c.g.g.resources and c.g.g.junit to have a package not depending on I18N and other things, and another one (or several) with additional dependencies. Why would it be acceptable to have shared code depend on server code? -- John A. Tamplin -- 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: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
On Tuesday, October 22, 2013 6:13:49 PM UTC+2, John A. Tamplin wrote: On Tue, Oct 22, 2013 at 12:11 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: As far as modularization is concerned, we'd like to have dependencies always in the same direction: rebind-client-shared-server (or rebind-client-server-shared, depending on modules) so we can make a client artifact depending on a server artifact, or a client and server artifacts both depending on a shared artifact (but with no dependency between client and server). In some cases, we'll split packages into distinct artifacts (there are cycles at the package level, but not when looking only at the classes); e.g. c.g.g.user.client (Window, Timer, etc.) c.g.g.resources and c.g.g.junit to have a package not depending on I18N and other things, and another one (or several) with additional dependencies. Why would it be acceptable to have shared code depend on server code? I probably meant rebind rather than shared; but I seem to remember some shared code making direct calls to server/vm, with a super-source version. In this case, the shared and server packages would live in a server artifact, and the client package and super-source version would live in a client artifact, with no shared artifact. There's also the case of classes referenced in annotations (e.g. @ProxyFor and @Service in RequestFactory) -- 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] being cute with git describe
On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman step...@exigencecorp.comwrote: Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. This is my instinct too: I'd like to be able to look at a version string and have some intuition about whether it came from a release branch or from master. But that's not a deal breaker for me. If the Git experts working on Gerrit have decided to go with 'ambiguous' descriptions, I'm willing to try out their method; maybe it's not so bad in practice. -- 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: Bad news for GWT DevMode!
I expect that by next summer devmode will *only* work in IE and perhaps an older version of Firefox. Oddly enough, the IE plugin has apparently worked for years with no complaints. (But the issue is that nobody currently on the team has ever built it.) - Brian On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer t.bro...@gmail.com wrote: I don't think any committer to the GWT project uses Windows (other than for testing, using VMs then), so it'd be either Firefox or Chrome (no other choice on Linux; and on OSX, Safari is no longer supported started with 5.1, and I don't think anyone uses OmniWeb or similar). Both work well. To answer the question about a “preferred browser”, I've been told that, on Windows, IE works best (is the fastest); that was a while back though, so things might have changed. On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote: IMO Firefox On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote: Just curious, is there a preferred browser for Classic DevMode? What do the cool kids use? :) On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote: Just saw this passing on Twitter: http://blog.chromium.** org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the browser. -- 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] Re: Bad news for GWT DevMode!
Amazingly, it still works great in the IE11 preview too! Only gotcha is that the missing plugin page thinks you are running firefox, so you need to manually grab the right copy of the IE plugin. On Tuesday, October 22, 2013 12:58:57 PM UTC-5, Brian Slesinsky wrote: I expect that by next summer devmode will *only* work in IE and perhaps an older version of Firefox. Oddly enough, the IE plugin has apparently worked for years with no complaints. (But the issue is that nobody currently on the team has ever built it.) - Brian On Mon, Oct 21, 2013 at 6:56 AM, Thomas Broyer t.br...@gmail.comjavascript: wrote: I don't think any committer to the GWT project uses Windows (other than for testing, using VMs then), so it'd be either Firefox or Chrome (no other choice on Linux; and on OSX, Safari is no longer supported started with 5.1, and I don't think anyone uses OmniWeb or similar). Both work well. To answer the question about a “preferred browser”, I've been told that, on Windows, IE works best (is the fastest); that was a while back though, so things might have changed. On Monday, October 21, 2013 3:21:49 PM UTC+2, Ivan Dimitrijevic wrote: IMO Firefox On Friday, October 18, 2013 11:47:13 PM UTC+2, Alex Raugust wrote: Just curious, is there a preferred browser for Classic DevMode? What do the cool kids use? :) On Tuesday, September 24, 2013 4:05:59 AM UTC-7, Thomas Broyer wrote: Just saw this passing on Twitter: http://blog.chromium.** org/2013/09/saying-goodbye-to-**our-old-friend-npapi.htmlhttp://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html This is really bad for DevMode in Chrome (maybe also in Firefox, which was already a nightmare). Means we really need to improve SuperDevMode, or find a non-NPAPI way to plug into the browser. -- 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.comjavascript: . 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] Re: Bad news for GWT DevMode!
On Tue, Oct 22, 2013 at 11:03 AM, Colin Alworth niloc...@gmail.com wrote: Amazingly, it still works great in the IE11 preview too! Only gotcha is that the missing plugin page thinks you are running firefox, so you need to manually grab the right copy of the IE plugin. Haha. We should file a bug against IE11 that they don't support FF plugins. ;) -- 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: Gerrit presubmit changes
One more update: The presubmitter tools are now open source. They're written in Go and the source code is available at https://gwt.googlesource.com/buildglue/. You can easily download and build it using the go command: mkdir buildglue export GOPATH=$PWD/buildglue go get gwt.googlesource.com/buildglue.git/cmd/... # Git checkout is now at $GOPATH/src/gwt.googlesource.com/buildglue.git # Compiled tools are now in $GOPATH/bin On Sun, Oct 20, 2013 at 6:57 PM, Matthew Dempsky mdemp...@google.comwrote: I've made a few changes to the presubmit process this weekend that I wanted to share: 1. There's now an initial fast style check step that should give style feedback much faster (on average within about a minute). If this fails, then the usual build/full-style check is skipped. 2. Style warnings are now presented inline as normal Gerrit review comments so you don't need to dig through the build log to figure out what went wrong. E.g., see https://gwt-review.googlesource.com/#/c/5035/ for an example review. 3. In addition to the usual style 'errors' that the full style check warns about, the fast style check will include 'info' and 'warning' messages, but only if they came from a source line modified by the change (as identified by git blame). 4. The fast style check now also includes some basic warnings for commit messages that don't follow Git commit message best practiceshttp://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html. Currently it checks that the subject line is =50 chars, the second line is blank, and all other lines are =72 chars. 5. I've configured an issue tracker template for reporting issues with the presubmitter: https://code.google.com/p/google-web-toolkit/issues/entry?template=Presubmit%20issue If you notice anything wrong or that could be improved, please feel free to submit an issue. Thanks -- 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] being cute with git describe
Le 22 oct. 2013 19:26, Matthew Dempsky mdemp...@google.com a écrit : On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman step...@exigencecorp.com wrote: Also FWIW, I am not a fan of master's git describe looking like 2.5.1-250- That seems misleading, because if we put the 2.5.1-rc0 tag directly on master's commit B: A - B [2.5.1-rc0] - C - D (master) And the 2.5.1 branch continues off B: A - B [2.5.1-rc0] - E - F [2.5.1] Then describe will name commit C as 2.5.1-rc1-1-C, when really in my mind 2.5.1-rc1 + 1 commit is commit E. On the 2.5.1 branch. There would basically be two 2.5.1-rc1 + 1 commit commits, which, yes, there is still the sha, but that seems confusing IMO. This is my instinct too: I'd like to be able to look at a version string and have some intuition about whether it came from a release branch or from master. But that's not a deal breaker for me. If the Git experts working on Gerrit have decided to go with 'ambiguous' descriptions, I'm willing to try out their method; maybe it's not so bad in practice. I believe it works best if you always merge release branches back to master (which implies that you commit fixes to release branches and merge them back to master, rather than cherry pick from master to releases), or absolutely never. Honestly, I'd just go with our current approach: use 0.0.0 by default with an override at build time, used when you release a new version or possibly for custom builds. At least for now. We'll revisit this when we have moved to the new build tool. -- 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: Change in gwt[master]: Added disabled IE10 permutation
[Moving discussion to gwt-contrib] If we don't fallback, we'll need to figure out how to handle the GWT 2.6 release. Possible options: 1. Enable ie10 permutation without fallback. When users upgrade, they need to simultaneously fix their code by adding appropriate rebind rules for ie10. Or they need to manually disable the ie10 permutation (but manually disabling a single permutation is clumsier than manually enabling a single permutation). 2. Don't enable the ie10 permutation by default in GWT 2.6, but include a release note mentioning it and warning that it will be enabled in GWT 3.0. Users can then upgrade to GWT 2.6, fix all of their rebind rules, and then enable the permutation manually if they desire. On Tue, Oct 22, 2013 at 2:42 PM, Brian Slesinsky skybr...@google.comwrote: Brian Slesinsky has posted comments on this change. Change subject: Added disabled IE10 permutation ..**..**.. Patch Set 21: Hi folks, Matthew and I talked about this and we're having second thoughts about the fallback from IE10 to IE9. Fallbacks are poorly documented and confusing. (Are they transitive so we will pick up bindings intended for IE8 as well?) Maybe it's better to start with a clean slate and not assume that workarounds for older IE are still necessary for IE10+? However, I don't know the consequences. Any comments? -- To view, visit https://gwt-review.**googlesource.com/2421https://gwt-review.googlesource.com/2421 To unsubscribe, visit https://gwt-review.**googlesource.com/settingshttps://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Iba0cec6e33ffd3fefa69c3c760868**beb00d42076 Gerrit-PatchSet: 21 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Matti Tahvonen ma...@vaadin.com Gerrit-Reviewer: Artur Signell ar...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Matti Tahvonen ma...@vaadin.com Gerrit-Reviewer: Patrick Tucker tucker...@gmail.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- 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.
