Re: GWT 2.8 next release

[Michael Zhou]

I think it's fine to wait for the in-review Java 8 API additions to land. 
You can use 2.8.0-beta1 for now.

On Friday, April 8, 2016 at 4:43:35 PM UTC-4, Ming-Yee Iu wrote:
>
> Is there an ETA on RC1? How long is it expected to take to take to emulate 
> all those Java 8 APIs? Couldn't API emulation be put off until a 2.8.1 or 
> something?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 next release

[Ming-Yee Iu]

Is there an ETA on RC1? How long is it expected to take to take to emulate 
all those Java 8 APIs? Couldn't API emulation be put off until a 2.8.1 or 
something?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 next release

[Jens]

> Is the CompletableFuture on the emulation implementation plan for 2.8 
> release? It's an amazing helper for chaining asynchronous operations.
>

I think the consensus between Colin, Andrei and me (we have done most of 
the Java8 API work so far) is that we want to emulate CompletableFuture 
(except the synchronous get() methods of course) based on JS Promises. 
However currently no one is really working on it so it might not be in 2.8 
release. Obviously you can always use a GWT library that supports promises 
for now.

Same is true for java.time. Actually some time ago someone else already did 
a java.time emulation based on threetenbp (which we would also use as 
foundation) but never contributed it to GWT itself. I don't know how well 
it works but you can find it at https://github.com/m-m-m/gwt-time if you 
want to try it.

-- J. 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT 2.8 next release

[Ed]

Thanks for sharing.  It will be worth the wait.

Ed

On Wed, Mar 30, 2016 at 6:09 PM, Thomas Broyer  wrote:

> We're a bit late wrt our plan for RC1, but we're currently adding
> emulation for many Java 8 APIs (new methods in collections,
> java.util.function, spliterators, and soon streams). Stay tuned.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT 2.8 next release

[Debasish Padhy]

When shall we expect a new release of 2.8 .. may be beta2 ? Its been more 
then 3 months since beta1 .

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Thomas Broyer]

On Wednesday, October 28, 2015 at 6:32:28 AM UTC+1, bendg25 wrote:
>
> If you abstract out the integration point to start up the embedded server, 
> then it would be easy to swap it out.


Why would you abstract it out? CodeServer is a tool that listens on a port 
and does HTTP, why would you abstract the way it does HTTP?
(the embedded server that host your webapp in DevMode is swappable though: 
http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/ext/ServletContainerLauncher.html
 
& 
http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#What_options_can_be_passed_to_development_mode;
 
I believe the main usecase was AppEngine support, and the AppEngine servlet 
container launcher uses an isolated ClassLoader IIRC)
I understand that you want to run everything in a single JVM (why? I can 
only see drawbacks, apart from "there's only one thing to launch and thus 
no need to remember the order you have to launch things") but that's just 
not a usecase GWT was designed to support. It could be made to work, and 
you're encouraged to come discuss this in the gwt-contrib forum 
 
and possibly send in patches, but it's low priority – plus, supporting 
other use cases also means making sure you don't break them moving forward, 
so it's not just a one-time effort, but a continuous one).
BTW, there's a pending change already to bump Jetty to 
9.x: https://gwt-review.googlesource.com/7857

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[bendg25]

Hi

My rationale for the request is we run up server, client and server, in a 
single jvm.  We have tried upgrading our runtime to say jetty 9 and come 
unstuck.  (I don't have the detail)

More recently I have been working on a spring boot gwt app.  I would like to 
run this in one Jvm using maven gwt plugin but could not get it working as it 
uses jetty 8.  I supplied a web.xml (that Spring boot does not need) to enable 
jetty to bootstrap but Spring security was not handling the requests for some 
reason.

I have ended up with running my spring boot container exposing debug port and 
running gwt maven plugin with super Dev mode and no server option.  This allows 
me to recompile using bookmark lets but the break points are not being hit so 
it is not ideal.

However back to my original request, I just don't understand, from a design 
perspective, why you would want to couple yourself so closely to a particular 
version of a web container.  It does cause issues.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Thomas Broyer]

On Tuesday, October 27, 2015 at 7:15:00 AM UTC+1, bendg25 wrote:
>
> However back to my original request, I just don't understand, from a 
> design perspective, why you would want to couple yourself so closely to a 
> particular version of a web container.
>

It's not a "container", it's an embedded server.
No one specifically *wants* to be coupled so closely to that particular 
version, it just happens that Jetty doesn't provide backwards compatibility 
(for semver lovers, note that they bumped the major version a couple times).
…and until quite recently, we couldn't update it because HtmlUnit (used in 
GWTTestCase) depends on Jetty too (I think I already said it before in this 
thread)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[bendg25]

