[gwt-contrib] Re: Change in gwt[master]: Added disabled IE10 permutation

[Matthew Dempsky]

[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 wrote:

> 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/2421
> To unsubscribe, visit 
> https://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 
> Gerrit-Reviewer: Artur Signell 
> Gerrit-Reviewer: Brian Slesinsky 
>
> Gerrit-Reviewer: Colin Alworth 
> Gerrit-Reviewer: Daniel Kurka 
> Gerrit-Reviewer: Goktug Gokdogan 
> Gerrit-Reviewer: Leeroy Jenkins 
> Gerrit-Reviewer: Manuel Carrasco Moñino 
> Gerrit-Reviewer: Matthew Dempsky 
> Gerrit-Reviewer: Matti Tahvonen 
> Gerrit-Reviewer: Patrick Tucker 
> Gerrit-Reviewer: Thomas Broyer 
> 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.

Re: [gwt-contrib] being cute with git describe

[Thomas Broyer]

Le 22 oct. 2013 19:26, "Matthew Dempsky"  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: Gerrit presubmit changes

[Matthew Dempsky]

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 wrote:

> 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 
> practices.
>  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] Re: Bad news for GWT DevMode!

[Matthew Dempsky]

On Tue, Oct 22, 2013 at 11:03 AM, Colin Alworth  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.

Re: [gwt-contrib] Re: Bad news for GWT DevMode!

[Colin Alworth]

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

[Brian Slesinsky]

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  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.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] being cute with git describe

[Matthew Dempsky]

On Tue, Oct 22, 2013 at 9:10 AM, Stephen Haberman
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.

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

[Thomas Broyer]

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 
> 
> > 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] Re: Question about the source: how does GWT builds "*.translatable.*", "*.emul.*", etc. packages?

[John A. Tamplin]

On Tue, Oct 22, 2013 at 12:11 PM, Thomas Broyer  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.

[gwt-contrib] Re: Question about the source: how does GWT builds "*.translatable.*", "*.emul.*", etc. packages?

[Thomas Broyer]

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] being cute with git describe

[Stephen Haberman]

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

[Jens]

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.

[gwt-contrib] Question about the source: how does GWT builds "*.translatable.*", "*.emul.*", etc. packages?

[Cristiano]

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.

[gwt-contrib] Re: Where is gwt-customchecks.jar?

[Andrés Testi]

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] Re: Where is gwt-customchecks.jar?

[Colin Alworth]

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?

[Andrés Testi]

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.

Re: [gwt-contrib] being cute with git describe

[Thomas Broyer]

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.