1. No, these dependencies were not updated as part of the 2.9.0 release
2. An update would come either in a 2.9.x bugfix release, or in 2.10 - the
3.x release is going to be structured in a different enough of a way that
none of these will be present.
3. At a quick glance, it appears to be an
I'm not sure I've seen this done before, but in theory what you are
attempting should be supported? The CodeSplitter runs on each individual
permutation, taking both java/js programs as input, and appears to have
checks to confirm that only reachable code for that permutation ends up in
the
I may be putting words in Frank's mouth, but I believe the proposal to "merge"
these is only to bring them into a single git repository, rather than one
repository per module - so option #4 is specifically what he is proposing (with
lots of room for optional other changes like 1, 2). We still
One potential option could be moving the tests into gwt-safecss, and only
release them together - the release process through sonatype will permit
you to push more than one set of artifacts, test them in the staging repo,
and then release to central together. That would imply using either local
and the bandwidth to resolve this problem fully, we probably can get most of
the way there, provided they can accept the caveats and test heavily.
--
Colin Alworth
co...@colinalworth.com
On Wed, Jun 24, 2020, at 5:09 PM, Gordan Krešić wrote:
> I'm willing to provide more info, but TBH I'm not s
Can you clarify the browser event that you are working with? If it is
something through JsInterop, then this is expected, since JSNI style calls
into Java from JS require $entry, but jsinterop provides no such mechanism.
If it is an event from a GWT Widget, then that would go through JSNI, and
Can you share the jenkins configurations as they exist today to ease the
migration process? They don't seem to be checked in to the build glue or any
other repository I noticed on the gwt.googlesource.com repo.
--
Colin Alworth
co...@colinalworth.com
On Wed, Jun 17, 2020, at 10:29 AM
The call two weeks ago
(https://groups.google.com/d/topic/google-web-toolkit-contributors/Tqgfb3QgGS0/discussion)
was fairly successful, so we're doing it again. Structure is again quite
light, there will be a few items to get discussion going, and we'll let it
take its own life from there.
None of those classes are included in the default JRE emulation provided in
either GWT 2.8.2 or 2.9.0 - if this previously worked, you might have had
something on your classpath which provided those sources as supersource, or
.gwt.xml files in those packages to indicate that they could be
I am not a lawyer, so I tend toward a very conservative interpretation of
anything we come up with, and none of this is actual legal advice, just my
understanding.
GWT is licensed/distributed under the Apache Public License 2.0, so any
code contributed must be compatible with that license to
My repo of tests, with some notes on problems it has encountered while testing
https://github.com/Vertispan/gwt-groupid-relocation-test
--
Colin Alworth
co...@colinalworth.com
On Sun, Jun 14, 2020, at 3:21 PM, Colin Alworth wrote:
> Agreed, I was testing to confirm this. It appe
Agreed, I was testing to confirm this. It appears to not make a difference in
the samples I have so far if that BOM includes the relocation though, but there
are a lot of permutations to go through, I'm mostly automating the "easier"
ones at this time.
--
Colin Alworth
co...@colina
e to o.g, which will say please
include o.g", as that will skip the c.g.g version bump.
Will push shortly, compare notes.
--
Colin Alworth
co...@colinalworth.com
On Sun, Jun 14, 2020, at 3:04 PM, Thomas Broyer wrote:
> Fwiw, I started setting up some tests here:
> https://github.com/tb
as a jar. The manual work is done, and it was fairly minimal (after
i figured out the minimal set, and that latest ant doesnt work), just want to
get thoughts on packaging/licensing, if there are any considerations.
--
Colin Alworth
co...@colinalworth.com
On Fri, Jun 12, 2020, at 5:19 PM
n if we tweaked it a bit". For the zip distribution I imagine we'd shade it
in to the overall zip, but for the m2 release it would probably be an external
jar (since it will hopefully never change).
--
Colin Alworth
co...@colinalworth.com
On Fri, Jun 12, 2020, at 1:36 PM, Thomas Broyer
Yep, sounds like the test stuff I had in mind - for a quick demo I'll set up a
repo, put some "libraries" and "gwt" jars/boms into it, and then make a bunch
of sample projects. The "gwt jars" will have some service loader wiring, and
the sample projects will check to see which jars they end up
years), but
require that projects go out of their way to enable that support.
--
Colin Alworth
co...@colinalworth.com
On Fri, Jun 12, 2020, at 9:49 AM, stockiNail wrote:
> Some frameworks can support IE8 polyfilling the application. In my opinion
> the IE 8 support could be dropped.
>
We have two issues tracking the dependency that GWT has on Ant,
https://github.com/gwtproject/gwt/issues/9690 and
https://github.com/gwtproject/gwt/issues/9677. I've taken a little time and
produced a minimal set of classes copied from ant which appear to provide a
working ZipScanner. For the
In GWT 2.7.0 (specifically in the first release candidate), SDM was made
the default, and IFrameLinker, XSLinker were deprecated since they didn't
work properly with SDM. You can reenable them in your own project though.
However, the replacement linker is mentioned in the release notes as
day, June 10, 2020 at 3:40:58 AM UTC-5, Thomas Broyer wrote:
>
>
> On Wednesday, June 10, 2020 at 12:09:29 AM UTC+2, Colin Alworth wrote:
>>
>> We're in the last phases of refactoring out the various GWT modules from
>> the gwt-user.jar each into their own github.com/
Since the existing code is very similar to J2CL's code, it seems like a
reasonable change, provided it is indeed safe to drop support for IE8. At a
glance, I'm having trouble finding a recent statement describing whether or
not IE8 (and 9, 10) ought to be supported - since GWT is often used for
There are multiple problems with using GXT 2.x with a recent version of GWT
(anything since GWT 2.6 or so, released in 2014). Sencha hasn't offered
support for GXT 2 since version 4 was released (and doesn't appear to
provide support for GXT 4 any longer either), but the last time I ran into
We're in the last phases of refactoring out the various GWT modules from
the gwt-user.jar each into their own github.com/gwtproject/ repositories
and jars, so they can be released separately and managed directly on github
rather than only through gerrit. These will be new jars, each with a
Every few weeks, a group of us that chat regularly on gitter try to meet up
and chat about what we're working on in the GWT/J2CL ecosystem. We're
casting the net a bit wider this time, posting the invite here (albeit with
short notice). If those goes well, we might formalize further.
This is
Whoops, sorry, I see it in the other thread
"https://groups.google.com/d/topic/google-web-toolkit/aCWkpXWVsD4/discussion;.
On Friday, May 29, 2020 at 9:43:36 AM UTC-5, Colin Alworth wrote:
>
> We did see type inference issues in earlier builds of the JDT version that
> GWT u
We did see type inference issues in earlier builds of the JDT version that
GWT uses, but after an update was done we thought that the issues were
resolved.
Can you give an example so we can check to see if JDT has handled this in a
later update that we can migrate to?
On Friday, May 29, 2020
s.
-Colin
On Thursday, May 28, 2020 at 1:03:48 PM UTC-5, David Nouls wrote:
>
> Strange, just retried today and now the compile worked properly.
>
> Thanks for the support!
> On 19 May 2020, 16:41 +0200, Colin Alworth , wrote:
>
> Nothing should have changed here as far as I am
- As for GWT 2.9.0, we don't see any deprecation warnings during
>>>compilation for JSNI, but you're saying JSNI is actually deprecated as
>>> of
>>>the 2.9.0 release, or is that a forward-looking statement targeting
>>>potential future 2.9.x
Nothing should have changed here as far as I am aware - GWT itself
continues to have emulation for Annotation, Enum, etc (Predicate doesnt
seem to be listed in your error)
https://gwt.googlesource.com/gwt/+/master/user/super/com/google/gwt/emul/java/lang/annotation/Annotation.java
Today we are pleased to announce the next release of GWT, version 2.9.0.
Some highlights of this release:
* GWT supports Java 9, 10, 11 language features.
* The elemental2 1.0.0 release is supported, along with
jsinterop-annotations 2.0.0 (except @JsAsync, which requires dropping
support for
Another option could be to tell GWT that this is just the idea of what the
Car type will be, but that there isn't actually a real type called Car that
it will be able to find. For example, you could perhaps make this an
interface instead of a class (js has no actual interface types, just "it
Excellent - reach out in https://gitter.im/gwtproject/gwt,
https://gitter.im/gwtproject/gwt-modules, or https://gitter.im/vertispan/j2cl
for any discussion around this, and people who are eager to help test.
--
Colin Alworth
co...@colinalworth.com
On Sun, May 3, 2020, at 11:40 AM, Manfred
, but we can discuss
cutting yet another release if someone feels strongly about this. My current
position is that if all tests pass, we can release as-is, does that seem
reasonable?
-Colin
--
Colin Alworth
co...@colinalworth.com
On Sun, May 3, 2020, at 10:23 AM, Thomas Broyer wrote
The build is failing again, two days in a row, and since this is shortly
after the jsinterop-annotation change, there is concern that this failure
is a result of that change. Can a googler look into this, or grant us the
ability to do so?
Thanks,
Colin
On Monday, July 22, 2019 at 12:48:34 PM
Jim, from this result, your classpath isn't correctly configured - the file is
there in the jar, as expected, but GWT isn't seeing it, so doesn't know to
include these sources.
I'll reach out off-list once we have a new zip and are ready to start testing
again.
--
Colin Alworth
co
was saying was not to
exclude you, but to indicate that the zip wasn't available yet because it
wasn't ready to be generally available at this time.
--
Colin Alworth
co...@colinalworth.com
On Tue, Apr 28, 2020, at 9:41 PM, Colin Alworth wrote:
> Jim, the download zip is available for peo
-annotations-1.1.0-RC1-sources.jar
Archive: jsinterop-annotations-1.1.0-RC1-sources.jar
inflating: jsinterop/annotations/Annotations.gwt.xml
...
--
Colin Alworth
co...@colinalworth.com
On Tue, Apr 28, 2020, at 1:02 PM, 'Jim Douglas' via GWT Contributors wrote:
> I've got the same build er
Update on the broken samples in the gwt distribution:
The issue is some kind of interaction between Java 8 and ant - when a URL
is read from the classloader for a directory within a jar, it had a
trailing slash. When running the GWT webappcreator from command line, this
didn't happen, when
We're having an issue related to the java7->java8 update, the build isn't
properly including the full sources for the included sample projects. By
itself, not a big deal, but it could imply that other assumptions of the
ant build are broken too. I'm looking into it, we'll have an updated
Yeah I’ll send it out once we’ve got some volunteers, and figured out who is
able to test what configurations.
--
Colin Alworth
co...@colinalworth.com
On Mon, Apr 13, 2020, at 10:00 PM, Juan Pablo Gardella wrote:
> Hi Colin,
>
> Could you please share the spreadsheet again?
Hi all,
We have a build ready to test for GWT 2.9.0, and are looking for volunteers
to verify that things are behaving properly on a variety of platforms. If
you have an hour or two free and can help us out, we would appreciate it.
We're hoping for a cross-section of testing that verifies
*
tps://gitter.im/vertispan/j2cl, or a few
other rooms, or on stackoverflow.
--
Colin Alworth
co...@colinalworth.com
On Sat, Apr 4, 2020, at 12:33 PM, Käpt'n Körk wrote:
> Hey there, as a GWT addict I am wondering, if GWT is finally dead? Any search
> for GWT 3.0 or similar results in a
Some quick observations from the docx:
The bulk of your split points are sized pretty well, but if you can save
the compiler work on those tiny ones and delete/merge them, that would be
ideal, and may well help your leftovers.
That leftovers is quite large, but not totally out of control at
Are you able to answer the other questions too? This looks like the same
numbers that was in your last email. "Lines of code" refers to the sources
that the developers write, not the generated JS. My reply also asked for
more detail on the deferredjs contents, just the last file numerically in
Also telling your JS debugger to pause on uncaught exceptions will help -
it will stop when that null.toString() takes place, letting you examine
which method you are in when it happens, and which local variable or field
is null.
On Wednesday, March 13, 2019 at 3:33:48 PM UTC-5, Jens wrote:
>
How much Java code goes into this? Combined file, line counts between
shared and client packages?
>From your .gwt.rpc files, My guess is that you have a huge amount of
duplication between RPC interfaces. Improper use of supertypes, generics,
interfaces, etc can cause the compiler to believe
Alexander has patches up for Java 11 language support - if we ship now, we
won't be compatible with Java 11 (unless you just mean running the compiler
on a Java 11 JDK, but as I understand it, we're already good there with
2.8.2?).
I have patches up for Java 9, 10 JRE support, which also need
Hey all, anyone want to review some code?
Right around the new year, I finished up a first cut of all of the features
mentioned so far on https://github.com/gwtproject/gwt/issues/9547,
including tests. The first patch is at
https://gwt-review.googlesource.com/c/gwt/+/21501, with a tentative -1
I believe that the reason this class existed to begin with was to allow
(for some reason..) RPC to serialize that exception and pass it to client
code. But emulation that "needs" it to match the correct signature can
safely remove it from a "throws" clause without breaking the contract,
Thanks for the heads up - it was removed since it isn't possible to throw
in client code anyway, and projects could emulate it themselves if
necessary. I'm curious about why gwt-bean-validators must have it, as the
original validator code did not have it - is it expecting it to be possible
to
checking internally but didn't find anything right
away, I owe him a more in-depth writeup of what we think will point at
the tool which had been used in the past.
--
Colin Alworth
co...@colinalworth.com
On Mon, Dec 17, 2018, at 4:22 PM, Manuel Carrasco Moñino wrote:
> Sorry for the late re
I'm not sure we can find much more public
commentary.
--
Colin Alworth
co...@colinalworth.com
On Fri, Dec 7, 2018, at 8:32 AM, Thomas Broyer wrote:
>
>
> On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh wrote:>>
> Anyone know what is generating TimeZon
Yes - it doesn't need Widgets at all, just any bean-like data and views
which implement the various Editor interfaces. There's no reason that
this wouldn't work outside of GWT entirely - JVM, Android, TeaVM all can
run plain Java sources like this generates.
--
Colin Alworth
co
At the risk of sounding like I'm telling off the people who agree with me
that GWT-RPC has value, the purpose of this thread isn't to establish that
RPC will live on in some form, but to discuss how it will be maintained. It
_will_ still exist in some form, either as part of the "official GWT
As has been discussed previously in various venues, I have a mostly-working
port of GWT-RPC that drops the use of legacy GWT APIs like Generators and
JSNI, future-proofing both beyond GWT 2.x, and making it functional in
other runtimes (JVM, Android, TeaVM, etc). It isn't perfect, and isn't
t; correct version.
> Whatever the reason for that error was. I hope it is not reproducable and
> we can ignore that.
> So my assumption was wrong and then GWT release is fine.
>
> Am Mittwoch, 29. August 2018 23:39:07 UTC+2 schrieb Colin Alworth:
>>
>> For what its wor
With that update, you might need to look more at your test or project setup
- can you share the full log from a mvn test (or whatever you do to run the
gwt test cases)?
Any chance of another corrupt local jar?
On Wednesday, August 29, 2018 at 4:38:02 PM UTC-5, Jörg Hohwiller wrote:
>
> Indeed.
For what its worth, I'm not seeing any such issues in opening classes
within the 2.19 jar (source or binary) - any chance you've just got a
corrupt local copy, or that your org has a maven repo with a corrupt copy?
On Wednesday, August 29, 2018 at 4:24:59 PM UTC-5, Jörg Hohwiller wrote:
>
> Hi
GWT 2.9 is already started, you can check it out at current master - you
can see the commits and even build it yourself at
https://gwt.googlesource.com/gwt/+/master/, or get a nightly build from
https://oss.sonatype.org/content/repositories/google/ (i.e. the latest
build at
The beginning of the payload all looks correct, and it won't be possible
for us to fully decode it and see what is wrong without the sources of the
various objects mentioned.
But the format *appears* to be trying to send something impossible:
7 - "current version of the stream format"
0 - "no
e on GWT 2.6.0 (not on GWT 1.5) and currently trying to
>>> upgrade to GWT 2.8.2.
>>>
>>> On Wednesday, June 13, 2018 at 3:05:47 AM UTC+5:30, Colin Alworth wrote:
>>>>
>>>> This happens when the server thinks it can serialize and send an
>>
)
>>> at throwClassCastExceptionUnlessNull
>>> (com.ptc.windchill.wncgwt.WncGWTdebug-0.js:458)
>>> at Array.init_9 (com.ptc.windchill.wncgwt.WncGWTdebug-0.js:74335)
>>> at initializeModules (com.ptc.windchill.wncgwt.WncGWTdebug-0.js:46)
>>> at apply_0 (com.ptc
The errors you are getting aren't related to your Locale supersource (or at
least not directly), but to the fact that your project has conflicting JRE
sources which don't make sense, and so cannot be compiled. Your version of
"gwtx" cannot be used with any version of GWT released within the
The error that looks like it might be the source of the problems is this
one:
[java] [ERROR] Errors in
'jar:file:/opt/wnc/3rdPartyJars/lib/gwt-user.jar!/com/google/gwt/emul/java/io/FilterOutputStream.java'
[java] [ERROR] Line 74: The constructor
IOException(Throwable)
Legacy dev mode was not removed when super dev mode was introduced, so any
use of asm in legacy dev mode would not have changed.
That said, the package you are describing still exists in 2.8.2 and even in
master:
Your Java code isn't async, but your JSNI method and JS function are - the
imageCapture() method is passing an async function to
`navigator.camera.getPicture`, and expected it to return right away.
Instead, your `imageCapture` method should take a java-annotated
@JsFunction and pass that in
r feet wet in a "hard" one might be rather
intimidating).
There is also lots of discussion at https://gitter.im/gwtproject/gwt if
you have questions, you may get answers or advice there.
--
Colin Alworth
co...@colinalworth.com
On Thu, Apr 12, 2018, at 11:47 AM, Grzegorz Nowak wrote:
>
"gwt.org" is not available - it refers to a hiking trail.
My suggestion is org.gwtproject.$module:gwt-$module.
Cons:
- Redundant appearance of $module, and of "gwt"
Pros:
- Multi-module maven projects all have the same groupid, instead of
requiring that the gwt-event project all be under
With no replies in two weeks, I'd say you should proceed with a change
request to the tools repo to add the new jar, and the changes required to
the gwt project itself to support the new version.
On Friday, February 16, 2018 at 1:34:16 PM UTC-6, Colin Alworth wrote:
>
> From our disc
Perhaps you can share your full pom, or other dependencies? It might be
that you have some conflicting dependency which is preventing GWT from
having the colt version it needs.
That said, how are you running SDM? From your log, that doesn't look like
you are running it from the maven plugin
6, Goktug Gokdogan wrote:
>
> I haven't thought about separating it from J2CL, not sure if it is a good
> idea.
> Why do you need it for GWT2? For code sharing, we simply use Junit3 style
> and we didn't feel much pain about it.
>
>
> On Thu, Feb 15, 2018 at 12:15 PM Colin Alwo
>From our discussion in Gitter, it sounds like many/most of the changes in
GoogleMods are no longer needed to get tests to pass - either the existing
tests are insufficient to make sure that these changes are still there, or
the important changes have been folded in upstream.
I do recall that
Anything we can do to facilitate this? Also, if it is released under j2cl,
is there an expectation that it could be factored out and made to work with
GWT2, and released generally instead of just under J2CL (in its binaries
and its deadlines)?
On Friday, January 26, 2018 at 9:17:39 PM UTC-6,
As we look at how to keep migrating GWT provided user modules to modern
best practices, the JUnit runner is a hairy one - it relies on a lot of the
practices we discourage, including a great many modules in GWT that we
might prefer it not use. It also assumes
As has been discussed on other
le code? If
you make a very simple application that only tries to serialize one of
these Collection/Connection objects, do you get the same error, or does
it only happen in your main project?
Feel free to contact me off-list if you want to try sharing some source
privately.
--
Colin Alworth
co
Hello contributors,
We've decided to change how we manage official gwt modules a bit, to allow
modernization and faster updates to gwt-user while still supporting
developers who need backward compatibility. We're now allowing creation of
repositories at github.com/gwtproject by contributors who
arts looks like it could
potentially be used as a primitive in building this functionality (if we
wanted to forgo any JVM support) perhaps. That said, formatToParts is
still not well supported yet (no Edge, no IE11, no FF ESR).
--
Colin Alworth
co...@colinalworth.com
On Sun, Jan 7, 2018,
I would be interested in hearing about concrete cases where one jar adds
.properties files for a class declared in a completely different jar - I
haven't seen that done in the wild before, it sounds like a bit of a
stretch to me. It might also be something that we could formally discourage
in
As far as I can tell, Tree/TreeItem work just fine in standards mode - what
makes you think that they don't?
http://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwTree shows
it being used in standards mode.
In contrast, consider com.google.gwt.user.client.ui.TabPanel, which has
Yes, that should work - a "java array" of js objects can be a js array. You
could also use elemental2.core.JsArray instead if you wanted to be
explicit in your Java code that you are dealing with a Java array.
On Tuesday, January 2, 2018 at 3:28:34 PM UTC-6, Power Droid wrote:
>
> I have a
r the reply.
>
> On Tuesday, January 2, 2018 at 11:43:04 AM UTC-6, Colin Alworth wrote:
>>
>> You are using latest GWT, but ancient Guava. Upgrade your Guava version
>> to something more recent, and this will go away.
>>
>> On Tuesday, January 2, 2018 at 11:22:25 AM
Beware using JsArray, instead use JsArray, see
https://github.com/google/elemental2/issues/28.
A third option, with elemental2-core, rather than explicitly copying the
array, ask the browser to do it for you with slice(). First cast the array
to JsArray, then slice it to get a copy of its
You are using latest GWT, but ancient Guava. Upgrade your Guava version to
something more recent, and this will go away.
On Tuesday, January 2, 2018 at 11:22:25 AM UTC-6, BM wrote:
>
> We recently upgraded our project from GWT 2.6.1 to GWT 2.8.2.
>
> We running java version: 1.8.0_144
>
How much memory does your app need to do a full compile on your machine
(for just one permutation)?
Super dev mode works very differently than legacy dev mode - I almost
prefer to call it "super draft mode" but it has more improvements than
simply running a draft compile. Legacy dev mode
Thanks Thomas, I'm excited to see where this will lead.
Can you talk a little more about plans POJO support, as none of the three
existing options have any? Would you envision a wrapping tool that looks
like AutoBean/gwt-jackson, and where on that continuum are you thinking
(autobean is as
Can you share the string that the client sent to the server for this? It
looks as though either something has been done to modify the stream
(preemptively read from it once it hit the client? an extra token was
written to it? some other customization?) or perhaps a proxy server
replaced some
Tables should only be needed (even historically) to manage rounded corners
or some other "9-box" way to build corners and edges - if you just want a
flat popup with square, solid colored border, there shouldn't be a need for
tables. If you only need modern browser support, you shouldn't need
com.google.jsinterop:base:1.0.0-beta-3 was released to maven central on
nov 10:
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.google.jsinterop%22%20AND%20a%3A%22base%22
--
Colin Alworth
co...@colinalworth.com
On Sun, Dec 3, 2017, at 07:28 PM, Hristo Stoyanov wrote:
> Hm ... Jul
It looks like the poms weren't correctly updated - they still depend on
jsinterop-base 1.0.0-beta-1, tickling
https://github.com/google/elemental2/issues/20 again. The gwt2 compiler
fails on this with this sort of error:
[INFO][ERROR] Errors in
-6, Scott Palmer wrote:
>
>
>
> On Thursday, 19 October 2017 16:30:49 UTC-4, Colin Alworth wrote:
>>
>> Today we released the next version of GWT, version 2.8.2. A few quick
>> highlights from this new release:
>>
>>- GWT can now run on
On Friday, November 17, 2017 at 10:37:59 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>>
>> Sounds like there is enough diversity of opinion that this discussion
>> should go on - first step seems to b
Sounds like there is enough diversity of opinion that this discussion
should go on - first step seems to be deciding if we think the CLA and/or
gerrit-style review is important for all artifacts deployed to
org.gwtproject.
For the time being, it sounds like individual groupIds are the way
It turns out this is already supported in the editor framework, though
perhaps not in your editors themselves - the framework even supports a
collection being passed from the client code (perhaps from the server) to
the driver to indicate that there are problems, and which fields to
highlight.
Symbol maps are distinct from source maps, the serve different purposes.
Sourcemaps, when deployed with your actual source, allow the browser to ask
the server for your Java source, so you can see if when you debug - this
may not be something most production applications want their customers to
where code came from in an external project,
make sure everyone is on board with moving to gwtproject.
On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>>
>> Thanks guy
Thanks guys - I guess I'm confused as to why Daniel and Thomas have their
projects so far in their own repos, and not in github.com/gwtproject - I
was following that example. If you guys are ready to move them now and ship
them (0.9 or 1.0-beta-n, either works for me) to central, then I have no
I'm about to put out a blog post with a bunch of details on how one might
port gwt-user.jar modules out (thanks to the hard work of those who have
started this effort already, especially Dan Kurka and Thomas Broyer), and
once those are ready to be consumed, we'll certainly want the various
To answer the original question, no - no changes are planned in the Xsrf
variants of generator-based RPC. We should remove those comments. I am
aware of no reason to not use the Xsrf variants in production code.
Looking forward, beyond gwt-user.jar, I have the core of RPC working
correctly in
Today we released the next version of GWT, version 2.8.2. A few quick
highlights from this new release:
- GWT can now run on Java 9 (though Java 9 features are not yet
supported, coming soon!)
- Chrome 61 change in getAbsoluteTop/Left has been fixed
- Errors on the page reported
On Wed, Oct 11, 2017, at 02:01 PM, 'Goktug Gokdogan' via GWT Contributors
wrote:>
> PS: pls avoid the urge to discuss technical stuff in steering commitee
> and try to keep it in the contributor list ;)
If we could get the monthly (weekly?) contrib calls going again so we
have someone to
101 - 200 of 463 matches
Mail list logo