If you abstract out the integration point to start up the embedded server, then 
it would be easy to swap it out.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Cristiano]

Hi Thomas, Hi all,

I've recently studied and "hacked" the code server and I have grown an 
opinion about this, let me share some thoughts.

I do prefer too that Jetty get stripped off from GWT, I find generically 
the same issue of Luis and Bendg; 
it is true there are many ways to work around these issues, but it can get 
very annoying in the end.

In my studies I have "hacked" the code server, and I've noted that the 
codeserver's com.google.gwt.dev.codeserver.WebServer is the class 
responsible of depending on Jetty.
It basically creates an anonymous Servlet and start it with an embedded 
Jetty, but it is all merged on a single class with many responsibilities 
and it is very hard to reuse.

Well, the good news is that even if Jetty has very bad records of backward 
compatibility, the servlet standard has a very good one, and I think that 
if we split the CodeServer's Servlet from the Embedded Jetty Server 
implementation, anyone can get happy.

This is not an hypothesis, I've actually made it working: I have created a 
pure servlet, extracted from WebServer, that provides the code server 
functionality.
I've been able to run this servlet on the Jetty version that I prefer 
(Jetty 9.2.11.v20150529), and moreover, I've used a single embedded Jetty 
server, written by myself that run both the GWT application and the Code 
Server's servlet. This CodeServer don't runs on port 9876, it runs instead 
on sub-path /dev-mode, same port.
With this configuration, I've achieved another goal (well, actually it was 
my primary one): I've been able to use the SSO linker with SuperDevMode 
(with limitations, I need to open manually the url http://localhost:**/
*dev-mode*
/recompile/my_module?_callback=__gwt_sdm_globals.callbacks.c1444718136184 

  
to trigger recompilation, and the SuperDevMode compiled Javascript is 
included with a script tag like http://localhost:8082/dev-mode/wunit_logic/wunit_logic.nocache.js>"> 
- anyway this can be improved and automated easily).

Another relevant consideration is that with these configuration, I've been 
able to develop and debug (server side for the moment) GWT *without the 
Eclipse Plugin*: 
I think next generation of GWT should follow such approach, that it is 
inspired on what the Wicket framework provides: if you try to create a 
Wicket archetype (use this command: mvn archetype:generate 
-DarchetypeGroupId=org.apache.wicket 
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.0.0 
-DgroupId=org.example.jetty.embedded.wicket.check 
-DartifactId=check-wicket-embedded-jetty 
-DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false), 
you'll see that it creates an embedded Jetty server in test sources, and it 
can be started in Eclipse as any regular Java application. If GWT would 
follow the same approach, it could create an embedded jetty server that 
also starts a CodeServer Servlet, or maybe a Servlet Filter that intercepts 
Javascript requests for GWT's *.nocache.js files and recompiles them on the 
fly.


I don't have "clean" code to share, but if there is interest I can share 
these modified classes or describe the modification I've ade (note though 
I'm not using this code in production, I've just hacked it while studying 
the feasibility of some other PoC using SSO linker).

If I reach some more concrete results, I'll show them to the GWTcon in 
Florence next 11 november, where I hope to meet and discuss about these 
topics with a wide community.

Hope this is interesting,
have a nice day,

Cristiano

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Thomas Broyer]

