Re: [gwt-contrib] Re: Latest update to GWT plugin for Eclipse crashes Indigo

[Rajeev Dayal]

Looking into this now. Updates will be posted on the other thread that
Michael mentions.


On Mon, Dec 23, 2013 at 4:38 PM, Michael Prentice wrote:

> This was also posted in the GPE Google Group here:
> https://groups.google.com/forum/#!topic/google-plugin-eclipse/V4MaZEXY24Q
>
> That is probably a better place to discuss it. Also posting your update
> site URL would be helpful.
>
> --
> 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: GPE does not like GWT trunk SDK?

[Rajeev Dayal]

Hey guys,

The source is on SVN, as Thomas says, but it's not up-to-date nor is it
buildable right now.

We have a hidden project on GitHub with the updated GPE source, but I don't
want to open it up until external people can actually build it. I'm working
on this as we speak. I'd expect to have it publicly available by Jan 1st.
However, if there's something you'd immediately like to work on, contact me
privately and I could add you to the project.

@Brandon:  We have an engineer working on proper maven support right now.
The way it will work is that when you import a Maven project that uses the
appengine-maven-plugin, it will set it up as a WTP App Engine project (as
described here:
https://developers.google.com/appengine/docs/java/webtoolsplatform). The
existing Maven support will go away, as it's sort of not the right way to
do things (as you've noticed).

I've added Norman to the thread. He can provide more details.



On Sun, Dec 8, 2013 at 5:50 PM, Thomas Broyer  wrote:

> I have no idea how one builds Eclipse plugins but I suspect (in this case)
> this is "Eclipse driven" (i.e. no Ant or similar command-line-oriented
> build tool)
>
>
> On Sunday, December 8, 2013 11:41:09 PM UTC+1, Alain Ekambi wrote:
>
>> I know  the source is open. But last time I checked it was nt possible to
>> build it.
>> I still cant find any information about how to build the plugin.
>> Is that available somewhere ?
>>
>>
>>
>>
>> 2013/12/8 Thomas Broyer 
>>
>>
>>>
>>> On Sunday, December 8, 2013 11:26:41 PM UTC+1, Alain Ekambi wrote:

 Any new when the repo will be public.
 I would love to build some stuff on top of GPE.

>>>
>>> The GPE repo is already public, just not on GitHub (and still using
>>> SVN): https://code.google.com/p/google-plugin-for-eclipse/source/browse/
>>>
>>>
>>> --
>>> 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.
>

-- 
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: GPE does not like GWT trunk SDK?

[Rajeev Dayal]

Hi Brandon,

The sources are on GitHub right now, but they are not public. I'm working
on externalizing the build system. I don't want to make the sources public
till then, as it's not much use to outside contributors if they can't build
the plugin themselves (which has been evidenced by the GPE project on
code.google.com).

It's going to take another couple of weeks of work, I'd imagine.

Is there something you'd like to contribute in particular?


Thanks,
Rajeev



On Sat, Nov 16, 2013 at 7:36 PM, Brandon Donnelson
wrote:

> Rajeev, could I ask what the status is on the project? Maybe it's
> premature to ask yet. :) I'd like to see if I can plugin to contribute.
>
> Brandon Donnelson
>
>
> On Thursday, October 31, 2013 12:54:21 PM UTC-7, Jens wrote:
>>
>>
>> As for the problem you've noted, I'll fix that up this week and we'll aim
>>> to put out a release that works with GWT trunk in the next two weeks.
>>>
>>
>> Sounds great. Thanks a lot!
>>
>> -- J.
>>
>  --
> 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: GPE does not like GWT trunk SDK?

[Rajeev Dayal]

Hey Stephen,

We're in the process of moving the GPE source to github (and converting the
build system to Maven/Tycho so that external developers can build it) ,
which is why that repo hasn't been updated in a long time. I'll update the
homepage to reflect that.

As for the problem you've noted, I'll fix that up this week and we'll aim
to put out a release that works with GWT trunk in the next two weeks.


Thanks,
Rajeev


On Wed, Oct 30, 2013 at 2:41 PM, Stephen Haberman
wrote:

>
> I was going to ask how active the GPE project is...is the last commit
> really from October 2012?
>
> https://code.google.com/p/google-plugin-for-eclipse/source/list
>
> That doesn't seem right, but AFAICT there isn't another source repo?
>
> https://developers.google.com/eclipse/community
>
> - 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.
>

-- 
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] “GWT no longer supports ChromeFrame. The implementation caused more bugs than it solved.”

[Rajeev Dayal]

Ugh, thanks Unnur.
Sorry about that, Thomas.


On Mon, Oct 29, 2012 at 1:02 PM, Unnur Gretarsdottir wrote:

> OK - I'm just removing the bullet point entirely now - should be live soon
>
> On Fri, Oct 26, 2012 at 5:53 PM, Thomas Broyer  wrote:
> >
> >
> > On Thursday, July 19, 2012 12:16:26 AM UTC+2, rdayal wrote:
> >>
> >> Hey guys,
> >>
> >> This is my fault. I mis-interpreted the code change. As the change to
> >> "fix" this issue was basically a "revert" of the original commit that
> was
> >> supposed to add ChromeFrame support, I incorrectly assumed that
> reverting
> >> the code would prevent special behavior for ChromeFrame (which I
> figured we
> >> needed in order to make it work). Had I read issue #6665 more
> carefully, I
> >> would have realized that this fix was to improve support for
> ChromeFrame,
> >> not remove it entirely.
> >>
> >> I'll be sure to fix this statement in the release notes.
> >
> >
> > 3 months later, this is unfortunately still there :-(
> >
> > Could anyone fix it please?
> >
>
>
>
> --
> DO NOT FORWARD
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?

[Rajeev Dayal]

+[skybrian]

Ok, so it looks like we'll have to go ahead and rebuild the crx on our
side. I've added Brian, who has been playing around with the crx build
process.

On Wed, Sep 12, 2012 at 7:33 PM, Daniel Kurka wrote:

> Hi Rajeev,
>
> I just gave it a try and it seems that we need to do some actual changes
> to make this work. The chrome web store is complaining about the manifest
> version of the plugin:
>
> > An error occurred: Manifest version 1 is unsupported. Please upgrade to
> manifest version 2.
>
> I will give this another look tomorrow. It`s getting too late in Germany
> right now.
>
> -Daniel
>
>
>
>
> Am 13.09.2012 um 01:09 schrieb Rajeev Dayal :
>
> Sorry, this totally fell off the plate.
> Daniel, would you be able to submit it to the Chrome Webstore?
>
> On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka wrote:
>
>> Hi Rajeev,
>>
>> what is the status here?
>>
>> Can I help?
>>
>> -Daniel
>>
>>
>> Am 19.08.2012 um 17:10 schrieb Robert Hanson :
>>
>> @Rajeev, you mentioned that you were going to post the plugin to the
>> Chrome store.  Is that still the plan, or did you run into some issues
>> there?
>>
>> I'm working on some documentation that is about to go to press, and just
>> want to make sure I have the right instructions in there.
>>
>> Thanks.
>>
>> Rob
>>
>>
>>
>> On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal  wrote:
>>
>>> Hey Daniel,
>>>
>>> We do need to post the chrome devmode plugin to the webstore. I'll take
>>> care of that this week.
>>>
>>> I also need to rebuild the devmode plugin, as there were some fixes that
>>> went into it a while back that were never put into a distributable binary.
>>>
>>>
>>> Rajeev
>>>
>>>
>>> On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos  wrote:
>>>
>>>> Hi,
>>>>
>>>> A quick fix that might help:
>>>>
>>>> 1. right click on the chrome icon>Properties>Shortcut
>>>> 2. add in target: --enable-easy-off-store-extension-install
>>>> 3. open chrome and navitage to extensions ( chrome://chrome/extensions/)
>>>> 4. drag and drop on it the plugin (should be in your download folder
>>>> if you tried to install it before and didn't succeed)
>>>>
>>>> Regards,
>>>>Istvan
>>>>
>>>> On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka 
>>>> wrote:
>>>> > Hi everyone,
>>>> >
>>>> > today at work I was setting up a GWT installation on windows for a new
>>>> > coworker and noticed that with chrome 21 we can not install extension
>>>> > anymore. (They need to be in the chrome web store). I also noticed an
>>>> issue
>>>> > popping up on the issue tracker on the exact same thing:
>>>> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7569
>>>> >
>>>> > Does anyone have this covered or are we just hearing about this
>>>> change to
>>>> > chrome right now?
>>>> >
>>>> > -Daniel
>>>>
>>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1828803)

[Rajeev Dayal]

Thanks David - when I tested on the mac, I didn't have to refresh the
project after first import provided that I actually did an "Update Project"
after enabling Maven Annotation Processing on the project.

I noted this in bold on the Wiki page.

On Mon, Sep 17, 2012 at 9:15 AM,  wrote:

> LGTM
>
> Note that Mac users may have to refresh the project after first import
> in order to force APT to run.
>
> http://gwt-code-reviews.**appspot.com/1828803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Move GAE Auth functionality from Expenses over the MobileWebApp sample. (issue1829803)

[Rajeev Dayal]

Hey Thomas,

Thanks for looking this over. I'll reply to the code-specific comments in
Rietveld itself, but I thought I'd respond to your more pressing concerns
first.

On Fri, Sep 14, 2012 at 10:57 AM,  wrote:

> I'm sorry I've only started to review the files (over the last few days)
> but I have a first question/comment about where this is going:
>
> There are many things that are not needed in the case of MobileWebApp as
> the host page is protected behind authentication. Because the user won't
> ever see this page when being unauthenticated:
>  - LoginWidget does not need to have a dual state (there's no need for a
> "login" link)
>  - the username could be inlined in the script generated by the JSP
> (that might not work very well with the ApplicationCache/offline though)
>

That is true. I think that I moved the auth functionality over to this
sample so it wouldn't be lost (since Expenses is deprecated, and doesn't
completely work anymore).

I think what needs to happen is that this functionality should be
abstracted out into a separate useful widget. I just didn't have the time
to do this, so I decided to move it over here. It did not seem useful to
leave it in Expenses.

However, if we think that the best solution is to abstract out the
LoginWidget and leave MobileWebApp as-is (since the LoginWidget
functionality doesn't really apply as directly here), I'm okay with that.


> Also, there's probably no need to pass MobileWebApp.jsp as an init-param
> to the GaeAuthFilter as it could just use getContextPath()
> (MobileWebApp.jsp is in the welcome-file-list in the web.xml), or "/"
> (the context path is always "/" on GAE)
>

True, I can fix that up.


>
> As far as offline is concerned, it might get in our way here, but I'm no
> expert in mobile dev. Anyway, it seems to cause us more harm than
> anything, and the linker is known not to be great (it will load all
> permutations in the client's cache, only to use one of them)
>

Sorry, are you saying that we should make this an online-only sample until
we straighten out the offline story? It's good to know about the
permutations issue with the client's cache; that's not ideal at all. What
other harmful aspects are you referring to?


>
> This would greatly simplify the code, at the expense of removing a bunch
> of reusable code (LoginWidget, etc.)
>
>
> http://gwt-code-reviews.**appspot.com/1829803/diff/1/**
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthRequestTransport.java
> File
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthRequestTransport.java
> (right):
>
> http://gwt-code-reviews.**appspot.com/1829803/diff/1/**
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthRequestTransport.java#**newcode18
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthRequestTransport.java:**18:
> import com.google.gwt.event.shared.**EventBus;
> Why this change?
>
> http://gwt-code-reviews.**appspot.com/1829803/diff/1/**
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java
> File
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java
> (right):
>
> http://gwt-code-reviews.**appspot.com/1829803/diff/1/**
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java#newcode18
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java:18:
> import com.google.gwt.event.shared.**EventBus;
> Same question: what's the reason behind this change?
>
> http://gwt-code-reviews.**appspot.com/1829803/diff/1/**
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java#newcode64
> samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java:64:
> * @param state a {@link State} instance
> This looks like a leftover fro

Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?

[Rajeev Dayal]

Sorry, this totally fell off the plate.
Daniel, would you be able to submit it to the Chrome Webstore?

On Wed, Sep 12, 2012 at 7:07 PM, Daniel Kurka wrote:

> Hi Rajeev,
>
> what is the status here?
>
> Can I help?
>
> -Daniel
>
>
> Am 19.08.2012 um 17:10 schrieb Robert Hanson :
>
> @Rajeev, you mentioned that you were going to post the plugin to the
> Chrome store.  Is that still the plan, or did you run into some issues
> there?
>
> I'm working on some documentation that is about to go to press, and just
> want to make sure I have the right instructions in there.
>
> Thanks.
>
> Rob
>
>
>
> On Tue, Aug 7, 2012 at 11:39 AM, Rajeev Dayal  wrote:
>
>> Hey Daniel,
>>
>> We do need to post the chrome devmode plugin to the webstore. I'll take
>> care of that this week.
>>
>> I also need to rebuild the devmode plugin, as there were some fixes that
>> went into it a while back that were never put into a distributable binary.
>>
>>
>> Rajeev
>>
>>
>> On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos  wrote:
>>
>>> Hi,
>>>
>>> A quick fix that might help:
>>>
>>> 1. right click on the chrome icon>Properties>Shortcut
>>> 2. add in target: --enable-easy-off-store-extension-install
>>> 3. open chrome and navitage to extensions ( chrome://chrome/extensions/)
>>> 4. drag and drop on it the plugin (should be in your download folder
>>> if you tried to install it before and didn't succeed)
>>>
>>> Regards,
>>>Istvan
>>>
>>> On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka 
>>> wrote:
>>> > Hi everyone,
>>> >
>>> > today at work I was setting up a GWT installation on windows for a new
>>> > coworker and noticed that with chrome 21 we can not install extension
>>> > anymore. (They need to be in the chrome web store). I also noticed an
>>> issue
>>> > popping up on the issue tracker on the exact same thing:
>>> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7569
>>> >
>>> > Does anyone have this covered or are we just hearing about this change
>>> to
>>> > chrome right now?
>>> >
>>> > -Daniel
>>>
>>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Move GAE Auth functionality from Expenses over the MobileWebApp sample. (issue1806803)

[Rajeev Dayal]

On Wed, Aug 8, 2012 at 4:34 PM, Thomas Broyer  wrote:

> I'm on mobile right now so I didn't review the changes, but it looks from
> your comments like the home page should simply be protected. That way, auth
> would be triggered by the app loading, and the RF stuff would only be used
> in cased you're logged out while using the app (sign out from another
> window/tab or session expiration).
>

Yes, this is exactly right. It's honestly been a while since I've built a
webapp (curse of the tool-writer), so I apologize if some of these
statements seem simplistic :).

When you say protected, you mean by more than just a security-constraint,
right? Because that's not enough to prevent the browser loading it from
cache - there would have to be app-level logic to protect the page.


> This is how I handle auth in my own apps at least (I also make the home
> page dynamic, passing the user info and logout URL in the page as JS global
> vars, retrieved from the app using JSNI or a Dictionary)
>
I think that's a good idea.

I'm still inclined to commit as-is, as it's a step in the right direction,
but I think it needs another iteration with your suggestions.


> Le 8 août 2012 21:54, "Rajeev Dayal"  a écrit :
>
> Should mention that this review is based on
>> http://gwt-code-reviews.appspot.com/1804803/.
>>
>> I've moved over the authentication functionality from Expenses to
>> MobileWebApp. While I was at it, I corrected some of the inherent auth
>> problems in Expenses (and therefore MobileWebApp when I copied this over).
>> I've described these issues below:
>>
>> After logging out, if MobileWebApp.html is loaded from cache (which it
>> can be, because we're not setting the no-store header), there would be a
>> problem with the redirection back to the login page. The triggering event
>> was an unauthorized post to /gwtRequest, which the GaeAuthFilter would
>> trap. Unfortunately, /gwtRequest is not a valid URL to navigate to after
>> login. I had to add code to always go back to MobileWebApp.html. I also had
>> to add logic to preserve the gwt.codesvr parameter, so that the user would
>> not be dropped out of development mode on the redirection.
>>
>> While this fix works, it's not perfect, there are still inherent problems
>> with this re-authentication approach. If you look closely, when you log out
>> of the app, there's a second where you're logged out, but the app is still
>> visible. This is because the revalidation trigger occurs when
>> RequestFactory attempts to do an RPC. We should have a re-validation
>> trigger before this - that is, before the app UI even loads, we should do
>> an auth check.
>>
>> Also, it's clunky to have to do custom hackery to preserve the
>> gwt.codesvr param and know the app's home page in the revalidation case
>> triggered by RequestFactory. I don't think there's any way we can get
>> around baking the home page URL into the server code if we want to be able
>> to trigger a re-validation due to a RequestFactory RPC. We could make
>> things a bit nicer by having the DefaultRequestTransport in RequestFactory
>> preserve query params, just so that things work properly in Development
>> Mode.
>>
>> Also, I did not make any changes to the Tablet or Desktop versions; this
>> is something we need to update. Any takers?
>>
>> On Wed, Aug 8, 2012 at 3:42 PM,  wrote:
>>
>>> Reviewers: drfibonacci, tbroyer,
>>>
>>> Description:
>>> Move GAE Auth functionality from Expenses over the MobileWebApp sample.
>>>
>>>
>>> Please review this at 
>>> http://gwt-code-reviews.**appspot.com/1806803/<http://gwt-code-reviews.appspot.com/1806803/>
>>>
>>> Affected files:
>>>   M samples/dynatablerf/README-**MAVEN.txt
>>>   M samples/dynatablerf/pom.xml
>>>   M samples/mobilewebapp/README-**MAVEN.txt
>>>   M samples/mobilewebapp/pom.xml
>>>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
>>> gaerequest/client/**GaeAuthRequestTransport.java
>>>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
>>> gaerequest/client/**GaeAuthenticationFailureEvent.**java
>>>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
>>> gaerequest/client/LoginWidget.**java
>>>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
>>> gaerequest/client/LoginWidget.**ui.xml
>>>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
>>> gaerequest/client/**ReloadOnAuthentic

[gwt-contrib] Re: Move GAE Auth functionality from Expenses over the MobileWebApp sample. (issue1806803)

[Rajeev Dayal]

Should mention that this review is based on
http://gwt-code-reviews.appspot.com/1804803/.

I've moved over the authentication functionality from Expenses to
MobileWebApp. While I was at it, I corrected some of the inherent auth
problems in Expenses (and therefore MobileWebApp when I copied this over).
I've described these issues below:

After logging out, if MobileWebApp.html is loaded from cache (which it can
be, because we're not setting the no-store header), there would be a
problem with the redirection back to the login page. The triggering event
was an unauthorized post to /gwtRequest, which the GaeAuthFilter would
trap. Unfortunately, /gwtRequest is not a valid URL to navigate to after
login. I had to add code to always go back to MobileWebApp.html. I also had
to add logic to preserve the gwt.codesvr parameter, so that the user would
not be dropped out of development mode on the redirection.

While this fix works, it's not perfect, there are still inherent problems
with this re-authentication approach. If you look closely, when you log out
of the app, there's a second where you're logged out, but the app is still
visible. This is because the revalidation trigger occurs when
RequestFactory attempts to do an RPC. We should have a re-validation
trigger before this - that is, before the app UI even loads, we should do
an auth check.

Also, it's clunky to have to do custom hackery to preserve the gwt.codesvr
param and know the app's home page in the revalidation case triggered by
RequestFactory. I don't think there's any way we can get around baking the
home page URL into the server code if we want to be able to trigger a
re-validation due to a RequestFactory RPC. We could make things a bit nicer
by having the DefaultRequestTransport in RequestFactory preserve query
params, just so that things work properly in Development Mode.

Also, I did not make any changes to the Tablet or Desktop versions; this is
something we need to update. Any takers?

On Wed, Aug 8, 2012 at 3:42 PM,  wrote:

> Reviewers: drfibonacci, tbroyer,
>
> Description:
> Move GAE Auth functionality from Expenses over the MobileWebApp sample.
>
>
> Please review this at 
> http://gwt-code-reviews.**appspot.com/1806803/
>
> Affected files:
>   M samples/dynatablerf/README-**MAVEN.txt
>   M samples/dynatablerf/pom.xml
>   M samples/mobilewebapp/README-**MAVEN.txt
>   M samples/mobilewebapp/pom.xml
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthRequestTransport.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**GaeAuthenticationFailureEvent.**java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/LoginWidget.**java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/LoginWidget.**ui.xml
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/client/**ReloadOnAuthenticationFailure.**java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/server/**GaeAuthFilter.java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/server/**UserServiceLocator.java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/server/**UserServiceWrapper.java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/shared/GaeUser.java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/shared/**GaeUserServiceRequest.java
>   A samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> gaerequest/shared/**MakesGaeRequests.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/client/App.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/client/**ClientFactory.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/client/**ClientFactoryImpl.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/client/desktop/**MobileWebAppShellDesktop.java
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/client/desktop/**MobileWebAppShellDesktop.ui.**xml
>   M samples/mobilewebapp/src/main/**java/com/google/gwt/sample/**
> mobilewebapp/shared/**MobileWebAppRequestFactory.**java
>   M samples/mobilewebapp/src/main/**webapp/WEB-INF/appengine-web.**xml
>   M samples/mobilewebapp/src/main/**webapp/WEB-INF/web.xml
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] submit chrome dev mode plugin to chrome web store?

[Rajeev Dayal]

Hey Daniel,

We do need to post the chrome devmode plugin to the webstore. I'll take
care of that this week.

I also need to rebuild the devmode plugin, as there were some fixes that
went into it a while back that were never put into a distributable binary.


Rajeev

On Mon, Aug 6, 2012 at 6:53 PM, Istvan Soos  wrote:

> Hi,
>
> A quick fix that might help:
>
> 1. right click on the chrome icon>Properties>Shortcut
> 2. add in target: --enable-easy-off-store-extension-install
> 3. open chrome and navitage to extensions ( chrome://chrome/extensions/ )
> 4. drag and drop on it the plugin (should be in your download folder
> if you tried to install it before and didn't succeed)
>
> Regards,
>Istvan
>
> On Mon, Aug 6, 2012 at 12:44 PM, Daniel Kurka 
> wrote:
> > Hi everyone,
> >
> > today at work I was setting up a GWT installation on windows for a new
> > coworker and noticed that with chrome 21 we can not install extension
> > anymore. (They need to be in the chrome web store). I also noticed an
> issue
> > popping up on the issue tracker on the exact same thing:
> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7569
> >
> > Does anyone have this covered or are we just hearing about this change to
> > chrome right now?
> >
> > -Daniel
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Update Maven sample pom.xml files to use maven-compiler-plugin's annotation processing functiona... (issue1804803)

[Rajeev Dayal]

Also update the docs here:

http://code.google.com/p/google-web-toolkit/wiki/WorkingWithMaven

(a bit premature, sorry..)

On Mon, Aug 6, 2012 at 3:10 PM,  wrote:

> Reviewers: drfibonacci, tbroyer,
>
> Description:
> Update Maven sample pom.xml files to use maven-compiler-plugin's
> annotation processing functionality. It is now understood by m2e-apt, so
> we can get rid of the hacks we had to put in to make this work in
> Eclipse/GPE. This also gets rid of the nasty need to refresh the project
> (manually) after a build.
>
>
> Please review this at 
> http://gwt-code-reviews.**appspot.com/1804803/
>
> Affected files:
>   M samples/dynatablerf/README-**MAVEN.txt
>   M samples/dynatablerf/pom.xml
>   M samples/mobilewebapp/README-**MAVEN.txt
>   M samples/mobilewebapp/pom.xml
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: fixes ISSUE 7479 (typo in javadoc) (issue1770803)

[Rajeev Dayal]

Patch posted here (had already submitted the original before that):

http://gwt-code-reviews.appspot.com/1801803

On Tue, Jul 31, 2012 at 8:24 AM,  wrote:

> On 2012/07/30 19:10:14, rdayal wrote:
>
> Since this is just a doc fix can you also fix 4575?
> http://code.google.com/p/**google-web-toolkit/issues/**detail?id=4575
>
> http://gwt-code-reviews.**appspot.com/1770803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] GWT 2.5 RC1 increases mgwt showcase by 22%

[Rajeev Dayal]

Daniel mentioned that somehow the CSS for the blackberry permutation is
ending up in the iPhone permutation. That can't just be a Cell Widget issue.

On Mon, Jul 23, 2012 at 12:24 AM, Ray Cromwell wrote:

>
> Are you using any Cell widgets by any chance?
>
> I've seen that the Mail sample and ShowCase sample both shrunk, but the
> MobileWebApp sample increased in size. This leads me to believe it's not a
> compilation issue, but something in the user library pulling in a lot of
> extra code.
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] “GWT no longer supports ChromeFrame. The implementation caused more bugs than it solved.”

[Rajeev Dayal]

Hey guys,

This is my fault. I mis-interpreted the code change. As the change to "fix"
this issue was basically a "revert" of the original commit that was
supposed to add ChromeFrame support, I incorrectly assumed that reverting
the code would prevent special behavior for ChromeFrame (which I figured we
needed in order to make it work). Had I read issue #6665 more carefully, I
would have realized that this fix was to improve support for ChromeFrame,
not remove it entirely.

I'll be sure to fix this statement in the release notes.

However, what *is* our level of support for ChromeFrame? My thought is that
we should guarantee support for it, just as we guarantee support for Chrome
itself...that's probably a question for the steering committee, though..


Rajeev

On Mon, Jul 16, 2012 at 3:38 AM, Manuel Carrasco Moñino
wrote:

> As you say chromeframe works ok with 2.5.0, so I agree that the release
> note is incorrect and may confuse people.
>
> The way to check that chromeframe is active is just to check whether the
> useragent contains the word 'safari' like we do with any other browser, and
> this only happens when the plugin is activated  [1].
>
> I've checked 2.5.0-rc1 and it works as expected. I have used most recent
> and an old version (May-2011) of chromeframe with working applications and
> I've not seen any problem.
>
> So in my opinion that release note should be removed or modified to say
> that 2.5 regression issues introduced in 2.4
>
> - Manolo
>
> [1]
> http://www.chromium.org/developers/how-tos/chrome-frame-getting-started/understanding-chrome-frame-user-agent
>
>
>
>
> On Fri, Jul 13, 2012 at 12:09 PM, Thomas Broyer wrote:
>
>> This is from the release notes: “GWT no longer supports ChromeFrame. The
>> implementation caused more bugs than it solved.”
>>
>> I suppose it's related to
>> http://code.google.com/p/google-web-toolkit/issues/detail?id=6665 but
>> then it's rather than GWT 2.5 now *finally* correctly supports
>> ChromeFrame (even when disabled). Anyone has insights as to what this is
>> really meaning? Is it more about “it might work, but we no longer guarantee
>> it”? (but had it ever been the case?)
>>
>> FYI, people took notice and some of them are already interpreting it
>> wrong:
>> http://stackoverflow.com/questions/11467822/does-chrome-browser-support-gwt-2-5
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: GWT 2.5 RC1 increases mgwt showcase by 22%

[Rajeev Dayal]

Hey Daniel,

Did you find out anything more about this? Sorry for the long delay in
reply - many people were on vacation after the holiday break.

I'd agree that we need to fix this for RC2/final.

Would you be able to file a bug for this so we can track it?


Rajeev

On Sat, Jun 30, 2012 at 1:07 AM, Daniel Kurka
wrote:

> I Just took a quick look and its actually not just client bundle thats
> affected. If someone wants to take a look here are both soyc reports:
> https://www.dropbox.com/s/2edw73vpmde9oz4/soyc.zip
>
> -Daniel
>
>
>
> Am 30.06.2012 um 06:58 schrieb Daniel Kurka:
>
> I just had a few hours of spare time and went ahead and checked out the
> GWT release candidate together with mgwt showcase.
>
> I was quite staggered to see that it increases the Javascript size by 22%.
> I just took a brief look at the SOYC report and it seems that it fails to
> remove unused CSS from different permutations (that are actually not
> active). Somehow CSS for the blackberry permutations ends up in the iPhone
> permutation
>
> I am going to drill deeper into this, but to me this is quite critical.
>
> -Daniel
>
>
>
>
>
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Update to 1.6 for javac source/target. (issue1753803)

[Rajeev Dayal]

Oh shoot, fat-fingered - I'm sorry about that!

On Thu, Jun 21, 2012 at 11:12 AM, Thomas Broyer  wrote:

>
>
> On Thursday, June 21, 2012 4:46:36 PM UTC+2, rdayal wrote:
>>
>> Reviewers: jat, t.broyer_google.com,
>
>
> Ah ah!
> People please do not read anything in Rajeev's mistake above ;-)
> There's no current plan that I work at Google in the near future.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Move test Messages files from client to shared; was missed in r10061. This was causing I18NSuite... (issue1752803)

[Rajeev Dayal]

No prob, thx for your help in doing so :).

On Wed, Jun 20, 2012 at 7:38 PM,  wrote:

> LGTM
>
> Thanks for tracking this down and fixing it.
>
> http://gwt-code-reviews.**appspot.com/1752803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] tests

[Rajeev Dayal]

Hey,

I'm running into the same thing on a Linux workstation. It's a virtual
instance, so I'm not sure if that might have something to do with it, but
it's definitely strange.

Here's one exception that I see:

  [junit] Exception in thread "pool-1-thread-1"
java.lang.RuntimeException: Unable to read from byte cache
[junit] at
com.google.gwt.dev.util.DiskCache.transferToStream(DiskCache.java:201)
[junit] at
com.google.gwt.dev.util.DiskCacheToken.writeObject(DiskCacheToken.java:91)
[junit] at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[junit] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[junit] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[junit] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[junit] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
[junit] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
[junit] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[junit] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[junit] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[junit] at java.util.ArrayList.writeObject(ArrayList.java:673)
[junit] at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[junit] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[junit] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[junit] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[junit] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[junit] at
com.google.gwt.dev.javac.CachedCompilationUnit.writeObject(CachedCompilationUnit.java:223)
[junit] at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[junit] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[junit] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[junit] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[junit] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[junit] at
com.google.gwt.dev.javac.PersistentUnitCache$6.run(PersistentUnitCache.java:446)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[junit] at java.lang.Thread.run(Thread.java:679)
[junit] Caused by: java.io.EOFException
[junit] at java.io.RandomAccessFile.readInt(RandomAccessFile.java:776)
[junit] at
com.google.gwt.dev.util.DiskCache.transferToStream(DiskCache.java:188)
[junit] ... 35 more

Which suggests that we're attempting to read data from the cache before
we've added anything..

and then tons of the form:

  [junit] Exception in thread "pool-1-thread-3" java.lang.NullPointerException
[junit] at
com.google.gwt.dev.util.DiskCache.transferToStream(DiskCache.java:187)
[junit] at
com.google.gwt.dev.util.DiskCacheToken.writeObject(DiskCacheToken.java:91)
[junit] at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[junit] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[junit] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[junit] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[junit] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
[junit] at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:438)
[junit] at
com.goo

[gwt-contrib] Re: Bundle org.json in gwt-dev and javax.validation into gwt-user, unbundle from requestfactory-* (issue1731804)

[Rajeev Dayal]

On Wed, Jun 13, 2012 at 5:04 PM, Brian Slesinsky wrote:

> I don't think we support Java 1.5 anymore?
> http://code.google.com/p/google-web-toolkit/issues/detail?id=6790
>
> https://groups.google.com/forum/#!msg/google-web-toolkit/fATw0rL8lSE/xbxX5Hf8ozUJ
>
> I'm totally fine with dropping support for 1.5 altogether.
>

+1. I think support was dropped in GWT 2.4.


>
> - Brian
>
> On Wed, Jun 13, 2012 at 9:47 AM,   wrote:
> > I've removed the changes concerning javax.validation, so it's still
> > distributed as a separate JAR.
> >
> > org.json is now bundled in gwt-dev, no longer bundled into
> > requestfactory-* JARs, and distributed as a separate JAR in the SDK (so
> > that requestfactory users have the choice to user gwt-servlet-deps.jar
> > with both org.json and javax.validation, or either one or both the
> > separate JARs; Android users can just pick the javax.validation JAR, as
> > org.json is provided by the platform).
> >
> > I've also updated JSON to use the original, Java-1.6-compiled, JAR, as
> > GWT now requires Java6 anyway. That way, the JAR in the SDK is named
> > json.jar
> > I've kept the json-1.5.jar in gwt-servlet-deps.jar though, in case
> > people are still using Java 1.5 on the server-side.
> >
> > That means that for those people using Java 1.5 on their server, if they
> > didn't use gwt-servlet-deps.jar but relied on the org.json bundled into
> > requestfactory-server.jar, they'll have to download the json-1.5.jar
> > (either from the GWT SVN or elsewhere), or switch to using
> > gwt-serlvet-deps.jar.
> > Given that Java 1.5 has reached EOL, I don't really mind giving them a
> > bit more work (IFF they update GWT!)
> > I'm open to reverting to json-1.5.jar though.
> >
> > https://gwt-code-reviews.appspot.com/1731804/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Packaging issue: org.json and RequestFactory

[Rajeev Dayal]

On Wed, Jun 6, 2012 at 2:38 AM, James Nelson  wrote:

> I wouldn't be opposed to having differing rules for the GWT SDK
>> package downloadable at code.google.com and the Maven artifacts.
>> AFAIK, the original idea of bundling them into gwt-user.jar (and
>> gwt-dev.jar) was to make things simpler for users (just put gwt-dev
>> and gwt-user in the classpath).
>
> For everyone using artifacts from "The Central Repository" (Maven,
>> Ivy, Gradle, etc.), bundled dependencies hurt more than they help.
>>
>
> For unfamiliar users, having everything bundled up into a single massive
> jar does reduce barrier to entry.
> For anyone with a remotely complex build, being able to pick and choose
> dependencies can be of vital importance.
> Aggressive bundling and excessive repackaging can lead to major bloat and
> potential classpath-order problems,
> but just adding one jar is the simplest way to get started.
>
> So, this suggests that gwt-user could be made a bloated super-jar, with
> validation and json et al. builtin by jarring in maven.
> Build this jar from gwt-core, validation, json, elemental, etc. artifacts,
> but also export these artifacts independently, including a sparse
> gwt-core.jar.
> Anyone who doesn't want the bloated omni-jar can take the sparse-jar and
> declare dependencies manually, then export only what they need to the
> server,
> while everyone else can just carry on like normal.
>

I like that idea..


>
> In maven, what's in gwt-user now would become gwt-core, and replace
> gwt-user with a pom stub that just bundles up the omni gwt-user.jar.
> gwt-core would be a kernel module representing c.g.g.core.Core + all the
> .gwt.xml and interfaces / utilities needed to build the gwt environment;
> the maven build for core could still suck in all the required dependencies
> to run with packaging pom, and just export a jar/gwtar in release stage.
>

Makes sense.


>
> So, gwt-user.jar and gwt-core.jar would be mutually exclusive {emit
> warning that classpath is setup inefficiently}.
> If you take gwt-core, you must also take all other jars you actually need,
> or deal with classpath manually.
> If you take gwt-user, don't take any of the other jars; everything is
> right there.
>

Though gwt-user.jar would actually encompass gwt-core.jar, right?


>
> For IDE / GPE, let it be known that gwt-user is the deprecated way to get
> up and running quickly,
> and gwt-core + jars_you_need is the advanced way to get up to max
> performance.
>

Seems reasonable.


> It may be more work to maintain, and gwt-user.jar updates can only be
> issued with a stable set of dependencies bundled,
> but at least the component projects and artifacts can be updated
> independently in maven central, and then by hand in user classpath;
> that way, if there is an update to request factory or elemental or
> widgetFrameworkXYZ, the sub-modules can release updates without waiting on
> a version release.
>

The problem I see here is if there are two different sub-components that
require a different version of the same dependency. I think we'd have to
make sure that this never happens.

So, you're saying that we only release a new gwt-user.jar whenever there's
a major release? What does this mean with the Maven setup that you're
proposing? That we only update the gwt-user.jar POM whenever we have a
major release?


> For anyone exporting third party libraries, they can just mimic the
> gwt-user pom to create their own omni-jar, and instruct clients to remove
> everything but gwt-server/dev.
>
>
>
>> +1
>> (though it'd be even better to ditch org.json and use the upcoming
>> JSON lib; BTW, is it the one from PlayN?)
>>
>
> +1 more.  Some example syntax I saw somewhere suggests it's very PlayN
> like;
>
>
> >> I'll try to submit a patch to have it fixed in 2.5 but we must first
>> >> settle on the appropriate way to do it (both for the GWT SDK and for
>> Maven
>> >> artifacts), and I'd also like your feedback on what would be the
>> appropriate
>> >> workaround while waiting for 2.5.
>>
>
> For maven, gwt-user 2.4 cannot be changed, but a gwt-core 2.4 can be added
> with packaging pom, and dependencies declared as needed.
> For IDE users, a snapshot release with gwt-core and bundled jars, and
> maybe a pom.xml / generateProject.sh to do mvn eclipse:eclipse to setup
> classpath?
>
> That or just a README with setup instructions / warnings.
>

I'd be inclined to leave 2.4 as-is, and move forward with any packaging
changes in 2.5.


>
> > Whatever we do, we're going to have to make sure that we update GPE so
>> that
>> > it knows to add the appropriate dependent jars to the classpath.
>>
>> I don't know for the "AppEngine connected Android project" (or
>> whatever its exact name), but a "standard" GWT project currently is
>> missing javax.validation (and of course org.json).
>>
>
> I bring along javax.validation et. al in an eclipse user library, so
> they're available to dev mode, but never on server classpath.
>
> --
> http://groups.

Re: [gwt-contrib] Packaging issue: org.json and RequestFactory

[Rajeev Dayal]

On Thu, May 31, 2012 at 12:07 PM, Thomas Broyer  wrote:

> On Thu, May 31, 2012 at 5:00 PM, Rajeev Dayal wrote:
> > Hey Thomas,
> >
> > Thanks for pointing this out. This is pretty whacked, and is probably a
> > symptom of a problem that we've had for a long time - how do we handle
> > dependencies on GWT? Should we bundle them, re-package them, or require
> the
> > user to add them to the classpath?
>
> I wouldn't be opposed to having differing rules for the GWT SDK
> package downloadable at code.google.com and the Maven artifacts.
> AFAIK, the original idea of bundling them into gwt-user.jar (and
> gwt-dev.jar) was to make things simpler for users (just put gwt-dev
> and gwt-user in the classpath).
> For everyone using artifacts from "The Central Repository" (Maven,
> Ivy, Gradle, etc.), bundled dependencies hurt more than they help.
> As for repackaging (JarJar), this should definitely be done for
> patched dependencies! (and deployed to Central as separate artifacts,
> just like Sonatype deployed a pre-release andor patched versions of
> Guice and Guava:
> http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.sonatype.sisu%22
> AFAICT, Sisu Guice is/was used in Maven 3.0)
>
> > Other replies inline:
> >
> > On Tue, May 29, 2012 at 4:51 AM, Thomas Broyer 
> wrote:
> >>
> >> Hi all,
> >>
> >> it looks like there's an issue in packaging the GWT SDK (and GWT maven
> >> artifacts): org.json is not bundled gwt-user. That makes it harder to
> use
> >> RequestFactory out-of-the-box, as DevMode will have
> NoClassDefFoundErrors
> >> when trying to *send* a request to the server. org.json is bundled into
> >> requestfactory-server.jar and gwt-servlet-deps.jar, which makes it
> usable
> >> out-of-the-box on the server-side; it's also bundle into
> >> requestfactory-client.jar so you can easily run VM client-side code too
> (in
> >> unit-tests, an Android app, etc.) To run RF code in DevMode, you'd have
> to
> >> add the org.json JAR (downloaded somewhere on the internet) or the
> >> requestfactory-client.jar (which duplicates a lot of classes from
> >> gwt-user.jar), or the gwt-servlet-deps.jar (which is supposedly related
> to
> >> server-side code only) to your classpath; this is not intuitive.
> >
> >
> > Is this a new problem? It seems that this would have always been present.
> > Was a recent change made to expose this?
>
> As you said, it's probably been there from the beginning.
> I've always been using Maven since GWT 2.1-M1, and it had dependency
> issues too (neither org.json nor javax.validation were declared as
> dependencies), so I didn't noticed it; and we're depending on org.json
> transitively from other dependencies so it didn't affected us with
> newer GWT versions either.
>
> > All those options that you mention are less-than-ideal. My preference
> would
> > be to have them download org.json from the Internet, but it rubs me the
> > wrong way that it won't work out of the box.
>
> Well, org.json hasn't changed for a while, and validation-api is a
> "standard" so it won't change either; so it's rather safe to bundle
> them in the GWT SDK (but not within the JARs, that's a different
> issue).
>

Yes, that would be fine (bundling them with the GWT SDK, but not actually
putting them in gwt-user.jar)

>
> >> What's striking is that javax.validation is *not* bundled that way
> >> (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as
> a
> >> separate JAR in the SDK; it's not even bundled into gwt-user.jar.
> >>
> >> There's a real discrepancy between org.json and javax.validation wrt
> >> packaging in the SDK, and none of them is satisfactory.
> >>
> >> requestfactory-* JARs contain org.json but not javax.validation
> >> gwt-user contains none of them
> >> gwt-servlet-deps is made of only org.json and javax.validation, so why
> >> ship javax.validation in addition to it?
> >>
> >> IMO, both dependencies should receive equal treatment: either ship as
> >> separate JARs in the SDK (json.jar and validation-api.jar), or be
> bundled
> >> where needed (if you ask me, only in gwt-user.jar –similar to what's
> done
> >> with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or
> >> duplicated as requestfactory-deps.jar, as they are dependencies for both
> >> requestfactory-client and requestfactory-server).
> >
> >
>

[gwt-contrib] Re: Re: Add Map support to RequestFactory (issue 6132056)

[Rajeev Dayal]

Yep, you're on the CLA list.

On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley 
wrote:

> Just to check, was everything okay with the CLA I signed?
>
> On 7 June 2012 16:56, James Horsley  wrote:
>
> Thanks Rajeev. Let me know if there's anything else you need with it.
>
>
> On 7 June 2012 16:18, Rajeev Dayal  wrote:
>
> Thomas, thanks for jumping in.
>
> James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
> to get it in there, as it's an important patch. We just didn't want to
> force this patch in 2.5.0, which is what we would have to do with the
> current workload.
>
> Thanks so much for working on this.
>
>
> On Thu Jun 07 06:23:58 GMT-400 2012,  wrote:
>
> Totally agree on this needing another round. Also, hearing about the
> plans for a 2.5.1 release which this could potentially be a candidate
> for is great.
>
> Thanks again.
>
> On 2012/06/07 09:56:52, t.broyer wrote:
> > On 2012/06/07 09:22:24, james.horsley wrote:
> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> make it
> > > into GWT 2.5 as we were really looking to use RF with Maps without
> having to
> > use
> > > a patched version of GWT built from source internally.
>
> > We're planning a 2.5.1 soon after 2.5.
> > There are also several issues with Map support in AutoBeans (reported
> only
> > recently) which I'd like to get fixed at the same time (some of them
> are related
> > to how maps are encoded/decoded, so I'd like to have it the same in
> both
> > AutoBeans and RF; see
> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> instance,
> > which you seem to have avoided by using a slightly different
> serialization path
> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> AutoBean's
> > serialization).
> > Finally, to be honest, I think we need at least one more round here: I
> need some
> > more time to wrap my head around it.
>
>
>
> http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http://codereview.appspot.com/6132056/>
>
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Use shared.GWT to avoid ClassNotFoundExceptions (issue1722803)

[Rajeev Dayal]

Committed as r11024.

On Thu May 31 14:13:23 GMT-400 2012, Rajeev Dayal 
wrote:

> Hey all,
>
> I don't think I'll have a chance to look at this by the afternoon. John,
> if you could check into this, that would be great.
>
> I believe I was up-to-date; did a sync right before I ran the tests. I
> didn't check to see if some other change had landed that would have caused
> this problem.
>
> I'll check the status later this evening - thanks for helping out.
>
>
>
> Rajeev
>
>
> On Thu, May 31, 2012 at 1:23 PM,  wrote:
>
>
>  I remember seeing that before (and unrelated to the GWT.create
>
> changes) --
>
> are you sure you are up to date?
>
>
> Thanks for chiming in John--I was just running the test that failed
> (ScriptInjectorTest) here locally in Eclipse, both web and prod mode,
> and it works fine. Wasn't really seeing how the isClient change could
> cause this, but am currently cleaning/rebuilding to try from ant.
>
> http://gwt-code-reviews.**appspot.com/1722803/<http://gwt-code-reviews.appspot.com/1722803/>
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Add Map support to RequestFactory (issue 6132056)

[Rajeev Dayal]

Thomas, thanks for jumping in.

James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
to get it in there, as it's an important patch. We just didn't want to
force this patch in 2.5.0, which is what we would have to do with the
current workload.

Thanks so much for working on this.


On Thu Jun 07 06:23:58 GMT-400 2012,  wrote:

> Totally agree on this needing another round. Also, hearing about the
> plans for a 2.5.1 release which this could potentially be a candidate
> for is great.
>
> Thanks again.
>
> On 2012/06/07 09:56:52, t.broyer wrote:
> > On 2012/06/07 09:22:24, james.horsley wrote:
> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> make it
> > > into GWT 2.5 as we were really looking to use RF with Maps without
> having to
> > use
> > > a patched version of GWT built from source internally.
>
> > We're planning a 2.5.1 soon after 2.5.
> > There are also several issues with Map support in AutoBeans (reported
> only
> > recently) which I'd like to get fixed at the same time (some of them
> are related
> > to how maps are encoded/decoded, so I'd like to have it the same in
> both
> > AutoBeans and RF; see
> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> instance,
> > which you seem to have avoided by using a slightly different
> serialization path
> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> AutoBean's
> > serialization).
> > Finally, to be honest, I think we need at least one more round here: I
> need some
> > more time to wrap my head around it.
>
>
>
> http://codereview.appspot.com/6132056/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Use shared.GWT to avoid ClassNotFoundExceptions (issue1722803)

[Rajeev Dayal]

Hey all,

I don't think I'll have a chance to look at this by the afternoon. John, if
you could check into this, that would be great.

I believe I was up-to-date; did a sync right before I ran the tests. I
didn't check to see if some other change had landed that would have caused
this problem.

I'll check the status later this evening - thanks for helping out.



Rajeev

On Thu, May 31, 2012 at 1:23 PM,  wrote:

>
>  I remember seeing that before (and unrelated to the GWT.create
>>
> changes) --
>
>> are you sure you are up to date?
>>
>
> Thanks for chiming in John--I was just running the test that failed
> (ScriptInjectorTest) here locally in Eclipse, both web and prod mode,
> and it works fine. Wasn't really seeing how the isClient change could
> cause this, but am currently cleaning/rebuilding to try from ant.
>
> http://gwt-code-reviews.**appspot.com/1722803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

Committed as r11004.

On Thu May 31 11:34:33 GMT-400 2012, Rajeev Dayal 
wrote:

> Ran the latest patch set through google's battery of tests; everything
> passed.
>
> On Thu May 31 09:22:21 GMT-400 2012,  wrote:
>
> On 2012/05/31 01:56:32, skybrian wrote:
> > LGTM (assuming tests still pass)
>
> Because I must confess I didn't run them on the last few patch-sets, I
> just ran "ant clean testrf" and then the RequestFactorySuite in both
> prod and dev mode from within Eclipse, and I confirm everything's OK.
>
> http://gwt-code-reviews.appspot.com/1601806/<https://www.google.com/url?sa=D&q=http://gwt-code-reviews.appspot.com/1601806/>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Ignore qualified refs with generics (issue1578808)

[Rajeev Dayal]

Sounds good.

On Thu May 31 11:51:45 GMT-400 2012,  wrote:

> > Double-ping. If we can't land this one soon, we'll defer it to 2.5.1.
>
> Yeah, let's just defer. I haven't had time to get back in to it and
> answer Scott's question. This is just an optimization anyway, and I
> don't know what, or if any, affect it had on perceived performance.
>
> http://gwt-code-reviews.appspot.com/1578808/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

Ran the latest patch set through google's battery of tests; everything
passed.

On Thu May 31 09:22:21 GMT-400 2012,  wrote:

> On 2012/05/31 01:56:32, skybrian wrote:
> > LGTM (assuming tests still pass)
>
> Because I must confess I didn't run them on the last few patch-sets, I
> just ran "ant clean testrf" and then the RequestFactorySuite in both
> prod and dev mode from within Eclipse, and I confirm everything's OK.
>
> http://gwt-code-reviews.appspot.com/1601806/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Packaging issue: org.json and RequestFactory

[Rajeev Dayal]

Hey Thomas,

Thanks for pointing this out. This is pretty whacked, and is probably a
symptom of a problem that we've had for a long time - how do we handle
dependencies on GWT? Should we bundle them, re-package them, or require the
user to add them to the classpath?

Other replies inline:

On Tue, May 29, 2012 at 4:51 AM, Thomas Broyer  wrote:

> Hi all,
>
> it looks like there's an issue in packaging the GWT SDK (and GWT maven
> artifacts): org.json is not bundled gwt-user. That makes it harder to use
> RequestFactory out-of-the-box, as DevMode will have NoClassDefFoundErrors
> when trying to *send* a request to the server. org.json is bundled into
> requestfactory-server.jar and gwt-servlet-deps.jar, which makes it usable
> out-of-the-box on the server-side; it's also bundle into
> requestfactory-client.jar so you can easily run VM client-side code too (in
> unit-tests, an Android app, etc.) To run RF code in DevMode, you'd have to
> add the org.json JAR (downloaded somewhere on the internet) or the
> requestfactory-client.jar (which duplicates a lot of classes from
> gwt-user.jar), or the gwt-servlet-deps.jar (which is supposedly related to
> server-side code only) to your classpath; this is not intuitive.
>

Is this a new problem? It seems that this would have always been present.
Was a recent change made to expose this?

All those options that you mention are less-than-ideal. My preference would
be to have them download org.json from the Internet, but it rubs me the
wrong way that it won't work out of the box.


>
> What's striking is that javax.validation is *not* bundled that way
> (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as a
> separate JAR in the SDK; it's not even bundled into gwt-user.jar.
>
> There's a real discrepancy between org.json and javax.validation wrt
> packaging in the SDK, and none of them is satisfactory.
>
>
>- requestfactory-* JARs contain org.json but not javax.validation
>- gwt-user contains none of them
>- gwt-servlet-deps is made of only org.json and javax.validation, so
>why ship javax.validation in addition to it?
>
> IMO, both dependencies should receive equal treatment: either ship as
> separate JARs in the SDK (json.jar and validation-api.jar), or be bundled
> where needed (if you ask me, only in gwt-user.jar –similar to what's done
> with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or
> duplicated as requestfactory-deps.jar, as they are dependencies for both
> requestfactory-client and requestfactory-server).
>

I'd lean towards to having json.jar and validation-api.jar - even though it
makes it harder to work with out-of-the-box, we're trying to move in the
direction of breaking GWT into smaller components.

Also, when SuperDevMode becomes the default, we're not going to need
org.json or javax.validation on the client-side.


> Now, we have similar issues with Maven artifacts: gwt-user.jar depends on
> javax.validation but not org.json, so the DevMode will fail (whether you
> launch it with "Run As… Web Application" in Eclipse or "mvn gwt:run")
> unless you add a dependency on org.json. org.json is not even
> referenced/documented as an optional dependency (but given that
> javax.validation is not marked as "optional", there's no reason org.json
> would be marked "optional").
> We're currently facing this issue in gwt-maven-archetypes and I'm not sure
> what we should do: add a dependency on requestfactory-client (contains
> duplicate classes from gwt-user) or on org.json (weird as we don't directly
> use org.json classes, and org.json is not marked as an optional dependency
> of gwt-user). https://github.com/tbroyer/gwt-maven-archetypes/pull/16
>

Maybe we need to mark org.json as a required dep of gwt-user? Is this
possible?


>
> I'll try to submit a patch to have it fixed in 2.5 but we must first
> settle on the appropriate way to do it (both for the GWT SDK and for Maven
> artifacts), and I'd also like your feedback on what would be the
> appropriate workaround while waiting for 2.5.
>
>
Whatever we do, we're going to have to make sure that we update GPE so that
it knows to add the appropriate dependent jars to the classpath.


> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Contributor License Agreements question

[Rajeev Dayal]

Just verified that you're added to the corporate CLA list. I think I was
looking at an outdated spreadsheet.

You're all good!


On Fri May 25 10:15:54 GMT-400 2012, Alexandre Ardhuin <
alexandre.ardh...@gmail.com> wrote:

> Confirmation email forwarded.
>
> Thanks,
> Alexandre
>
> 2012/5/25 Rajeev Dayal 
>
> Hey Alexandre,
>
> You're not able to verify that you signed the CLA in the corporate case. I
> looked at our corporate CLA list, and I don't see your name (or that of
> your company) listed there.
>
> I'll do some more digging to see what happened. Did you receive any sort
> of confirmation e-mail? If so, could you forward it to me directly?
>
>
> Thanks,
> Rajeev
>
>
> On Fri May 25 08:55:21 GMT-400 2012, Alexandre Ardhuin <
> alexandre.ardh...@gmail.com> wrote:
>
> Hi all,
>
> A few days ago I submitted a patch (
> http://gwt-code-reviews.appspot.com/1712803/ ) after having followed the
> steps described at
> https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches.
> My CTO had signed the "Corporate Contributor License Agreement" (
> http://code.google.com/legal/corporate-cla-v1.0.html ) . He had provided
> my name and my corporate email ( alexandre.ardhuin at deveryware com ) in
> Schedule A. But with that email, I could not sign in at
> http://gwt-code-reviews.appspot.com , a "Google Account" was required. So
> I signed with a google account ( alexandre.ardhuin.dw at gmail com ) to
> submit my patch.
>
> How can I check to be identified as a cla-signer ?
> Will my patch be taken in account ? I don't see the review made by Thomas
> in this contributors group and I wonder why.
>
> Thanks in advance,
> Alexandre
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Contributor License Agreements question

[Rajeev Dayal]

Hey Alexandre,

You're not able to verify that you signed the CLA in the corporate case. I
looked at our corporate CLA list, and I don't see your name (or that of
your company) listed there.

I'll do some more digging to see what happened. Did you receive any sort of
confirmation e-mail? If so, could you forward it to me directly?


Thanks,
Rajeev


On Fri May 25 08:55:21 GMT-400 2012, Alexandre Ardhuin <
alexandre.ardh...@gmail.com> wrote:

> Hi all,
>
> A few days ago I submitted a patch (
> http://gwt-code-reviews.appspot.com/1712803/ ) after having followed the
> steps described at
> https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches.
> My CTO had signed the "Corporate Contributor License Agreement" (
> http://code.google.com/legal/corporate-cla-v1.0.html ) . He had provided
> my name and my corporate email ( alexandre.ardhuin at deveryware com ) in
> Schedule A. But with that email, I could not sign in at
> http://gwt-code-reviews.appspot.com , a "Google Account" was required. So
> I signed with a google account ( alexandre.ardhuin.dw at gmail com ) to
> submit my patch.
>
> How can I check to be identified as a cla-signer ?
> Will my patch be taken in account ? I don't see the review made by Thomas
> in this contributors group and I wonder why.
>
> Thanks in advance,
> Alexandre
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix this->window confusion in DevMode (issue1620805)

[Rajeev Dayal]

Hey Stephen,

Thanks for the feedback. Replies inline:


On Tue May 08 23:22:49 GMT-400 2012, Stephen Haberman <
stephen.haber...@gmail.com> wrote:

>
> > I agree, but asking anyone to have to make changes in working code
>
> Two things, one is that I don't think any code that relies on this
> behavior could really be called "working". It's dev mode mistakingly
> acting differently than web mode.
>

Agreed, but if you have a ton of internal code that is written in such a
way that flipping on this behavior causes a ton of failures, then it's
going to take time to fix them all. I totally agree that they should be
fixed, but it's going to take a non-trivial amount of time.

I'd rather spend that time working on SuperDevMode and moving people over
to that, where this whole issue of differing implementations between web
mode and dev mode goes away.

>
> > as a consequence of upgrading increases the cost, even if they are
> > good changes.
>
> The other is that (disclaimer, this isn't really a discussion for the
> bug tracker, and is just my personal opinion) I think this extreme
> dedication to backwards compatibility at some point hurts more than it
> helps.
>
> Yes, it means users have 0-change upgrades, which is great if you do
> an upgrade every month (or on every commit, e.g. internally to Google).
>
> But after years of 0-change upgrades, I think the burden of backwards
> compatibility starts to wear on a codebase. Of course every release
> can't be a fresh start, but I think there needs to be a compromise
> that's less-than-every-release but more-than-never.
>

I completely agree that supporting backwards compatibility all of the time
wears on the codebase. However, if you want to suddenly stop supporting
this, you need a clean break. Maybe that clean break is defining a new
user-level library for GWT; maybe it's SuperDevMode, or something else -
but, we do need to define this break at some point soon, and allow for the
breaking of backwards compatibility. I'd also agree that we should be less
conservative going forward.

I just don't think this issue is one where we should start to break
backwards compatibility.


> Furthering my musing that is kind of silly to do in an issue, I think
> Google's internal "all upstream/downstream projects always build from
> trunk" encourages codebases to grow stale as they can never break any
> project ever.
>

:) That's a much larger discussion.


>
> Let's have some forks, branches, or something, that at least
> occasionally lifts this burden of backwards compatibility for those of
> us who are just fine with a yearly-ish/non-bugfix release that has
> breaking changes in the name of a better, cleaner codebase.
>

Stay tuned. There are going to be some major changes in the coming weeks
that allow for much more flexibility than is currently offered to the
external community.

To circle back, let's not put this in to 2.5. I do suggest enabling the
behavior behind a flag, and we can push people to switch to the new
behavior. Internally, we can then tell people the stricter (correct)
behavior is going to become the default, and get rid of the flag. Stephen,
what do you think? Would you be amenable to adding the code for the flag?

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Add Map support to RequestFactory (issue 6132056)

[Rajeev Dayal]

Hey James,

Sorry, I have not had a chance to look this one over, but I am planning to.
The turnaround on patches has been pretty bad for the past while, and we're
actively going to make some changes soon that will result in big
improvements (I hope).

In the meantime, we're trying to review and land patches as fast as we can.
No, you're not being pushy :).


Rajeev


On Thu May 10 16:15:15 GMT-400 2012,  wrote:

> Rajeev, did you get a chance to look the patch over?
>
> I have no clue on what the turnaround is on submitted patches so
> hopefully am not being too pushy. I saw that GWT 2.5 is close to being
> released and I'd love to have this functionality available in it.
>
> Thanks!
>
> On 2012/05/07 20:28:44, james.horsley wrote:
> > The instructions at
>
> https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
> say
> > to add this patch to the issue
> > (http://code.google.com/p/google-web-toolkit/issues/detail?id=5524)
> but I don't
> > see how to do that. Is there a permission I'm missing?
>
>
>
> http://codereview.appspot.com/6132056/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

Hey Thomas,

Good find! I thought there was something funny with finishTestAndReset, but
I wouldn't have spotted that :).

Replies inline:

On Fri May 04 22:08:03 GMT-400 2012,  wrote:

> OK, found it: the issue in EditorTest is that the SimpleBar that the
> setUserName is applied to and the one in the SimpleFoo's barField are
> not the same instances!
>
> The instances are initialized in response to the finishTestAndReset call
> from RequestBatcherTest, which explains the differing behavior when this
> test is commented out (or moved to run later): in this case, everything
> is initialized from the call to findSimpleFooById at the beginning of
> EditorTest#test.
>

Ok, I see.


>
> The real issue is actually that finisTestAndReset resets SimpleFoo
> before resetting SimpleBar, so when SimpleFoo asks for
> SimpleBar.getSingleton() it gets the "previous instance", and then the
> SimpleBars are reinitialized.
> When everything is initialized in EditorTest#test() through
> findSimpleFooById, the SimpleFoo's barField and SimpleBar are the same
> instances. It might be that they differ in subsequent tests but that
> just does not seem to be an issue then.
>

Ugh, that sucks - fortunately, it's just an artifact of testing. A better
fix might be to change the reset(...) in SimpleFoo to automatically reset
the SimpleBar entity? What do you think?


>
> Inverting the order of the reset calls in finishAndResetTest fixes the
> issue.
>
> I also simplified the changes to AbstractRequestContext (adding a
> "diff'ing" state to the AbstractRequestContext/RequestState that's then
> used in the various AutoBean Categories to
> a) avoid auto-editing proxies (what was done by temporarily locking the
> context in patchsets 1 to 6)
> b) change the equals() behavior for EntityProxies (fixing issue 5952)
>

Ok, I'll take a detailed look.


>
> http://gwt-code-reviews.appspot.com/1601806/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

On Sun Apr 29 07:17:38 GMT-400 2012,  wrote:

> On 2012/04/29 10:42:26, tbroyer wrote:
> > On 2012/04/27 16:11:29, rdayal wrote:
> > > Hey Thomas,
> > >
> > > When I ran the tests after applying your change, I saw a failure in
> > > EditorTest.test:
> > >
> > > aused by: junit.framework.AssertionFailedError:
> expected=EditorBarTest
> > > actual=FOO
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:164)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:1)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequest.onSuccess(AbstractRequest.java:129)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.processPayload(AbstractRequestContext.java:377)
>
> > > ... 28 more
> > >
> > >
> > > Are you seeing the same thing?
>
> > On my local branch (off of r10773), "ant -f user/build.xml
> test.dev.htmlunit
>
> -Dgwt.junit.testcase.includes=com/google/web/bindery/requestfactory/gwt/client/ui/EditorTest.class"
>
> > passes:
>
> > [junit] Running
> > com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest
> > [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 49,035
> sec
>
> > I'll rebase and see if that changes anything.
>
> Rebased upon r10958, "ant clean dist-dev" and then ran test.dev.htmlunit
> and test.web.htmlunit, with the same BUILD SUCCESSFUL results.
>
> I tried with OpenJDK (6u24) and Oracle JDK (6u27)
> (with the clean/dist-dev being run with OpenJDK; only the test being run
> with both JDKs)
>
> Also tried with OpenJDK 7u3 (clean dist-dev, then test.dev.htmlunit;
> using "JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ ant ..." on the
> command line; I'm not really sure the JAVA_HOME honored everywhere using
> this technique); same (successful) results.
>

Ok, more information - I'm only getting the failure when I run the entire
RequestFactorySuite. Still digging, but can you tell me if you see a
failure if you run the entire suite?

>
> http://gwt-code-reviews.appspot.com/1601806/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Serialization of Final Fields in RPC (issue1380807)

[Rajeev Dayal]

Hey Stephen,

Thanks for the info. So we should probably try and land it. From my quick
summary of the comment thread, it looks like there's disagreement on the
implementation. Can you or John save me some time and fill me in on the
history?


Rajeev


On Fri May 04 14:24:11 GMT-400 2012,  wrote:

>
> > If it's important enough, we should land it, but my impression is that
> it isn't
>
> It is the 7th-ranked bug in the issue tracker (by number of stars). But,
> as John said, it's had 5 years to get all those votes.
>
>
> http://gwt-code-reviews.appspot.com/1380807/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Serialization of Final Fields in RPC (issue1380807)

[Rajeev Dayal]

HA!

If it's important enough, we should land it, but my impression is that it
isn't  - so maybe it should die a quiet death.


On Fri May 04 14:13:42 GMT-400 2012, John Tamplin  wrote:

> On Fri, May 4, 2012 at 12:15 PM,  wrote:
>
> Was debating whether this one should go in for GWT 2.5, but my
> inclination is to skip it. Please let me know if anyone feels strongly
> about this.
>
> http://gwt-code-reviews.**appspot.com/1380807/
>
>
> It has been waiting a few years, another one won't hurt.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

Ah, thanks - though it's interesting that there'd be a browser-specific
failure in response to this type of change. Thanks for pointing out the
difference though; I'll double-check.

On Mon Apr 30 13:22:34 GMT-400 2012, Freeland Abbott 
wrote:

> Depending on which targets are failing, we also run with FF3, which Thomas
> most likely doesn't
>
> On Mon Apr 30 11:10:32 GMT-400 2012, Rajeev Dayal 
> wrote:
> Thanks, Thomas. I'll take a look and see what's going on in our
> environment. I wonder if it's an order-of-execution failure (implying that
> there's statefulness between test runs that's not getting cleared).
>
> On Sun Apr 29 07:17:38 GMT-400 2012,  wrote:
>
> On 2012/04/29 10:42:26, tbroyer wrote:
> > On 2012/04/27 16:11:29, rdayal wrote:
> > > Hey Thomas,
> > >
> > > When I ran the tests after applying your change, I saw a failure in
> > > EditorTest.test:
> > >
> > > aused by: junit.framework.AssertionFailedError:
> expected=EditorBarTest
> > > actual=FOO
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:164)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:1)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequest.onSuccess(AbstractRequest.java:129)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.processPayload(AbstractRequestContext.java:377)
>
> > > ... 28 more
> > >
> > >
> > > Are you seeing the same thing?
>
> > On my local branch (off of r10773), "ant -f user/build.xml
> test.dev.htmlunit
>
> -Dgwt.junit.testcase.includes=com/google/web/bindery/requestfactory/gwt/client/ui/EditorTest.class"
>
> > passes:
>
> > [junit] Running
> > com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest
> > [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 49,035
> sec
>
> > I'll rebase and see if that changes anything.
>
> Rebased upon r10958, "ant clean dist-dev" and then ran test.dev.htmlunit
> and test.web.htmlunit, with the same BUILD SUCCESSFUL results.
>
> I tried with OpenJDK (6u24) and Oracle JDK (6u27)
> (with the clean/dist-dev being run with OpenJDK; only the test being run
> with both JDKs)
>
> Also tried with OpenJDK 7u3 (clean dist-dev, then test.dev.htmlunit;
> using "JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ ant ..." on the
> command line; I'm not really sure the JAVA_HOME honored everywhere using
> this technique); same (successful) results.
>
> http://gwt-code-reviews.appspot.com/1601806/<https://www.google.com/url?sa=D&q=http://gwt-code-reviews.appspot.com/1601806/>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Fix for issue 5952: RequestContext#isChanged. (issue1601806)

[Rajeev Dayal]

Thanks, Thomas. I'll take a look and see what's going on in our
environment. I wonder if it's an order-of-execution failure (implying that
there's statefulness between test runs that's not getting cleared).

On Sun Apr 29 07:17:38 GMT-400 2012,  wrote:

> On 2012/04/29 10:42:26, tbroyer wrote:
> > On 2012/04/27 16:11:29, rdayal wrote:
> > > Hey Thomas,
> > >
> > > When I ran the tests after applying your change, I saw a failure in
> > > EditorTest.test:
> > >
> > > aused by: junit.framework.AssertionFailedError:
> expected=EditorBarTest
> > > actual=FOO
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:164)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:1)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequest.onSuccess(AbstractRequest.java:129)
>
> > > at
> > >
>
> com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.processPayload(AbstractRequestContext.java:377)
>
> > > ... 28 more
> > >
> > >
> > > Are you seeing the same thing?
>
> > On my local branch (off of r10773), "ant -f user/build.xml
> test.dev.htmlunit
>
> -Dgwt.junit.testcase.includes=com/google/web/bindery/requestfactory/gwt/client/ui/EditorTest.class"
>
> > passes:
>
> > [junit] Running
> > com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest
> > [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 49,035
> sec
>
> > I'll rebase and see if that changes anything.
>
> Rebased upon r10958, "ant clean dist-dev" and then ran test.dev.htmlunit
> and test.web.htmlunit, with the same BUILD SUCCESSFUL results.
>
> I tried with OpenJDK (6u24) and Oracle JDK (6u27)
> (with the clean/dist-dev being run with OpenJDK; only the test being run
> with both JDKs)
>
> Also tried with OpenJDK 7u3 (clean dist-dev, then test.dev.htmlunit;
> using "JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/ ant ..." on the
> command line; I'm not really sure the JAVA_HOME honored everywhere using
> this technique); same (successful) results.
>
> http://gwt-code-reviews.appspot.com/1601806/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix PopupPanel.center when content has changed (issue1573803)

[Rajeev Dayal]

Thanks!

On Fri Apr 06 10:52:30 GMT-400 2012,  wrote:

> LGTM
>
> http://gwt-code-reviews.appspot.com/1573803/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Adding a spot for database column name in Column. Allows us to create an updated SQL statement w... (issue1503806)

[Rajeev Dayal]

No worries, we're leaving it in :).

On Thu Apr 05 19:37:49 GMT-400 2012, John Porter Simons 
wrote:

> It's handy, and we depend on it now. Definitely let me know if you remove
> it so we can subclass Column.
>
> On Thu, Apr 5, 2012 at 5:19 PM,  wrote:
>
> Leave it in.  We've already spent way too long debating a simple string
> field.  I don't feel strongly enough that it should be removed.
>
> http://gwt-code-reviews.**appspot.com/1503806/
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: Adding a spot for database column name in Column. Allows us to create an updated SQL statement w... (issue1503806)

[Rajeev Dayal]

Wow, you're right. Good catch. I'll follow up and see what's going on here..

On Thu Apr 05 17:02:10 GMT-400 2012,  wrote:

>
> > Looks like this one is not going to be accepted.
>
> It was actually already committed...if the decision was to not add it,
> it needs to be reverted.
>
> http://gwt-code-reviews.appspot.com/1503806/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Re: scheglov pointed out a leak in compilation units in dev mode after a refresh (issue1490801)

[Rajeev Dayal]

We're gearing up for a GWT 2.5, so I'd either like to get this in, or close
the issue if it will never make it into a GWT release.

On Thu Apr 05 15:42:05 GMT-400 2012,  wrote:

> On 2012/04/05 19:39:54, rdayal wrote:
> > Ping. Is this patch dead, or do we still want to get this in?
>
> I remember that we were not able to push it into release (2.4 ?).
> But this problem is still causing problems in GWT Designer.
>
> http://gwt-code-reviews.appspot.com/1490801/
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Permutation Specific SymbolMap (issue1652803)

[Rajeev Dayal]

On Fri Mar 02 13:09:00 GMT-500 2012,  wrote:

> On 2012/03/02 10:39:39, acleung wrote:
>
> Are you missing the module files (.gwt.xml) that define this new
> property?
>
>
> http://gwt-code-reviews.appspot.com/1652803/
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Who does RequestFactory stuff now?

[Rajeev Dayal]

Hey Jeff,

Add me as a reviewer. I'm not as well-versed in RequestFactory as Ray, but
I'm committed to learning quickly ;).


Rajeev

On Fri, Oct 28, 2011 at 10:46 AM, Jeff Larsen  wrote:

>  Ray was in the process of reviewing a patch of mine before he left. Who
> should take that over, or should I continue to try to work with Ray on that?
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Make form event getTypes public. (issue1582803)

[Rajeev Dayal]

On Thu, Oct 27, 2011 at 3:15 PM,  wrote:

>
>  LGTM
>>
>
> Thanks.
>
>
>  (as a side note, I always wondered why these events are not in
>>
> com.google.gwt.event.dom; I believe we could add them there and have the
> existing ones extend the new ones)
>
> Good point, I didn't think about that. I'll keep that in mind but leave
> it for another CL for now.
>
>
>  Oh, and BTW, rjrjr is no longer a Googler; I wonder who to assign this
>>
> CL to;
>
>> jgw? jlabanca? fredsa?
>>
>
> Crazy; that is news to me. I found his G+ post--and also saw your
> comment about the GWT team changing. I'd been assigning reviews to some
> of those people.
>
> Dunno, should ask on gwt-contrib, I guess.


Sadly, Ray has left!

You can definitely still assign reviews to whomever you think is most
appropriate, but add me to the review if you're not getting a response, and
I'll make sure it gets some attention.


>
>
> http://gwt-code-reviews.**appspot.com/1582803/
>
> --
> http://groups.google.com/**group/Google-Web-Toolkit-**Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Add README step to use the Google Web Toolkit SDK in the gwt-user project so that users can run ... (issue966802)

[Rajeev Dayal]

Okay, thanks for checking this out. I'll run some more tests and report back
my results.

On Sat, Nov 27, 2010 at 7:43 AM, Miguel Méndez  wrote:

> Actually, I'm not sure that this is accurate.  I just tried it out against
> gwt-user and gwt-dev with natures and builders on in a clean eclipse Helios
> install (no GPE) and I did not see any exceptions thrown.  There were no
> visible exceptions and the error log was not updated.
>
> It seems worth it to take a look and see if it is eclipse version specific.
>
> On Wed, Nov 24, 2010 at 10:31 AM,  wrote:
>
>> I think that jat is right - if you have a builder defined on your
>> project that Eclipse does not know about, it will throw an exception.
>>
>> For now, let's go with this update to the README. I think, as a future
>> step, we should add the natures and builders to the gwt-user and gwt-dev
>> project, and make it a necessary step for them to install GPE.
>>
>>
>> http://gwt-code-reviews.appspot.com/966802/show
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>
>
> --
> Miguel
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Add README step to use the Google Web Toolkit SDK in the gwt-user project so that users can run ... (issue966802)

[Rajeev Dayal]

No, I don't think it will. I think the nature will be ignored. But let me
verify that before putting my foot in my mouth.

On Wed, Nov 17, 2010 at 1:59 PM, Ray Ryan  wrote:

> And all the examples as well.
>
> I thought one of you GPE guys told me that eclipse would barf if it saw
> that nature and the plugin was not installed?
>
> On Wed, Nov 17, 2010 at 9:41 AM,  wrote:
>
>> Looks good to me.
>>
>> I wonder why we haven't taken the step of adding the GWT Nature to the
>> gwt-user project's .eclipse file...
>>
>>
>> http://gwt-code-reviews.appspot.com/966802/show
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] [google-web-toolkit] r8838 committed - Placeholder for RC1 Maven and GPE artifacts.

[Rajeev Dayal]

Sorry, I'm not sure what you're referring to here.

On Wed, Sep 22, 2010 at 1:58 PM, Patrick Julien  wrote:

> Hmm, does that mean we would still be stuck using only static methods?
>  I mean, it's not that far out to introduce a helper class to find
> types.
>
>
> On Wed, Sep 22, 2010 at 1:35 PM,   wrote:
> > Revision: 8838
> > Author: rda...@google.com
> > Date: Wed Sep 22 10:34:59 2010
> > Log: Placeholder for RC1 Maven and GPE artifacts.
> >
> > http://code.google.com/p/google-web-toolkit/source/detail?r=8838
> >
> > Added:
> >  /2.1.0.RC1
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Re: Eclipse: GDT - Scala plugin cooperation problem

[Rajeev Dayal]

On Sun, Sep 5, 2010 at 10:29 PM, Martin Mauch wrote:

> Installing the Scala plugin into a fresh copy of Eclipse works fine.
> I haven't tried installing and uninstalling the GPE. I could try that if it
> helps.
>

If you could try this, that would be great.


> Concerning the launch configuration:
> Eclipse didn't even start, so I think it should be unrelated to any launch
> configurations.
>
> If the problem doesn't occur with other people's Eclipse installations
> don't consider it important.
> Atm I'm OK with using two Eclipse installations for Scala and GWT.
>
> Thanks!
>   Martin
>
>
> On Wed, Aug 25, 2010 at 18:30, Rajeev Dayal  wrote:
>
>> If you uninstall GPE and leave the Scala plugin, does everything work?
>> What type of launch configuration are you using? Is it a Web Application
>> launch configuration?
>>
>>
>> On Wed, Aug 25, 2010 at 3:06 AM, Martin Mauch wrote:
>>
>>> I'm running into the same problem here.
>>> Is there any known solution?
>>>
>>> On 15 Jul., 16:09, Marek  wrote:
>>> > My Eclipse hangs up while startup (showing gwt plugin as actually
>>> > loaded) and while changing run configuration properties pages. I've
>>> > checked for thread dumps while this occured and in my opinion problem
>>> > lies between Google Eclipse Plugin (any from v 1.3.2 and v 1.3.3) and
>>> > Scala plugin (2.8.0-final). Eclipse hangs on thread with stacktrace:
>>> >
>>> > at java.util.zip.ZipFile.open(Native Method)
>>> > at java.util.zip.ZipFile.(Unknown Source)
>>> > at java.util.zip.ZipFile.(Unknown Source)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.
>>> java:
>>> > 2453)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragm
>>> entRoot.java:
>>> > 152)
>>> > at
>>> org.eclipse.jdt.internal.core.ClassFile.getBytes(ClassFile.java:
>>> > 316)
>>> > at
>>> >
>>> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
>>> pect.ajc
>>> > $around
>>> >
>>> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
>>> spect
>>> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
>>> Fragment.java:
>>> > 73)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JarPackageFragment.buildStructure(JarPackageF
>>> ragment.java:
>>> > 54)
>>> >
>>> > from second dump:
>>> >
>>> > at java.util.zip.Inflater.inflateBytes(Native Method)
>>> > at java.util.zip.Inflater.inflate(Unknown Source)
>>> > - locked <0x0f9b44f0> (a java.util.zip.ZStreamRef)
>>> > at java.util.zip.InflaterInputStream.read(Unknown Source)
>>> > at java.io.BufferedInputStream.read1(Unknown Source)
>>> > at java.io.BufferedInputStream.read(Unknown Source)
>>> > - locked <0x0f9b94d8> (a java.io.BufferedInputStream)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsByteArray(Util.
>>> java:
>>> > 345)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.compiler.util.Util.getZipEntryByteContent(Util.jav
>>> a:
>>> > 511)
>>> > at
>>> org.eclipse.jdt.internal.core.ClassFile.getBytes(ClassFile.java:
>>> > 320)
>>> > at
>>> >
>>> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
>>> pect.ajc
>>> > $around
>>> >
>>> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
>>> spect
>>> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
>>> Fragment.java:
>>> > 73)
>>> > at
>>> >
>>> org.eclipse.jdt.internal.core.JarPackageFragment.buildStructure(JarPackageF
>>> ragment.java:
>>> > 54)
>>> >
>>> > from third

Re: [gwt-contrib] Re: Eclipse: GDT - Scala plugin cooperation problem

[Rajeev Dayal]

If you uninstall GPE and leave the Scala plugin, does everything work? What
type of launch configuration are you using? Is it a Web Application launch
configuration?

On Wed, Aug 25, 2010 at 3:06 AM, Martin Mauch wrote:

> I'm running into the same problem here.
> Is there any known solution?
>
> On 15 Jul., 16:09, Marek  wrote:
> > My Eclipse hangs up while startup (showing gwt plugin as actually
> > loaded) and while changing run configuration properties pages. I've
> > checked for thread dumps while this occured and in my opinion problem
> > lies between Google Eclipse Plugin (any from v 1.3.2 and v 1.3.3) and
> > Scala plugin (2.8.0-final). Eclipse hangs on thread with stacktrace:
> >
> > at java.util.zip.ZipFile.open(Native Method)
> > at java.util.zip.ZipFile.(Unknown Source)
> > at java.util.zip.ZipFile.(Unknown Source)
> > at
> >
> org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.
> java:
> > 2453)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragmentRoot.getJar(JarPackageFragm
> entRoot.java:
> > 152)
> > at
> org.eclipse.jdt.internal.core.ClassFile.getBytes(ClassFile.java:
> > 316)
> > at
> >
> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
> pect.ajc
> > $around
> >
> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
> spect
> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
> Fragment.java:
> > 73)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.buildStructure(JarPackageF
> ragment.java:
> > 54)
> >
> > from second dump:
> >
> > at java.util.zip.Inflater.inflateBytes(Native Method)
> > at java.util.zip.Inflater.inflate(Unknown Source)
> > - locked <0x0f9b44f0> (a java.util.zip.ZStreamRef)
> > at java.util.zip.InflaterInputStream.read(Unknown Source)
> > at java.io.BufferedInputStream.read1(Unknown Source)
> > at java.io.BufferedInputStream.read(Unknown Source)
> > - locked <0x0f9b94d8> (a java.io.BufferedInputStream)
> > at
> >
> org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsByteArray(Util.
> java:
> > 345)
> > at
> >
> org.eclipse.jdt.internal.compiler.util.Util.getZipEntryByteContent(Util.jav
> a:
> > 511)
> > at
> org.eclipse.jdt.internal.core.ClassFile.getBytes(ClassFile.java:
> > 320)
> > at
> >
> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
> pect.ajc
> > $around
> >
> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
> spect
> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
> Fragment.java:
> > 73)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.buildStructure(JarPackageF
> ragment.java:
> > 54)
> >
> > from third dump:
> >
> > at java.util.zip.ZipFile.close(Native Method)
> > at java.util.zip.ZipFile.close(Unknown Source)
> > - locked <0x0bc6f540> (a java.util.zip.ZipFile)
> > at
> >
> org.eclipse.jdt.internal.core.JavaModelManager.closeZipFile(JavaModelManage
> r.java:
> > 1553)
> > at
> org.eclipse.jdt.internal.core.ClassFile.getBytes(ClassFile.java:
> > 332)
> > at
> >
> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
> pect.ajc
> > $around
> >
> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
> spect
> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
> Fragment.java:
> > 73)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.buildStructure(JarPackageF
> ragment.java:
> > 54)
> >
> > So I think problem is in:
> > at
> >
> scala.tools.eclipse.contribution.weaving.jdt.cfprovider.ClassFileProviderAs
> pect.ajc
> > $around
> >
> $scala_tools_eclipse_contribution_weaving_jdt_cfprovider_ClassFileProviderA
> spect
> > $1$9776bbb8(ClassFileProviderAspect.aj:145)
> > at
> >
> org.eclipse.jdt.internal.core.JarPackageFragment.computeChildren(JarPackage
> Fragment.java:
> > 73)
> >
> > Not sure what scala weaves without GEP source code. After uninstalling
> > scala, everything works OK.
> >
> > I'm not sure is it GEP or Scala bug, so I post it here.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] STS RPC failures

[Rajeev Dayal]

Great, I think the problem was the AspectJ weaving being disabled. Glad that
it is all working.

On Sat, May 22, 2010 at 6:16 PM, Aaron Steele wrote:

> I reinstalled STS and enabled AspectJ weaving. All systems are go! I
> can launch and run the app from within STS or from the Maven command
> line. Sweet.
>
> Thanks,
> Aaron
>
> On Fri, May 21, 2010 at 4:30 PM, Aaron Steele 
> wrote:
> >> Oh, also, did you enable AspectJ weaving (when STS asked you about
> this)?
> >
> > No. Should I?
> >
> >> [by the way, the second link you posted is broken]
> >
> > Oops! Here it is again: http://goo.gl/SD8s
> >
> >> Hm, this is odd. What actions are you taking (in the UI) when the RPC
> >> exceptions happen?
> >
> > I'm actually just launching the app. After it loads, I see the errors,
> > before any UI interaction.
> >
> >> The dialog that pops up for you to select your WAR directory is
> expected;
> >> the default value is what you should choose. Can you send a text listing
> of
> >> the files that are in that directory (plus subdirectories) during the
> >> launch?
> >
> > After the launch, the recursive directory listing looks like this:
> > http://goo.gl/DAZu
> >
> > Before the launch (immediately after the 'script expenses.roo' command
> > finishes) it looks like this: http://goo.gl/D2Wu
> >
> > In STS I'm doing the following:
> >
> > 1) Import -> Existing Maven Project
> > 2) Run as -> Web Application
> > 3) Select ApplicationScaffold.html
> > 4) Select extrack-0.1.0-SNAPSHOT as WAR directory
> >
> > (At this point, here's what I see in the STS console: http://goo.gl/8unK
> )
> >
> > 5) Open Safari and load
> >
> http://127.0.0.1:/ApplicationScaffold.html?gwt.codesvr=127.0.0.1:9997
> >
> > In Safari I see the loading widget. Then it loads, but not completely
> > (screenshot attached). Then in the console, I see these errors:
> > http://goo.gl/M0J0
> >
> >> On Fri, May 21, 2010 at 3:37 PM, Aaron Steele 
> >> wrote:
> >>>
> >>> Similar results using Roo 1.1.0.M1 to generate the app (as opposed to
> >>> Roo 1.0.2):
> >>>
> >>> http://goo.gl/SD8sx
> >>>
> >>> $ springsource/roo-1.1.0.M1/bin/roo.sh
> >>> roo> script --file expenses.roo
> >>>
> >>> What am I missing?
> >>>
> >>> FWIW, when launching from STS (Run as->Web Application), it launches a
> >>> Finder window and prompts me to select a WAR directory, which defaults
> >>> to target/extrack-0.1.0-SNAPSHOT.
> >>>
> >>> On Fri, May 21, 2010 at 11:24 AM, Rajeev Dayal 
> wrote:
> >>> > The roo directory should be "roo-1.1.0.M1"; so you should be using
> Roo
> >>> > 1.1.0.M1 to generate the app, as opposed to Roo 1.0.2.
> >>> >
> >>> > On Fri, May 21, 2010 at 2:22 PM, Rajeev Dayal 
> wrote:
> >>> >>
> >>> >> I wonder about the version of Roo that you're using. If you navigate
> >>> >> down
> >>> >> into your STS folder, do you see a roo-related directory there? What
> is
> >>> >> the
> >>> >> name of that directory? I think you need to be using the milestone
> >>> >> version
> >>> >> of roo, which is located at //bin/roo.{sh, bat}.
> >>> >>
> >>> >> On Fri, May 21, 2010 at 2:02 PM, Aaron Steele <
> eightyste...@gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> I'm seeing a strange issue with STS where launching a web
> application
> >>> >>> from within STS succeeds, but then RPCs fail with the following
> >>> >>> errors:
> >>> >>>
> >>> >>> http://goo.gl/hAkP
> >>> >>>
> >>> >>> The project I'm running is from /samples/expenses.roo and was
> created
> >>> >>> using the Roo shell (script expenses.roo). If I try running the
> same
> >>> >>> project via 'mvn gwt:run', it works.
> >>> >>>
> >>> >>> Here's my setup:
> >>> >>>
> >>> >>> OS X
> >>> >>> SpringSource Tool Suite (2.3.3.M1)
> >>> >>> - DataNucleus Eclipse Plugins (2.0.2)
> >>> >>> - Google App Engine Java SDK (1.3.4.v201005191217)
> >>> >>> - Google Plugin for Eclipse 3.5 (1.4.0.m1-201005192034)
> >>> >>> - Google Web Toolkit SDK (2.1.0.m1-201005191217)
> >>> >>> - Spring Roo (1.0.2.RELEASE)
> >>> >>>
> >>> >>> Thanks!
> >>> >>> Aaron
> >>> >>>
> >>> >>> --
> >>> >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >>> >>
> >>> >
> >>> > --
> >>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >>>
> >>> --
> >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >>
> >> --
> >> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] STS RPC failures

[Rajeev Dayal]

Oh, also, did you enable AspectJ weaving (when STS asked you about this)?

On Fri, May 21, 2010 at 3:50 PM, Rajeev Dayal  wrote:

> [by the way, the second link you posted is broken]
>
> Hm, this is odd. What actions are you taking (in the UI) when the RPC
> exceptions happen?
>
> The dialog that pops up for you to select your WAR directory is expected;
> the default value is what you should choose. Can you send a text listing of
> the files that are in that directory (plus subdirectories) during the
> launch?
>
> Also, you shouldn't need to specify "--file expenses.roo"; you should just
> be able to type "script expenses.roo", but I don't think that would make a
> difference anyway.
>
>
>
> On Fri, May 21, 2010 at 3:37 PM, Aaron Steele wrote:
>
>> Similar results using Roo 1.1.0.M1 to generate the app (as opposed to
>> Roo 1.0.2):
>>
>> http://goo.gl/SD8sx
>>
>> $ springsource/roo-1.1.0.M1/bin/roo.sh
>> roo> script --file expenses.roo
>>
>> What am I missing?
>>
>> FWIW, when launching from STS (Run as->Web Application), it launches a
>> Finder window and prompts me to select a WAR directory, which defaults
>> to target/extrack-0.1.0-SNAPSHOT.
>>
>> On Fri, May 21, 2010 at 11:24 AM, Rajeev Dayal  wrote:
>> > The roo directory should be "roo-1.1.0.M1"; so you should be using Roo
>> > 1.1.0.M1 to generate the app, as opposed to Roo 1.0.2.
>> >
>> > On Fri, May 21, 2010 at 2:22 PM, Rajeev Dayal 
>> wrote:
>> >>
>> >> I wonder about the version of Roo that you're using. If you navigate
>> down
>> >> into your STS folder, do you see a roo-related directory there? What is
>> the
>> >> name of that directory? I think you need to be using the milestone
>> version
>> >> of roo, which is located at //bin/roo.{sh, bat}.
>> >>
>> >> On Fri, May 21, 2010 at 2:02 PM, Aaron Steele 
>> >> wrote:
>> >>>
>> >>> I'm seeing a strange issue with STS where launching a web application
>> >>> from within STS succeeds, but then RPCs fail with the following
>> >>> errors:
>> >>>
>> >>> http://goo.gl/hAkP
>> >>>
>> >>> The project I'm running is from /samples/expenses.roo and was created
>> >>> using the Roo shell (script expenses.roo). If I try running the same
>> >>> project via 'mvn gwt:run', it works.
>> >>>
>> >>> Here's my setup:
>> >>>
>> >>> OS X
>> >>> SpringSource Tool Suite (2.3.3.M1)
>> >>> - DataNucleus Eclipse Plugins (2.0.2)
>> >>> - Google App Engine Java SDK (1.3.4.v201005191217)
>> >>> - Google Plugin for Eclipse 3.5 (1.4.0.m1-201005192034)
>> >>> - Google Web Toolkit SDK (2.1.0.m1-201005191217)
>> >>> - Spring Roo (1.0.2.RELEASE)
>> >>>
>> >>> Thanks!
>> >>> Aaron
>> >>>
>> >>> --
>> >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> >>
>> >
>> > --
>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] STS RPC failures

[Rajeev Dayal]

[by the way, the second link you posted is broken]

Hm, this is odd. What actions are you taking (in the UI) when the RPC
exceptions happen?

The dialog that pops up for you to select your WAR directory is expected;
the default value is what you should choose. Can you send a text listing of
the files that are in that directory (plus subdirectories) during the
launch?

Also, you shouldn't need to specify "--file expenses.roo"; you should just
be able to type "script expenses.roo", but I don't think that would make a
difference anyway.



On Fri, May 21, 2010 at 3:37 PM, Aaron Steele wrote:

> Similar results using Roo 1.1.0.M1 to generate the app (as opposed to
> Roo 1.0.2):
>
> http://goo.gl/SD8sx
>
> $ springsource/roo-1.1.0.M1/bin/roo.sh
> roo> script --file expenses.roo
>
> What am I missing?
>
> FWIW, when launching from STS (Run as->Web Application), it launches a
> Finder window and prompts me to select a WAR directory, which defaults
> to target/extrack-0.1.0-SNAPSHOT.
>
> On Fri, May 21, 2010 at 11:24 AM, Rajeev Dayal  wrote:
> > The roo directory should be "roo-1.1.0.M1"; so you should be using Roo
> > 1.1.0.M1 to generate the app, as opposed to Roo 1.0.2.
> >
> > On Fri, May 21, 2010 at 2:22 PM, Rajeev Dayal  wrote:
> >>
> >> I wonder about the version of Roo that you're using. If you navigate
> down
> >> into your STS folder, do you see a roo-related directory there? What is
> the
> >> name of that directory? I think you need to be using the milestone
> version
> >> of roo, which is located at //bin/roo.{sh, bat}.
> >>
> >> On Fri, May 21, 2010 at 2:02 PM, Aaron Steele 
> >> wrote:
> >>>
> >>> I'm seeing a strange issue with STS where launching a web application
> >>> from within STS succeeds, but then RPCs fail with the following
> >>> errors:
> >>>
> >>> http://goo.gl/hAkP
> >>>
> >>> The project I'm running is from /samples/expenses.roo and was created
> >>> using the Roo shell (script expenses.roo). If I try running the same
> >>> project via 'mvn gwt:run', it works.
> >>>
> >>> Here's my setup:
> >>>
> >>> OS X
> >>> SpringSource Tool Suite (2.3.3.M1)
> >>> - DataNucleus Eclipse Plugins (2.0.2)
> >>> - Google App Engine Java SDK (1.3.4.v201005191217)
> >>> - Google Plugin for Eclipse 3.5 (1.4.0.m1-201005192034)
> >>> - Google Web Toolkit SDK (2.1.0.m1-201005191217)
> >>> - Spring Roo (1.0.2.RELEASE)
> >>>
> >>> Thanks!
> >>> Aaron
> >>>
> >>> --
> >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> >>
> >
> > --
> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] STS RPC failures

[Rajeev Dayal]

The roo directory should be "roo-1.1.0.M1"; so you should be using Roo
1.1.0.M1 to generate the app, as opposed to Roo 1.0.2.

On Fri, May 21, 2010 at 2:22 PM, Rajeev Dayal  wrote:

> I wonder about the version of Roo that you're using. If you navigate down
> into your STS folder, do you see a roo-related directory there? What is the
> name of that directory? I think you need to be using the milestone version
> of roo, which is located at //bin/roo.{sh, bat}.
>
>
> On Fri, May 21, 2010 at 2:02 PM, Aaron Steele wrote:
>
>> I'm seeing a strange issue with STS where launching a web application
>> from within STS succeeds, but then RPCs fail with the following
>> errors:
>>
>> http://goo.gl/hAkP
>>
>> The project I'm running is from /samples/expenses.roo and was created
>> using the Roo shell (script expenses.roo). If I try running the same
>> project via 'mvn gwt:run', it works.
>>
>> Here's my setup:
>>
>> OS X
>> SpringSource Tool Suite (2.3.3.M1)
>> - DataNucleus Eclipse Plugins (2.0.2)
>> - Google App Engine Java SDK (1.3.4.v201005191217)
>> - Google Plugin for Eclipse 3.5 (1.4.0.m1-201005192034)
>> - Google Web Toolkit SDK (2.1.0.m1-201005191217)
>> - Spring Roo (1.0.2.RELEASE)
>>
>> Thanks!
>> Aaron
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] STS RPC failures

[Rajeev Dayal]

I wonder about the version of Roo that you're using. If you navigate down
into your STS folder, do you see a roo-related directory there? What is the
name of that directory? I think you need to be using the milestone version
of roo, which is located at //bin/roo.{sh, bat}.

On Fri, May 21, 2010 at 2:02 PM, Aaron Steele wrote:

> I'm seeing a strange issue with STS where launching a web application
> from within STS succeeds, but then RPCs fail with the following
> errors:
>
> http://goo.gl/hAkP
>
> The project I'm running is from /samples/expenses.roo and was created
> using the Roo shell (script expenses.roo). If I try running the same
> project via 'mvn gwt:run', it works.
>
> Here's my setup:
>
> OS X
> SpringSource Tool Suite (2.3.3.M1)
> - DataNucleus Eclipse Plugins (2.0.2)
> - Google App Engine Java SDK (1.3.4.v201005191217)
> - Google Plugin for Eclipse 3.5 (1.4.0.m1-201005192034)
> - Google Web Toolkit SDK (2.1.0.m1-201005191217)
> - Spring Roo (1.0.2.RELEASE)
>
> Thanks!
> Aaron
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: ServletValidate disable external DTDs (issue371801)

[Rajeev Dayal]

If that's the main use case, then I agree. The reason I brought it up was
because App Engine also does its own validation of the web.xml file, so it
seemed like we were doing double-work here.

On Mon, Apr 26, 2010 at 3:33 PM, Scott Blum  wrote:

> I think that would just make things more complicated, and add new
> requirements to SCLs.  This is mostly intended as a sanity check for
> developers who put  tags in their .gwt.xml, but don't update their
> web.xml and then wonder why their RPC service is 404'ing them.
>
>
> On Mon, Apr 26, 2010 at 3:30 PM,  wrote:
>
>> LGTM. Though, I wonder if a better solution would be delegating the
>> validation of web.xml to the SCL, as opposed to doing it in GWT.
>>
>>
>> http://gwt-code-reviews.appspot.com/371801/show
>>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fix flaky MessageTransport test (again). (issue250802)

[Rajeev Dayal]

Hi Kevin,

You're right, it is different, but I don't think the actual test goes
through a different code path. Closing the entire server socket has the same
effect as just closing the output stream. See the docs on getInputStream and
getOutputStream here:

http://java.sun.com/javase/6/docs/api/java/net/Socket.html


Rajeev

On Tue, Mar 23, 2010 at 12:50 PM,  wrote:

> LGTM, but PTAL at my comments.
>
>
> http://gwt-code-reviews.appspot.com/250802/diff/1/2
> File
> dev/core/test/com/google/gwt/dev/shell/remoteui/MessageTransportTest.java
> (right):
>
> http://gwt-code-reviews.appspot.com/250802/diff/1/2#newcode310
>
> dev/core/test/com/google/gwt/dev/shell/remoteui/MessageTransportTest.java:310:
> network.shutdown();
> testExecuteRequestAsyncWithClosedReceiveStreamBeforeResponse is slightly
> different from the test above -- it calls
> network.getServerSocket().getOutputStream().close()
> instead of
> network.getServerSocket().close()
> Are you sure this test is redundant?
> I'd like to see the common code refactored to a private method, if you
> think this test is worth to keep.
>
> http://gwt-code-reviews.appspot.com/250802/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

To unsubscribe from this group, send email to 
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this 
email with the words "REMOVE ME" as the subject.

[gwt-contrib] Re: Code Review Request: Fix flaxy MessageTransport test

[Rajeev Dayal]

I'm testing that if you try to use MessageTransport.executeRequestAsync(..)
and the server side of the network has closed its input stream, then an
exception will be thrown (an ExecutionException with an underlying cause of
IllegalStateException).

I don't think shutdownInput(..) would work, because it says that any input
coming in will be silently discarded. I could probably use
network.getClientSocket(..).shutdownOutput() to achieve the same effect,
though I was really trying to test the case where the server side shut down
the input stream.

I don't know if there is a better way to do this than polling.


On Mon, Mar 15, 2010 at 4:28 PM,  wrote:

> Now we understand the mysterious failure. Thanks for finding it!
>
>
> http://gwt-code-reviews.appspot.com/111808/diff/1/2
> File
> dev/core/test/com/google/gwt/dev/shell/remoteui/MessageTransportTest.java
> (right):
>
> http://gwt-code-reviews.appspot.com/111808/diff/1/2#newcode135
> Line 135: sleepCycles++;
> We should fail with a clear message if the socket cannot be closed,
> rather than a misleading message down stream.
>
>
> http://gwt-code-reviews.appspot.com/111808
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Google Web Toolkit 2.0 RC2 Now Available

[Rajeev Dayal]

Glad its working for you. I'll keep my eyes out for any other reports of
this.

On Mon, Nov 30, 2009 at 12:11 PM, Jeff Chimene  wrote:

> Hi Rajeev,
>
> On Mon, Nov 30, 2009 at 9:32 AM, Rajeev Dayal  wrote:
>
>> Hi Jeff,
>>
>> The method you've outlined below will work. Alternatively, you can blow
>> away everything google related in eclipse/dropins, and then unzip the RC2
>> archive into the dropins directory. There is no dependency between the RC1
>> and RC2 plugins. That is, one does not have to be installed on top of the
>> other.
>>
>
> Yes, that's what I was hoping. However, my mileage did vary in that the GPE
> did not "work" unless I had the RC1 version also installed. The plugin
> simply did not load (no icons, no Google settings in Window > Preferences)
> unless RC1 was also in dropins. The RC2 plugin version showed as installed
> w/ both RC1 and RC2. Too, when both versions were installed, the RC1 plugin
> seemed to dominate (RC2 compiler complaint about the erroneous -style (?)
> switch sent by the RC1 GPE), even though installed software showed the RC2
> version.
>
> A quick scan of the Eclipse startup log showed the RC2 plugin signature. I
> didn't see any load errors, but I'm not an Eclipse expert.
>
> Rather than futzing with what seemed to be p2 weirdness, I opted to install
> the RC2 plugin via the method outlined below.
>
> Joy,
> jec
>
>>
>>
>>
>> On Wed, Nov 25, 2009 at 8:18 PM, Jeff Chimene  wrote:
>>
>>> Here is what I did to get this bad boy working in Linux Eclipse 3.5
>>>
>>>1. remove everything google related from eclipse/dropins;
>>>2. download the file at the GPE url below;
>>>3. unzip into /tmp;
>>>4. navigate to "Help > Install new software > Add > Local";
>>>5. select /tmp/eclipse;
>>>6. uncheck the "Group items by category" if checked. This should
>>>reveal the GPE item
>>>7. check the GPE item and follow the Wizard to complete the
>>>installation.
>>>
>>> Onward thru the fog,
>>> jec
>>>
>>>
>>>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Re: [gwt-contrib] Google Web Toolkit 2.0 RC2 Now Available

[Rajeev Dayal]

Hi Jeff,

The method you've outlined below will work. Alternatively, you can blow away
everything google related in eclipse/dropins, and then unzip the RC2 archive
into the dropins directory. There is no dependency between the RC1 and RC2
plugins. That is, one does not have to be installed on top of the other.


Rajeev

On Wed, Nov 25, 2009 at 8:18 PM, Jeff Chimene  wrote:

> Here is what I did to get this bad boy working in Linux Eclipse 3.5
>
>1. remove everything google related from eclipse/dropins;
>2. download the file at the GPE url below;
>3. unzip into /tmp;
>4. navigate to "Help > Install new software > Add > Local";
>5. select /tmp/eclipse;
>6. uncheck the "Group items by category" if checked. This should reveal
>the GPE item
>7. check the GPE item and follow the Wizard to complete the
>installation.
>
> Onward thru the fog,
> jec
>
>
> On Wed, Nov 25, 2009 at 3:56 PM, Jeff Chimene  wrote:
>
>> Hi,
>>
>> This is a sanity check: do not remove GPE rc1? It looks like there is
>> behavior in GPE rc2 that depends on RC1? I deleted GPE rc1 from the dropins
>> directory, unzipped rc2: no joy. After reinstalling GPE rc1: joy. Perhaps
>> there's another dependency that I don't understand.
>>
>> Anyway, back to bugging
>>
>>
>> On Wed, Nov 25, 2009 at 1:50 PM, John LaBanca wrote:
>>
>>> Hi everyone,
>>>
>>> We're getting close! GWT 2.0 SDK RC2 and Google Plugin for
>>> Eclipse 1.2 RC2 are now available for you to try.
>>>
>>> Download the GWT 2.0 SDK RC2 here:
>>>
>>> http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=gwt-2.0.0-rc2
>>>
>>> The full documentation is still a work in progress, but you can find
>>> instructions for using the updated SDK and Eclipse plugin here:
>>> http://code.google.com/p/google-web-toolkit/wiki/GWT_2_0_RC
>>>
>>> We've resolved several issues since RC1 and we feel pretty darn good
>>> about it, but as always, we caution you against using RC2 in production.
>>>
>>> Windows users who have previously installed the Google Web Toolkit
>>> Developer Plugin for IE will have to uninstall the old version and
>>> install the new version. This action is required because the file locations
>>> have changed. The RC1 installer required administrative
>>> privileges, but the new installer does not. Use the following steps:
>>> 1. Open Control Panel
>>> 2. Select Add/Remove Programs
>>> 3. Select Google Web Toolkit Developer Plugin for IE and click uninstall
>>> 4. During your next attempt to use GWT 2.0 development mode in IE, you
>>> will be prompted to install the GWT Developer Plugin, which will
>>> download an updated installer that does not require administrative
>>> privileges
>>>
>>> We are eager to get your feedback, both good and bad, in the Google Web
>>> Toolkit Developer Forum:
>>>
>>> http://groups.google.com/group/google-web-toolkit
>>>
>>> If you find specific bugs to report, please do so at the GWT Issue
>>> Tracker:
>>> http://code.google.com/p/google-web-toolkit/issues
>>>
>>> Cheers,
>>> John LaBanca, on behalf of the GWT team
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>>
>>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Code Review Request: Send startup URLs over the wire to GPE

[Rajeev Dayal]

Ok, I did confirm it - check out the documentation on
DevModeUI.setStartupURLs - that defines the values in the map.

2009/11/24 Miguel Méndez 

>
>
> On Tue, Nov 24, 2009 at 12:17 AM,  wrote:
>
>> Thanks for the review!
>>
>>
>>
>> http://gwt-code-reviews.appspot.com/111807/diff/1/5
>> File dev/core/src/com/google/gwt/dev/shell/remoteui/RemoteUI.java
>> (right):
>>
>> http://gwt-code-reviews.appspot.com/111807/diff/1/5#newcode169
>> Line 169: public void setStartupUrls(Map urls) {
>> On 2009/11/24 05:14:07, mmendez wrote:
>>
>>> Nit: why was this a Map again?
>>>
>> That's a good question. I think the intent was that that String value in
>> the map would be the URL fragment - i.e. Test.html. The URL would be the
>> fully-qualified URL, such as
>> http://localhost:/Test.html?gwt.codesvr=
>>
>>
>> http://gwt-code-reviews.appspot.com/111807
>>
>
> It would be good to confirm this at some point.
>
> --
> Miguel
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Fixes checkstyle issues introduced by r7001.

[Rajeev Dayal]

The Rietveld link does not seem to be working, but LGTM.

On Wed, Nov 18, 2009 at 5:18 PM,  wrote:

> Reviewers: rdayal, jat,
>
>
>
> Please review this at http://gwt-code-reviews.appspot.com/103813
>
> Affected files:
>  M dev/core/src/com/google/gwt/dev/DevModeBase.java
>
>
> Index: dev/core/src/com/google/gwt/dev/DevModeBase.java
> diff --git a/dev/core/src/com/google/gwt/dev/DevModeBase.java
> b/dev/core/src/com/google/gwt/dev/DevModeBase.java
> index
> 511d5458f848e1493c608c267ba5840971ae98eb..4bb36ecc206b3a9d83999be4cb8bb2ad4a279d95
> 100644
> --- a/dev/core/src/com/google/gwt/dev/DevModeBase.java
> +++ b/dev/core/src/com/google/gwt/dev/DevModeBase.java
> @@ -429,6 +429,10 @@ abstract class DevModeBase implements DoneCallback {
>   return remoteUIClientId;
> }
>
> +public int getCodeServerPort() {
> +  return portHosted;
> +}
> +
> public File getLogDir() {
>   return logDir;
> }
> @@ -444,10 +448,6 @@ abstract class DevModeBase implements DoneCallback {
>   return port;
> }
>
> -public int getCodeServerPort() {
> -  return portHosted;
> -}
> -
> public String getRemoteUIHost() {
>   return remoteUIHost;
> }
> @@ -472,6 +472,10 @@ abstract class DevModeBase implements DoneCallback {
>   this.remoteUIClientId = clientId;
> }
>
> +public void setCodeServerPort(int port) {
> +  portHosted = port;
> +}
> +
> public void setLogFile(String filename) {
>   logDir = new File(filename);
> }
> @@ -484,10 +488,6 @@ abstract class DevModeBase implements DoneCallback {
>   this.port = port;
> }
>
> -public void setCodeServerPort(int port) {
> -  portHosted = port;
> -}
> -
> public void setRemoteUIHost(String remoteUIHost) {
>   this.remoteUIHost = remoteUIHost;
> }
> @@ -502,6 +502,15 @@ abstract class DevModeBase implements DoneCallback {
>   }
>
>   /**
> +   * Controls what code server port to use.
> +   */
> +  protected interface OptionCodeServerPort {
> +int getCodeServerPort();
> +
> +void setCodeServerPort(int codeServerPort);
> +  }
> +
> +  /**
>* Controls whether and where to log data to file.
>*
>*/
> @@ -535,12 +544,6 @@ abstract class DevModeBase implements DoneCallback {
> void setPort(int port);
>   }
>
> -  protected interface OptionCodeServerPort {
> -int getCodeServerPort();
> -
> -void setCodeServerPort(int codeServerPort);
> -  }
> -
>   /**
>* Controls the UI that should be used to display the dev mode server's
> data.
>*/
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Code Review Request: Drop Request/Response Logging Levels down to TRACE

[Rajeev Dayal]

Based on some recent discussions, we're going to make a change where we
modify the log levels depending on what UI the user is using. I'll send out
a CL for this shortly.

On Wed, Nov 18, 2009 at 6:07 PM,  wrote:

>
> http://gwt-code-reviews.appspot.com/103812/diff/1/2
> File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
> (right):
>
> http://gwt-code-reviews.appspot.com/103812/diff/1/2#newcode89
> Line 89: logStatus = TreeLogger.TRACE;
> I still object to requiring anyone who wants to see the HTTP logs having
> to specify -logLevel TRACE.  Maybe I am not the average user, but I
> personally look at the web log all the time.  The browser didn't seem to
> do anything?  Check the log and see if it got the host page, then
> hosted.html, etc.  Wondering why the JSONP request didn't get the
> expected results, look at the URL that was used.  Did it get the new
> version of this file or is the browser caching something? Etc.
>
> Switching to TRACE picks up tons more stuff, which means that users who
> *do* want to see these logs will see *more* log results rather than
> less.
>
> If the concern is about how it is presented in GPE, I think a better
> solution is for RemoteUi.getWebServerLogger() to return a new
> PrintWriterTreeLogger with max(logLevel, WARN) instead.
>
>
> http://gwt-code-reviews.appspot.com/103812
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Code Review Request: Addition of the Message Transport API

[Rajeev Dayal]

Ugh, don't know what Reitveld did here. Ignore the previous two messages; it
somehow merged another code review into this one. Just pay attention to the
first message; the issue 81805 is still valid.

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Google Plugin for Eclipse Source

[Rajeev Dayal]

Happy to hear you're interested in hacking away on the plugin ;)

On Mon, Oct 12, 2009 at 2:32 PM, Sam Gross  wrote:

> I opened issue 4124 (
> http://code.google.com/p/google-web-toolkit/issues/detail?id=4124).
> -Sam
>
>
> On Mon, Oct 12, 2009 at 2:08 PM, Jason Parekh wrote:
>
>> Hey Sam,
>> Unfortunately, there haven't been any recent discussions about open
>> sourcing it.  It's not something we're opposed to (quite the opposite, I'd
>> love to see it happen), but in reality we haven't had time to even think
>> about an open source plan.
>>
>> Definitely open a feature request (if there isn't one already) as it helps
>> us gauge how many people are interested.
>>
>> jason
>>
>> On Mon, Oct 12, 2009 at 1:42 PM, Sam Gross  wrote:
>>
>>>
>>> Any updates on releasing the source for GPE?  I would love to  be able
>>> to start hacking it...
>>>
>>> -Sam
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Invalid version number "2.0" passed to external.gwtOnLoad()

[Rajeev Dayal]

Could we modify the hosted mode servlet so that it set the appropriate
no-cache headers on hosted.html? I've also run into this issue due to
browser caching.
Also, is this file re-generated every time hosted mode is started up? If
not, it definitely should be.

On Mon, Sep 21, 2009 at 1:26 PM, John Tamplin  wrote:

> On Mon, Sep 21, 2009 at 1:06 PM, Ray Ryan  wrote:
>
>> Where does the error message live? This seems like the perfect time to
>> make it a bit more helpful, even if it just suggests to people that they
>> check for both browser and server caching.
>>
>
> HostedHtmlVersion.validHostedHtmlVersion
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: On Mac, emit a -d32 arg for hosted mode when running on a 64-bit vm

[Rajeev Dayal]

Do you also need to apply the same fix for the launch configurations that
are generated by WebAppCreator?

On Thu, Sep 17, 2009 at 3:10 PM,  wrote:

>
>
> http://gwt-code-reviews.appspot.com/68803/diff/1/3
> File user/src/com/google/gwt/user/tools/WebAppCreator.java (right):
>
> http://gwt-code-reviews.appspot.com/68803/diff/1/3#newcode264
> Line 264: + "   value=\"-d32\" else=\"-Dgwt.dummy.arg=\">\n"
> I assume empty string doesn't work here, thus the need for
> -Dgwt.dummy.arg?  Either way, you don't need the equals sign after the
> decl.
>
> http://gwt-code-reviews.appspot.com/68803
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Snow Leopard 32-bit checking fix (1.7 based)

[Rajeev Dayal]

@Ray: To clarify, you need to add -d32 to the launch config though, right?

On Thu, Sep 3, 2009 at 3:22 PM,  wrote:

>
> On 2009/09/03 19:07:53, knorton wrote:
> > Ray,
>
> > Can you confirm that this patch fixes the Snow Leopard issue. It's the
> same
> > patch as before with the typo fixed and the error message slightly
> expanded.
>
> Works on Snow Leopard with IntelliJ as launcher against GWT 2.0 trunk.
> LGTM.
>
> http://gwt-code-reviews.appspot.com/64805
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Issue With Debugging with JDK 1.6.0_14 Has Been Resolved in JDK 1.6.0_16

[Rajeev Dayal]

Hi,
As some of you may recall, there as an issue with debugging if you're using
JDK 1.6.0_14. You'll find that your breakpoints are not hit. More details on
the issue can be found here:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

This issue has been recently fixed in JDK 1.6.0_16. See
http://java.sun.com/javase/6/webnotes/6u16.html for details.



Thanks,
Rajeev

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: ant improvements, round 1

[Rajeev Dayal]

Nice job Freeland! You're an ant-master!

On Thu, Jun 11, 2009 at 10:40 AM, Freeland Abbott wrote:

> Well, if I've saved "serious time" by 10:30am, I'm happy indeed.
> I've got another depends-on-your-hardware-but-I-saw-4min-saving (for
> work-to-do rebuild of samples, so no gain if you use buildonly) out to scott
> already, though it's small enough that anyone who wants to review at
> http://gwt-code-reviews.appspot.com/36802/show can help Scott do real work
> instead of ant file review.
>
>
>
> 2009/6/11 Joel Webber 
>
> w00t indeed. This just saved me serious time this morning already.
>>
>>
>> On Wed, Jun 10, 2009 at 6:35 PM, Scott Blum  wrote:
>>
>>> w00t!!
>>>
>>>
>>> On Wed, Jun 10, 2009 at 5:47 PM, Freeland Abbott wrote:
>>>
 As of r5537, my no-change "ant build" takes 1:55 instead of 19:43, and
 there's still some easy work to do, albeit with obviously diminishing
 returns

 Most of that difference is due to a rather annoying timestamp
 consideration with directory entries in jars; my patch introduces a new Ant
 task, LatestTimeJar, to resolve it.

 The issue is---was---that in general, we jar both
 .../src/com/google/gwt/.../Foo.java and also
 build/out/.../com/google/gwt/.../Foo.class.  The jar file will have one
 directory entry for "com/", the existence of which is actually important to
 GWT as Scott pointed out in the first-round review comments.  But the two
 directories have different touch dates, and we archived the first-named,
 which was usually from .../src/..., with an "old" date by svn.  The second
 build would therefore notice that the *second* instance of "com/" was
 newer than the archived "com/", and therefore jar it again.  (Because we 
 did
 "updates," the entry would have been new after that second cycle.  In some
 cases, notably the servet API classes in alldeps.jar, we had up to four 
 such
 duplicates, though.)  Worse, everything downstream of that error also had 
 to
 be redone... including the samples.





>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: possible ant changes

[Rajeev Dayal]

Hey Freeland,

All of this sounds great. The build scripts have been in severe need of
tweaking for a while, and I'm glad that you've decided to tackle this tricky
issue. I've got a couple of comments about the "ant test" behavior.

If it is the case that a subsequent "ant build" after running "ant build" is
zero work provided that there are no code changes, then I am okay with
having "ant test" depend on "ant build". However, if running "ant build" in
a zero-work case takes a non-trivial amount of time, then we should
re-consider having "ant test" depend on "ant build".

I'd also recommend that running "ant test" rebuild the test classes
themselves, and the build step for test code should be zero-work if "ant
test" is run back-to-back with no test code changes in-between.

A nice-to-have (i.e. less important than all of the other things you
mentioned) would be the ability to specify specific tests via the
command-line (maybe via a system property?).


Rajeev



On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott  wrote:

> So, I'm looking at our ant files, and trying to unwind several problems...
> but I figure I'll ask what other people have as pet peeves, to see if there
> are other games I should play, too.
>
> Here's what's on my mind right now:
>
>- If you run "ant clean build; ant build", the second build should be
>zero work.  It's not, and in particular it painfully builds samples twice.
>It shouldn't.
>- Right now, tests require a staging directory, which implies requiring
>a full distro kit including samples.  That's unnecessary; tests should
>require build, but not much more.
>   - Related to that, too much depends on the semi-recursive -do, which
>   is actually a no-op that depends on dist, which pulls too much in for 
> simple
>   cases.
>- Largely orthogonal, we have checked in files with $ in their names,
>which are supposed to also be usable wtih _ instead.  I've got a system
>which is badly allergic to the $'s, which is why this causes me pain, but
>generally it seems this "should" be addressed with alternate classpath 
> roots
>anyway, so we can test both the two cases easily.
>
> Does anyone have other pain points to add?
>
>
> What I was thinking of doing is:
>
>- Shoot the top-level -do target, in favor of having subtargets
>directly invoke what they need from subprojects, via , and setting
>"target" as is done today... so e.g. target "test" can depend target 
> "build"
>or "buildonly" and then  the "test" targets of dev, user, etc.
>explicitly.  Since -do would no longer exist, it wouldn't depend on "dist"
>to get the fan-out effects, and fan-out can be more selectively controlled.
>- Untangle whatever our double-build is caused by; at first blush, it
>seems to think my directories are out of date relative to the existing jar
>(not the files in them, but the directories themselves).
>- Change the default target to "dist," for back compatibility, since
>that's what build today really does (build depends on -do which depends on
>dist which depends on build in all the subprojects).
>- Twiddle the semantics of "build" to be just building.  I haven't
>decided whether that would include building samples (probably; buildonly
>exists to skip that), but it wouldn't assemble the distro archive and then
>unpack it as dist does.
>- Introduce user/test_dollar and user/test_underbar as java-root
>directories with the obvious subset of files from today's user/test, and an
>adjustment to the test target one or the other is on classpath, controlled 
> I
>think by a system property.
>
> Thoughts on that?
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: locale names

[Rajeev Dayal]

You probably have already considered this, but there are made-up locales in
the I18N tests (PigLatin, for example).

On Mon, Feb 23, 2009 at 1:56 PM, John Tamplin  wrote:

> Does anyone use any made-up locales with GWT?
>
> I am getting ready to commit some changes which, among other things, adds
> support for region-based inheritance and locale aliases.  There are two
> implications of that:
>
>- the code has to be able to understand the structure of the locale tag
>to know which part means what.  Ie, in en_US, is the US a region, script or
>variant?
>- the code has to be able to know meanings of particular tags -- ie, iw
>is the old name for he, so it can map them appropriately as aliases
>
> GWT uses CLDR locales, which are in turn based on 
> BCP47.
> This provides the structure requirement above, so that US can be determined
> to be a region while en_Latn means using the Latin script.  The subtag
> registry, linked from the same page, provides the knowledge of what
> languages are what, if they have been deprecated what the new code is, and
> what the default script is.
>
> Note that since RTL support and plural rules were added in 1.5, there has
> been built-in knowledge of locale names, but things would still work if you
> made up your own as long as stripping off underscore separated parts handled
> inheritance, and you were willing to have to do your own RTL/plural support
> if you cared about it.  This change will mean that you really need to be
> using BCP47 locales, though there are a couple of escape valves:
>
>- x-whatever is a private-use locale tag and can be whatever you want.
>However, you don't get inheritance.
>- there are reserved private ranges -- langauges: qaa-qtz, regions: AA,
>ZZ, QM-QZ, and XA-XZ that can be used for private use
>
> Would this cause anyone any problems?
>
> Note that what is being implemented is strictly compile-time
> inheritance/aliasing, not at runtime as the tables in the selection script
> would be expensive.  These classes are alaso available for the server, and
> when coupled with something like LocaleListLinker you can have your server
> choose the proper initial locale based on the locales that are actually
> supported in the app and inheritance rules.  So for example, you could have
> translations just for es_419 (Spanish as spoken in Latin America), yet still
> get country-specific localizations like date/time/number formats and default
> currencies.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Could we create begin/end css attributes rather then switching left and right?

[Rajeev Dayal]

FWIW, similar sorts of things were done in HorizontalSplitPanel and
DockPanel for the RTL work that was done as part of 1.5. Both of these
panels had a concept of "LEFT" or "EAST" in GWT 1.4, but the bidi-friendly
"LINE_START" and "LINE_END" contants were added in GWT 1.5.

On Wed, Feb 18, 2009 at 9:43 AM, Emily Crutcher  wrote:

>
> On Tue, Feb 17, 2009 at 9:13 PM, BobV  wrote:
>
>>
>> Is @noflip{} insufficient?
>>
>
> The problem manifests when you are using style injector to inject "normal"
> style sheets. When in that mind-set, the flipping of left and right fields
> can seem unexpected. Also is there a way to get the @noflip to parse when
> using the stylesheet with normal css tools?
>
>
>
>>
>> If you go down this route, it would be necessary to add -begin and
>> -end suffixes as well.
>>
>> border-begin: 4px;
>> padding-begin: 5px;
>>
>
> That looks very readable to me.   Darn it, the more cool features you put
> into the css resources, the more I wish we could switch over and not worry
> about "normal" css at all!
>
>
>
>>
>> --
>> Bob Vawter
>> Google Web Toolkit Team
>>
>>
>>
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Code Review Request: Add createApplication method to WebAppCreator that accepts an Eclipse Project Name as an Argument

[Rajeev Dayal]

Hey Scott,

Actually, after some experimenting, this change will not be needed.
Generally, it is not the case that the client of the API needs to specify
both the entry point name and the project name. As such, it is sufficient to
append the project name to the end of the module name, and have
WebAppCreator do its thing.

Sorry about the unnecessary traffic, and thanks for your input.


Rajeev

On Wed, Jan 14, 2009 at 4:35 PM, Rajeev Dayal  wrote:

> Hi Scott,
>
> I'd like to you do a code review. To apply this patch, navigate to the the
> root of the GWT 1.6 releases branch, and perform the following steps:
>
> svn update -r4449
> patch -p0 < updatedWebAppCreatorWithProjectNameParam-r4449.patch
>
> Description:
>
> In the migration from ApplicationCreator to WebAppCreator, the parameter to
> specify the Eclipse project name to the createApplication method was
> removed. This is a useful argument, as there are other clients of this API
> that wish to specify the Eclipse project name directly, instead of having it
> inferred from the module name.
>
> Affected Files:
>
> M  user/src/com/google/gwt/user/tools/.projectsrc
> M  user/src/com/google/gwt/user/tools/App.launchsrc
> M  user/src/com/google/gwt/user/tools/WebAppCreator.java
>
>
> Thanks,
> Rajeev
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Code Review Request: Add createApplication method to WebAppCreator that accepts an Eclipse Project Name as an Argument

[Rajeev Dayal]

Hi Scott,

I'd like to you do a code review. To apply this patch, navigate to the the
root of the GWT 1.6 releases branch, and perform the following steps:

svn update -r4449
patch -p0 < updatedWebAppCreatorWithProjectNameParam-r4449.patch

Description:

In the migration from ApplicationCreator to WebAppCreator, the parameter to
specify the Eclipse project name to the createApplication method was
removed. This is a useful argument, as there are other clients of this API
that wish to specify the Eclipse project name directly, instead of having it
inferred from the module name.

Affected Files:

M  user/src/com/google/gwt/user/tools/.projectsrc
M  user/src/com/google/gwt/user/tools/App.launchsrc
M  user/src/com/google/gwt/user/tools/WebAppCreator.java


Thanks,
Rajeev

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

Index: user/src/com/google/gwt/user/tools/.projectsrc
===
--- user/src/com/google/gwt/user/tools/.projectsrc	(revision 4449)
+++ user/src/com/google/gwt/user/tools/.projectsrc	(working copy)
@@ -1,7 +1,7 @@
 
 
-   @moduleShortName
-   @moduleShortName project
+   @projectName
+   @projectName project



Index: user/src/com/google/gwt/user/tools/App.launchsrc
===
--- user/src/com/google/gwt/user/tools/App.launchsrc	(revision 4449)
+++ user/src/com/google/gwt/user/tools/App.launchsrc	(working copy)
@@ -3,13 +3,13 @@
 
 
 
-
-
-
+
+
+
 
 
 
 
-
+
 
 
Index: user/src/com/google/gwt/user/tools/WebAppCreator.java
===
--- user/src/com/google/gwt/user/tools/WebAppCreator.java	(revision 4449)
+++ user/src/com/google/gwt/user/tools/WebAppCreator.java	(working copy)
@@ -159,7 +159,22 @@
*/
   static void createApplication(String moduleName, File outDir,
   boolean overwrite, boolean ignore) throws IOException {
+createApplication(moduleName, outDir, null, overwrite, ignore);
+  }
 
+  /**
+   * @param moduleName name of the fully-qualified GWT module to create as an
+   *  Application.
+   * @param outDir Where to put the output files
+   * @param projectName The name of the generated Eclipse project for this
+   *  application, or null to generate one automatically
+   * @param overwrite Overwrite an existing files if they exist.
+   * @param ignore Ignore existing files if they exist.
+   * @throws IOException
+   */
+  static void createApplication(String moduleName, File outDir,
+  String projectName, boolean overwrite, boolean ignore) throws IOException {
+
 // Figure out the installation directory
 String installPath = Utility.getInstallPath();
 String gwtUserPath = installPath + '/' + "gwt-user.jar";
@@ -197,6 +212,8 @@
 // Create a map of replacements
 Map replacements = new HashMap();
 replacements.put("@moduleShortName", moduleShortName);
+replacements.put("@projectName", (projectName == null ? moduleShortName
+: projectName));
 replacements.put("@moduleName", moduleName);
 replacements.put("@clientPackage", modulePackageName + ".client");
 replacements.put("@serverPackage", modulePackageName + ".server");

[gwt-contrib] Re: Update datetime symbols

[Rajeev Dayal]

Let's work towards getting this in; we can discuss the script issue in a
separate thread.

Rajeev

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Updated WAR design for GWT 1.6

[Rajeev Dayal]

Hey all,
Sorry to derail from the security question that is being debated, but I
wanted to mention some of my observations as I've been playing around with
the DynaTable2 sample.

If the "-out" directory is unspecified, the application fails to launch. I
think this is probably because it is looking in the same directory as the
".project" file, which does not contain a "WEB-INF" directory. We can
probably rectify this by choosing a better default if "-out" is unspecified,
such as "war".

Along the same train of thought, if the directory specified by "-out" does
not exist, then the application will fail to launch. We could probably add a
simple sanity check for this.

Finally, I noticed that the DynaTable2 Eclipse project has the
war/WEB-INF/classes directory as its output directory. If you are
manipulating this directory from the command line, and you blow away the
classes directory, you have force a rebuild in Eclipse in order to populate
this necessary directory before launching the application. I guess it is
just a bit odd to me that the "-out" directory, which was previously only
used for output, now is considered to be an "input" directory as well.


Rajeev


On Thu, Oct 30, 2008 at 9:48 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote:

>
> perhaps the solution to the security concern is just to somehow be
> more clear what your actual endpoints are as a function of the modules
> you've inherited. maybe some sort of click-through acknowledgment? the
> compiler could even dump out the list when you compile.
>
> On 10/30/08, Scott Blum <[EMAIL PROTECTED]> wrote:
> > Ray, it's a great point you raise.  And it's possible my wanting to
> > deprecate it is in some way related to not wanting to solve the problem
> of
> > merging into a user's existing web.xml.  For parity between hosted and
> web
> > mode, I feel like if we continue to support servlets, the compiler needs
> to
> > hand this (as well as hosted mode).
> >
> > There is a possible security motivation, however, for not doing this.  I
> > think it's slightly better if a developer explicitly includes your
> servlet
> > in their web.xml.  Otherwise, just by inheriting your module (and future
> > tools might make it very easy to download/install/inherit someone's
> module
> > off the web) they are, perhaps without realizing it, setting themselves
> up
> > to run your code on their production servers.  Not only that, but as a
> > servlet, their code can be controlled directly from the web.  I'm
> imagining
> > someone slipping in a  > class="im.in.ur.datacenter.pwning.ur.Server" />.
> >
> > On Thu, Oct 30, 2008 at 2:55 PM, Ray Cromwell <[EMAIL PROTECTED]>
> wrote:
> >
> >> Does WAR mode offer the same inheritance benefits? What I mean is
> >> this: Today, I provide a servlet that accompanies the
> >> Chronoscope.gwt.xml module. Chronoscope itself has no entry point, it
> >> is a module made to be inherited. Any GWT module that inherits
> >> Chronoscope would get servlet config inherited with no need to
> >> configure anything. "It just works" And with the gwt-maven plugin I
> >> use, the  module descriptors are merged into any web.xml on
> >> behalf of the user, again, hassle-free module inheritance.
> >>
> >> With a pure module like Chronoscope, which has no entry points, but
> >> does have servlets, I'm unsure if it even needs a web.xml. If I
> >> provided one, and another project inherits from Chronoscope, and has
> >> its own web.xml as well, how do the two web.xml instances interact?
> >> Does the entry point module's web.xml win? This then seems to require
> >> that the developer scan the jars of every module he inherits looking
> >> for servlets so that he can add them to his web.xml
> >>
> >> I don't know what the solution is, but I kinda liked the 
> >> module tag and it's ability to be picked up by inheritors.
> >>
> >> -Ray
> >>
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Change Safari XML parse error detection

[Rajeev Dayal]

LGTM. If your document legitimately has a  tag contained by a
 tag, you're really having a bad day.
On Wed, Oct 15, 2008 at 6:49 PM, Bob Vawter <[EMAIL PROTECTED]> wrote:

> Here's a version that should allow a tag named "parseerror", as long
> as it's not contained by a body tag.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR : Change Safari XML parse error detection

[Rajeev Dayal]

It might be worth noting in the XMLParser javadoc that XML documents
containing the '' element will not parse correctly.

On Wed, Oct 15, 2008 at 5:45 PM, BobV <[EMAIL PROTECTED]> wrote:

> This patch simplifies the XML parse error detection to not look for a
> specific style applied to the error document.
>
> Diffstat:
>  XMLParserImplSafari.java |61 + 5 - 0 !
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: releases/1.6 merge from trunk

[Rajeev Dayal]

I think it should go in. It would be fairly annoying to have the build be
prevented from completing just because a command-line SVN client is not
available.

On Wed, Oct 15, 2008 at 11:26 AM, Scott Blum <[EMAIL PROTECTED]> wrote:

> Well I'll be.  Thanks for pointing that out.  c3717 wasn't terribly
> important, so methinks I'll just remove it from the log message.
>
> Anyone have a serious problem with 
> c3717not 
> going into 1.6?
>
> On Wed, Oct 15, 2008 at 3:05 AM, Sam Gross <[EMAIL PROTECTED]> wrote:
>
>> Hey Scott,
>> The trunk fixes merged into releases/1.6 in r3739 seemed to have missed
>> c3717.
>>
>> Regards,
>> Sam
>>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: [gwt-team] Release Notes for review

[Rajeev Dayal]

"HTTPRequests no long POST instead of GET in some IE installs because of
incorrect XHR selection"
should be

"HTTPRequests no longer POST instead of GET in some IE installs because of
incorrect XHR selection"

On Tue, Oct 14, 2008 at 4:20 PM, John LaBanca <[EMAIL PROTECTED]> wrote:

> Alright, please take a final look at the changes you all recommended and
> give a LGTM if the release notes look good.
> http://www.corp.google.com/~jlabanca/release_notes.html
>
> Thanks,
> John LaBanca
> [EMAIL PROTECTED]
>
>
> On Tue, Oct 14, 2008 at 3:08 PM, Scott Blum <[EMAIL PROTECTED]> wrote:
>
>> I don't think anything I did merits explicit release notes call out; let's
>> remember to include a query link for "all fixed issues".
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: [gwt-team] Release Notes for review

[Rajeev Dayal]

"Graceful selection of XHR class in IE6 and IE7: fixes a bug where data
would use POST instead of GET"..
I think it would be better to directly call out that this problem affected
RequestBuilder and RPC.

"Time.valueOf no longer tries to determine radix values"...

Instead of mentioning the radix problem, say that Time.valueOf correctly
parses values with leading zeros

On Tue, Oct 14, 2008 at 9:44 AM, John LaBanca <[EMAIL PROTECTED]> wrote:

> John -
>
> Please review the updated release notes for GWT 1.5.3.  If we slip in any
> more fixes, we can update them again as needed.
>
> Thanks,
> John LaBanca
> [EMAIL PROTECTED]
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations

[Rajeev Dayal]

Thanks for keeping us honest, Ray! Alex and I will add a test for this
behavior to DialogBoxTest and reply back on this thread with the code
review.

On Tue, Oct 7, 2008 at 11:26 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:

> Shouldn't there be a change to PopupTest to go along with this?
>
> On 10/7/08, Alex Rudnick <[EMAIL PROTECTED]> wrote:
> >
> > Hey Rajeev :)
> >
> > Thanks for the quick review!
> >
> > Responses inline.
> >
> > On Mon, Oct 6, 2008 at 7:08 PM, Rajeev Dayal <[EMAIL PROTECTED]> wrote:
> >> DialogBox.java
> >> 199: Spelling: sceen --> screen
> > OK
> >
> >> 243: @Overrides on an a method that implements an interface only works
> in
> >> Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code
> >> base still compiles under GWT 1.5. If this change goes in, then GWT will
> >> no
> >> longer be able to compile under JDK 1.5. Let's get rid of the
> annotation.
> > OK
> >
> >> 245: Do you need to recompute clientLeft and clientTop on window resize?
> >> Can
> >> these change based on a window resize?
> >
> > I don't think they can change on resize. For example, in RTL mode for
> > IE, clientLeft is the width of a scrollbar.
> >
> >> General:
> >> I did some testing and it looks good. Dragging in IE6 in RTL mode is
> still
> >> somewhat odd with the jumpiness, but workable. I wonder if we could
> >> improve
> >> RTL dragging in general in IE6/IE7. It might be worth filing a bug for.
> If
> >> I
> >> had to suspect something, it might be the use of CSS expressions and a
> >> hidden IFRAME to prevent scrollbar shine-through. This isn't needed in
> >> IE7,
> >> as they've fixed this at the rendering level, so it might be worth
> >> exploring
> >> at least an improvement for IE7 at some point.
> >> After addressing the above nits, feel free to hit the commit switch.
> >
> > Committed r3724, put in issue 2957.
> >
> > --
> > Alex Rudnick
> > swe, gwt, atl
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations

[Rajeev Dayal]

Hey Alex,

Thanks for putting this fix together. Comments below:

DialogBox.java
199: Spelling: sceen --> screen
243: @Overrides on an a method that implements an interface only works in
Java 1.6. While GWT on the the trunk currently support JDK 1.6, the code
base still compiles under GWT 1.5. If this change goes in, then GWT will no
longer be able to compile under JDK 1.5. Let's get rid of the annotation.
245: Do you need to recompute clientLeft and clientTop on window resize? Can
these change based on a window resize?

General:

I did some testing and it looks good. Dragging in IE6 in RTL mode is still
somewhat odd with the jumpiness, but workable. I wonder if we could improve
RTL dragging in general in IE6/IE7. It might be worth filing a bug for. If I
had to suspect something, it might be the use of CSS expressions and a
hidden IFRAME to prevent scrollbar shine-through. This isn't needed in IE7,
as they've fixed this at the rendering level, so it might be worth exploring
at least an improvement for IE7 at some point.

After addressing the above nits, feel free to hit the commit switch.


Rajeev

On Mon, Oct 6, 2008 at 4:03 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote:

> Hey Rajeev :)
>
> Would you take a look at this patch, implementing Joel's suggestion
> for keeping DialogBox on the screen?
>
> Instead of trying to decide whether a PopupPanel is being positioned
> off the edge, we check whether the user is dragging it off the screen,
> and ignore the drag if the pointer has left the visible window area.
> We use a WindowResizeListener to make sure we always know how wide the
> window is.
>
> Also, in the PopupPanel class, we remove the check that prevents
> placing a popup offscreen -- if a developer wants to programmatically
> put it off screen, that's OK.
>
>
> Seems to work right in RTL and LTR modes on all major browsers.
>
> Thanks!
>
> --
> Alex Rudnick
> swe, gwt, atl
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: make PopupPanels stay on the screen, even in RTL situations

[Rajeev Dayal]

Hey Alex,
LGTM, with the following suggestions and questions:

PopupPanel.java

590: Might want to elaborate a bit here ("Not always zero."). Maybe say
something like: "We check to see if left is less than clientLeft instead of
zero.."


General:

-Might want to add some JavaDoc to PopupPanel.setPopupPosition and the
DialogBox class indicating that the popup cannot be positioned (or dragged,
in the DialogBox case) horizontally outside of the visible area.

Testing:

-it seems that even if the body is horizontally scrollable, one will not be
able to drag the DialogBox into the "scrolled" area offscreen.  Is that the
case?



Rajeev

On Tue, Sep 30, 2008 at 1:54 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote:

> Hey Rajeev,
>
> Would you review this patch for PopupPanel? It's a cleaned up version
> of what we did yesterday. This fixes the odd behavior we noticed where
> Popup Panels could not be placed near the right edge of the screen on
> IE, and normalizes popups in RTL and LTR modes, so they can't be
> dragged off the horizontal edges in either case.
>
> Testing: we made sure popup panels worked as expected in Showcase on
> all major browsers, both in Quirks and Standards mode. GWT tests all
> still work.
>
> Thanks!
>
> --
> Alex Rudnick
> swe, gwt, atl
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: timezone support and updates to DateTimeFormat

[Rajeev Dayal]

Hey Alex,

Good job with this. Generally, looks good, with a bunch of nits (many
related to doc). I've mentioned them on a per-file basis below. If you could
take care of these nits (provided that you agree with them), go ahead and
commit; there's no need to iterate again on this patch unless you make some
significant code changes.


TimeZoneConstants.java

24: should read "..the actual data is defined in property files named
TimeZoneConstants_xx.properties.". The following sentence about deferred
binding is not needed.

28: should read "Time zone data has only been provided for the "en" locale.
Due to the sheer size of the time zone data for each locale, we recommend
that applications retrieve the necessary data (i.e. over RPC) for the user's
locale at run time."

TimeZoneConstants.properties

Though I think it already is, ensure that this file is in UTF-8 format
before committing it. I also wonder if we should be including the rest of
the TimeZone data in this patch. We do the same for DateTimeConstants and
NumberConstants; it is somewhat odd that we're not including all of the
TimeZone data, even if we do not recommend that they pull it in via deferred
binding.

Maybe it would suffice to add a URL in TimeZoneConstants.java indicating
where users can find the rest of the TimeZone data if need be?

TimeZone.java

25-35: All instances of "initiated", "initiate", etc should be changed to
"instantiate", "instantiated", and so on
29: "TimeZoneConstants" could make this a javadoc ref to the
TimeZoneConstants class
38: Could make this comment more accurate - "constants to reference time
zone names in the time zone names array"
39-42: These could all be private
47: "get such string from TimeZoneConstants class, or it can ask server to
provide the string" --> "get such a string from the TimeZoneConstants class,
or it can request the string from the server.."
48: "But either way, the application obtains the  original string from the
data provided in TimeZoneConstant.properties, which was carefully prepared
from CLDR and Olson time zone database." ---> "Either way, the application
obtains the original string from the data provided in the
TimeZoneConstats.properties file, which was carefully prepared using data
from CLDR and the Olson time zone database."
65:Cast to int is unnecessary here
94: "This factory method provide a decent..." --> "This factory method
provides a decent.."
95-96: Add a line break here.
116: Seems like having "GMT" in the array is unnecessary; it can be
concatenated to the end result after the transformation step.
131-143, 145-157: This logic is quite similar; can this be factored out in
some way? Really, the only difference is the prefix (UTC, or Etc/GMT)
169: Not sure why this comment is here.
179: Maybe clarify this sentence: "Return the adjustment amount of time zone
offset" --> "Return the amount to adjust the timezone offset by if daylight
savings time is in effect on the given date". Also, give some indication of
the units that the offset is expressed in.
181: Should be the "date" to check.
199: "The date for which time to retrieve GMT string." --> "The date from
which the time information should be extracted"
200: "GMT String" --> "A GMT representation of the time given by the date"
181-182,198-199: Add a line break here.
207: "To get time zone id for this time zone. For time zone object initiated
from time zone offset, POSIX time zone id will be returned." --> "Return
time zone id for this time zone. For time zone objects that have been
initiated from a time zone offset, the POSIX time zone id will be returned."
217: "To get long time zone name for given date." --> "Returns the long
version of the time zone name for the given date.". Add a line break after
this sentence as well.
218: "The date for which time to retrieve long time zone string." --> "The
date to check to see if daylight savings time is in effect"
238: "To get RFC representation of certain time zone name for given date."
--> "Returns the RFC representation of the time zone name for the given
date." Add a line break after this line as well.
242: This method is very similar to the composeGMTString(int) method. Can
you consolidate these two?
257: "To get short time zone name for given date." -> "Returns the short
time zone name for a given date.". Add a line break after this line as well.
258: Add the word "name" before the period. Add a line break before this
line as well.
266: "To get the standard time zone offset in minutes." --> "Returns the
standard time zone offset in minutes."
268: Need @return tag in javadoc
273: "Check if the given time fall within daylight saving period." -->
"Check to see if the given date and time falls within a daylight savings
time period." Add a line break.
274: "time for which to check." --> "date and time to check"
275: "if daylight time in effect." --> "if daylight savings time is in
effect"

DateTimeFormat.java

In the javadoc that was added for the public static methods, make sure there

[gwt-contrib] Re: [google-web-toolkit commit] r3547 - in trunk: . dev/core dev/core/src/com/google/gwt/dev distro-source distro-source/core/src

[Rajeev Dayal]

I noticed the following issue (I did not review the entire patch):

About.java, line 35: Need the static keyword here; this should be a static
initializer, not an instance initializer.



Rajeev

On Wed, Aug 20, 2008 at 5:40 PM, Scott Blum <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 20, 2008 at 5:03 PM, <[EMAIL PROTECTED]> wrote:
>
>> Modified: trunk/distro-source/core/src/about.html
>>
>> ==
>> -Version @GWT_VERSION@
>> +Version @GWT_VERSION@ 
>> (Subversion @GWT_SVNREV@)
>>
>
>  You got the one in about.txt, but you missed this ^^ one, cf:
>
>
>>  Google Web Toolkit @GWT_VERSION@
>> +(svn revision @GWT_SVNREV@)
>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: GWT 1.5 - Accessibility / ARIA support

[Rajeev Dayal]

Hi all,

I know that this thread has been silent for a while, and I apologize. Alex
and I have completed the a11y documentation, and it can be found here:

http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideAccessibility

Let us know if there are any questions!


Thanks,
Alex and Rajeev

On Wed, Mar 26, 2008 at 10:54 AM, Rajeev Dayal <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Here's a quick rundown of what has been done in GWT 1.5 in terms of
> accessibility support:
>
> -added keyboard support to Menus and TabBars
> -added ARIA roles/states to MenuBar/MenuItem, Tree/TreeItem,
> TabBar/TabPanel, CustomButton/ToggleButton/PushButton. Screen readers are
> now able to identify and speak the content of these widgets.
> -various tabindex fixes to improve tab navigation through a page
> -addition of an API to set ARIA roles/states on Elements (experimental)
>
> I'm planning on drafting a document explaining GWT's support for
> accessibility, and what GWT developers should keep in mind when writing new
> widgets that are meant to be accessible. I'll post the link to contributors
> forum when the document is complete.
>
> Let me know if you need any more information.
>
>
>
> Thanks,
> Rajeev
>
>
> On Tue, Mar 25, 2008 at 3:58 PM, HommeDeJava <[EMAIL PROTECTED]>
> wrote:
>
>>
>> Greetings,
>>
>> Can somebody in the GWT team give more details on what has been
>> implemented in the new GWT 1.5 to give accessibility  support out of
>> the box.
>>
>> For example, ARIA (Accessible Rich Internet Applications) support,
>> enhanced keyboard navigation, screen readers, high-contrast mode, etc.
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---