On Tuesday, October 20, 2015 at 8:50:39 AM UTC+2, Cristiano wrote:
>
> Hi Thomas, Hi all,
>
> I've recently studied and "hacked" the code server and I have grown an 
> opinion about this, let me share some thoughts.
>
> I do prefer too that Jetty get stripped off from GWT, I find generically 
> the same issue of Luis and Bendg; 
> it is true there are many ways to work around these issues, but it can get 
> very annoying in the end.
>
> In my studies I have "hacked" the code server, and I've noted that the 
> codeserver's com.google.gwt.dev.codeserver.WebServer is the class 
> responsible of depending on Jetty.
> It basically creates an anonymous Servlet and start it with an embedded 
> Jetty, but it is all merged on a single class with many responsibilities 
> and it is very hard to reuse.
>
> Well, the good news is that even if Jetty has very bad records of backward 
> compatibility, the servlet standard has a very good one, and I think that 
> if we split the CodeServer's Servlet from the Embedded Jetty Server 
> implementation, anyone can get happy.
>
> This is not an hypothesis, I've actually made it working: I have created a 
> pure servlet, extracted from WebServer, that provides the code server 
> functionality.
> I've been able to run this servlet on the Jetty version that I prefer 
> (Jetty 9.2.11.v20150529), and moreover, I've used a single embedded Jetty 
> server, written by myself that run both the GWT application and the Code 
> Server's servlet. This CodeServer don't runs on port 9876, it runs instead 
> on sub-path /dev-mode, same port.
> With this configuration, I've achieved another goal (well, actually it was 
> my primary one): I've been able to use the SSO linker with SuperDevMode 
> (with limitations, I need to open manually the url http://localhost:**
> /*dev-mode*
> /recompile/my_module?_callback=__gwt_sdm_globals.callbacks.c1444718136184 
> 
>   
> to trigger recompilation, and the SuperDevMode compiled Javascript is 
> included with a script tag like http://localhost:8082/dev-mode/wunit_logic/wunit_logic.nocache.js>">
>  
> - anyway this can be improved and automated easily).
>
> Another relevant consideration is that with these configuration, I've been 
> able to develop and debug (server side for the moment) GWT *without the 
> Eclipse Plugin*: 
> I think next generation of GWT should follow such approach, that it is 
> inspired on what the Wicket framework provides: if you try to create a 
> Wicket archetype (use this command: mvn archetype:generate 
> -DarchetypeGroupId=org.apache.wicket 
> -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.0.0 
> -DgroupId=org.example.jetty.embedded.wicket.check 
> -DartifactId=check-wicket-embedded-jetty -DarchetypeRepository=
> https://repository.apache.org/ -DinteractiveMode=false), you'll see that 
> it creates an embedded Jetty server in test sources, and it can be started 
> in Eclipse as any regular Java application. If GWT would follow the same 
> approach, it could create an embedded jetty server that also starts a 
> CodeServer Servlet, or maybe a Servlet Filter that intercepts Javascript 
> requests for GWT's *.nocache.js files and recompiles them on the fly.
>

Actually, Goktug (IIRC) once suggested (months ago) such an evolution of 
SDM, to work as a pure servlet within the webapp.
But now you just brought ECJ/JDT inside your webapp classloader, where it's 
likely to conflict with any ECJ/JDT version you could be using within your 
app (see https://github.com/gwtproject/gwt/issues/5289 
and https://github.com/gwtproject/gwt/issues/4479 for the reverse: people 
putting their server-side deps in GWT's classpath and seeing conflicts); 
and I'm not even talking about possible dependencies of your client 
libraries, particularly those used in generators or linkers (e.g. Arcbees 
like to use Velocity for code generation in their generators).
So to work cleanly, SDM would have to be a webapp with its own isolated 
classloader, rather than a servlet. And we'd have to find a way to pass 
"arguments" to the webapp (system properties? servlet context init 
parameters? maybe both?)

Note however that this is apparently not the way j2cl will work (a priori, 
from what we know), as it'll more likely run as/in a process watching for 
file changes and continuously re-transpiling changed files, similar to what 
you'd do with SASS, LESS, CoffeeScript, TypeScript, etc. (some of them can 
work directly in the browser too); and possibly would just integrate 
seamlessly with gulp/grunt/etc. to use their own "watch" feature.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: Next release

[Thomas Broyer]

On Thursday, October 15, 2015 at 9:25:40 PM UTC+2, bendg25 wrote:
>
> Can you ditch the embedded Jetty server please.
>

Hmm, no. But it'd be interesting to know the reason for that request.
For example, a classpath conflict is generally not a valid reason, because 
the part of GWT that includes Jetty is not concerned about the server side 
of the applications, and the part of your application that would need Jetty 
is likely its server side. So the answer in such case is to "just" use 
different classpaths/build paths for the client and server sides.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Luis Fernando Planella Gonzalez]

"classpath conflict is generally not a valid reason, because the part of 
GWT that includes Jetty is not concerned about the server side of the 
applications"
Unless you run [Super]DevMode, which runs both in a single JVM, then it is 
a pain.
There are other libs which are bundled in GWT jars, causing some 
inconveniences too, like 
IMHO, saying to run with -noserver is not a perfect solution either, 
because it complicates things, requiring 2 jvms, and don't playing well 
with RPC and security policies.
Having most of people (if not all) using either an IDE plugin or Maven, 
which can manage the classpath, I don't see a reason to bundle (very old) 
3rd party classes in the GTW jar.

Em sexta-feira, 16 de outubro de 2015 06:13:38 UTC-3, Thomas Broyer 
escreveu:
>
>
> On Thursday, October 15, 2015 at 9:25:40 PM UTC+2, bendg25 wrote:
>>
>> Can you ditch the embedded Jetty server please.
>>
>
> Hmm, no. But it'd be interesting to know the reason for that request.
> For example, a classpath conflict is generally not a valid reason, because 
> the part of GWT that includes Jetty is not concerned about the server side 
> of the applications, and the part of your application that would need Jetty 
> is likely its server side. So the answer in such case is to "just" use 
> different classpaths/build paths for the client and server sides.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Next release

[Thomas Broyer]

On Friday, October 16, 2015 at 3:25:04 PM UTC+2, Luis Fernando Planella 
Gonzalez wrote:
>
> "classpath conflict is generally not a valid reason, because the part of 
> GWT that includes Jetty is not concerned about the server side of the 
> applications"
> Unless you run [Super]DevMode, which runs both in a single JVM, then it is 
> a pain.
>

Well, if you decide to run your server-side code inside the server that 
ships with DevMode, then you have to deal with the version DevMode works 
with.
If it causes you trouble, it most likely means you're not building a 
"portable webapp" (that could run in any servlet container), and in that 
case you shouldn't use the embedded server.
 

> There are other libs which are bundled in GWT jars, causing some 
> inconveniences too, like 
>

There might be some "leaks" to the webapp (2.6.0 was known to be broken for 
instance), but as long as your server-side dependencies are not in the 
DevMode classpath (and only in your webapp's WEB-INF/ ) it should Just 
Work™ (for "portable webapps"), as they cannot conflict with GWT's own 
dependencies.
As I said: classpath conflicts are generally not a valid reason.

IMHO, saying to run with -noserver is not a perfect solution either, 
> because it complicates things, requiring 2 jvms, and don't playing well 
> with RPC and security policies.
>

AFAICT, RPC works well (at least in 2.7, but IIRC even before that); you 
just have to tell your RemoteServiceServlet to go load the serialization 
policies from the CodeServer using the gwt.codeserver.port system property: 
http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/server/rpc/RemoteServiceServlet.html#getCodeServerPolicyUrl(java.lang.String)

Can you give more details about "security policies" ?
 

> Having most of people (if not all) using either an IDE plugin or Maven, 
> which can manage the classpath, I don't see a reason to bundle (very old) 
> 3rd party classes in the GTW jar.
>

I don't necessarily disagree, but version mediation by tools like Maven is 
not a silver bullet.
Jetty, for instance, has a rather bad record wrt backwards compatibility. 
Currently, Jetty is used in GWT by the CodeServer to compile your code on 
the fly and serve it, by DevMode to host your webapp, by 
GWTTestCase/JUnitShell to serve the test's host page and script, and host 
servlets (both the ones used by the testing infra and user-provided ones), 
and by HTMLUnit, used by GWTTestCase/JUnitShell.
As you can see in https://gwt-review.googlesource.com/7857, upgrading Jetty 
is a breaking change, as is upgrading HTMLUnit. So not bundling them in the 
JAR wouldn't mean that you could use other versions, and using a tool like 
Maven could make you use other versions without you necessarily noticing.
Really, the solution is segregating client and server classpaths. GWT 3.0's 
new "j2cl" transpiler might change things a bit, but still in ways that are 
largely similar to what exists today (i.e. you won't put your code anymore 
in the classpath *at all*, instead you'll pass a classpath to the 
transpiler just like you give one to javac, and that one might container 
server-side code that –and that's the change– won't conflict with GWT's 
internal dependencies)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Next release

[bendg25]

Can you ditch the embedded Jetty server please.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT next release - what/when?

[denis56]

Are there a lot of chages one has to make to upgrate from 1.6 to 2.0.
I am considering if upgrading from 1.5 to 2.0 / writing straight in
2.0 would be a better option? Could you also please tell what are the
approximate timeline of 2.0 release, have not found dates in
documentation.
thanks

On Jul 14, 7:26 am, Alex Rudnick a...@google.com wrote:
 Many internal projects actually use the trunk. It's pretty stable, and
 it's got the aforementioned new features. (of course, the APIs may
 change a bit between now and 2.0)

 On Mon, Jul 13, 2009 at 8:29 PM, Joe Coleprofilercorporat...@gmail.com 
 wrote:

  Alex,

  Is there a specific tag that google are using internally for products
  like wave or are you using 1.6?

  Joe

 --
 Alex Rudnick
 swe, gwt, atl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Yegor]

FYI, GWT 1.7 downloads are already available. This is a minor release,
with added support for new browsers (IE8, FF3.5, Safari 4).

On Jul 12, 8:56 am, Ainata-Leb kassem.alsayed@gmail.com wrote:
 What will the next GWT release focus on and what is the expected date
 for that?
 Is there a centralized location/website that keeps tracks of GWT 3rd
 party libs?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Gert Scholten]

Interresting... I wonder why there wasn't an official announcement of
the release in the blog... or did it get released just a few min ago?

On Jul 14, 5:25 pm, Yegor yegor.jba...@gmail.com wrote:
 FYI, GWT 1.7 downloads are already available. This is a minor release,
 with added support for new browsers (IE8, FF3.5, Safari 4).

 On Jul 12, 8:56 am, Ainata-Leb kassem.alsayed@gmail.com wrote:

  What will the next GWT release focus on and what is the expected date
  for that?
  Is there a centralized location/website that keeps tracks of GWT 3rd
  party libs?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Isaac Truett]

It was announced on the GWT contributor list around 9:00 PM EDT last
night. A general announcement should be forthcoming in the next day or
two.


On Tue, Jul 14, 2009 at 2:10 PM, Gert Scholtengsch...@gmail.com wrote:

 Interresting... I wonder why there wasn't an official announcement of
 the release in the blog... or did it get released just a few min ago?

 On Jul 14, 5:25 pm, Yegor yegor.jba...@gmail.com wrote:
 FYI, GWT 1.7 downloads are already available. This is a minor release,
 with added support for new browsers (IE8, FF3.5, Safari 4).

 On Jul 12, 8:56 am, Ainata-Leb kassem.alsayed@gmail.com wrote:

  What will the next GWT release focus on and what is the expected date
  for that?
  Is there a centralized location/website that keeps tracks of GWT 3rd
  party libs?


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Alex Rudnick]

Hey Ainata,

We've got a pretty good GWT roadmap over here:
http://code.google.com/webtoolkit/makinggwtbetter.html#roadmap

(although we should update that page, because we've already released GWT 1.6!)

And somebody can correct me if I'm wrong, but I think all of those
features listed under Post 1.6 are going to be in the 2.0 version.
Aside from UiBinder, they're already in the trunk. GWT 2.0 is coming
pretty soon, but it's not hard to build the trunk from source, so you
can try the new features today!

We don't have an official list of libraries, but you can find quite
a few GWT-related projects by searching Google Code like this:
http://code.google.com/hosting/search?q=label:GWT

On Sun, Jul 12, 2009 at 10:56 AM,
Ainata-Lebkassem.alsayed@gmail.com wrote:

 What will the next GWT release focus on and what is the expected date
 for that?
 Is there a centralized location/website that keeps tracks of GWT 3rd
 party libs?

Hope this helps!

-- 
Alex Rudnick
swe, gwt, atl

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Joe Cole]

Alex,

Is there a specific tag that google are using internally for products
like wave or are you using 1.6?

Joe

On Jul 14, 3:10 am, Alex Rudnick a...@google.com wrote:
 Hey Ainata,

 We've got a pretty good GWT roadmap over 
 here:http://code.google.com/webtoolkit/makinggwtbetter.html#roadmap

 (although we should update that page, because we've already released GWT 1.6!)

 And somebody can correct me if I'm wrong, but I think all of those
 features listed under Post 1.6 are going to be in the 2.0 version.
 Aside from UiBinder, they're already in the trunk. GWT 2.0 is coming
 pretty soon, but it's not hard to build the trunk from source, so you
 can try the new features today!

 We don't have an official list of libraries, but you can find quite
 a few GWT-related projects by searching Google Code like 
 this:http://code.google.com/hosting/search?q=label:GWT

 On Sun, Jul 12, 2009 at 10:56 AM,

 Ainata-Lebkassem.alsayed@gmail.com wrote:

  What will the next GWT release focus on and what is the expected date
  for that?
  Is there a centralized location/website that keeps tracks of GWT 3rd
  party libs?

 Hope this helps!

 --
 Alex Rudnick
 swe, gwt, atl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: GWT next release - what/when?

[Alex Rudnick]

Many internal projects actually use the trunk. It's pretty stable, and
it's got the aforementioned new features. (of course, the APIs may
change a bit between now and 2.0)

On Mon, Jul 13, 2009 at 8:29 PM, Joe Coleprofilercorporat...@gmail.com wrote:

 Alex,

 Is there a specific tag that google are using internally for products
 like wave or are you using 1.6?

 Joe

-- 
Alex Rudnick
swe, gwt, atl

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Next Release

[Vitali Lovich]

From what I've read the GWT guys say, internally, Google uses trunk, so it's
stable (I also used trunk and it was stable for me too).

On Mon, May 11, 2009 at 2:44 AM, Noel noel.tr...@gmail.com wrote:


 No, that will be my option of last resort I suppose.  Mostly I don't
 have any idea how stable the GWT trunk code is, having not been a
 contributor or followed the development closely.  If I could get an
 idea of when the next release will be, I could then decide if I want
 to put in the effort to mess around with trunk or if it is an
 acceptable time frame for our team to just wait for the next release.

 On May 11, 12:58 am, Vitali Lovich vlov...@gmail.com wrote:
  Is there any particular reason you can't build from trunk?  It's pretty
  stable.
 
  On Sun, May 10, 2009 at 7:26 AM, Noel noel.tr...@gmail.com wrote:
 
   Does anyone know when the code currently in the GWT trunk will make it
   into a production ready release?  We are currently on 1.6.4 but there
   is a particular feature implemented in the trunk code that I really
   need - RemoteServiceProxy.setRpcRequestBuilder(RpcRequestBuilder).
 
   Thank-you,
 
   Noel
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Next Release

[Noel]

Does anyone know when the code currently in the GWT trunk will make it
into a production ready release?  We are currently on 1.6.4 but there
is a particular feature implemented in the trunk code that I really
need - RemoteServiceProxy.setRpcRequestBuilder(RpcRequestBuilder).

Thank-you,

Noel

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Next Release

[Vitali Lovich]

Is there any particular reason you can't build from trunk?  It's pretty
stable.

On Sun, May 10, 2009 at 7:26 AM, Noel noel.tr...@gmail.com wrote:


 Does anyone know when the code currently in the GWT trunk will make it
 into a production ready release?  We are currently on 1.6.4 but there
 is a particular feature implemented in the trunk code that I really
 need - RemoteServiceProxy.setRpcRequestBuilder(RpcRequestBuilder).

 Thank-you,

 Noel

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---