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
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
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
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
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
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
*
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?
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
-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
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
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
, 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
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
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
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
GWT itself hasn't changed substantially in many years - improvements have
mostly been language features, adding support for incremental compilation,
the jsinterop system, etc, so for the most part the optimizations haven't
changed.
That said, the best way is almost certainly to take a look at
We have a shorter itinerary this week - I'll record a short piece on
j2cl-maven-plugin and how to start a project with it, try using pieces from
the ecosystem.
Dmitrii, Ahmad and I will continue our brainstorming about efficiently
producing both optimized output and minimizing the work the
impossible, just perhaps messy -
and unwinding the "java8" flag (which really seems to mean "newer than java7")
is less fun than I'd like.
--
Colin Alworth
co...@colinalworth.com
On Mon, Jun 29, 2020, at 9:21 PM, 'Goktug Gokdogan' via GWT Contributors wrote:
> wrt running tests:
&g
As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
longer possible to build GWT with Java7, and similarly the decision was
made to no longer officially support running on Java7
(jsinterop-annotations use of "TYPE_USE", newer jetty version too I
believe).
There is still
Meeting link is at https://meet.google.com/jbs-wier-ywp - we will start
recording in about an hour, and will only publish the three talks listed
below.
On Wednesday, July 1, 2020 at 12:58:15 PM UTC-5, Colin Alworth wrote:
>
> We're going to try recording tomorrow, just for the sp
d, landed.
* Update Javadoc to support >8 only, update build to skip any doc tasks when
on Java 8
On Wed, Jul 1, 2020, at 11:34 AM, Thomas Broyer wrote:
>
>
> On Wednesday, July 1, 2020 at 3:32:34 AM UTC+2, Colin Alworth wrote:
>> Thanks Goktug for clarifying - I am personall
We're going to try recording tomorrow, just for the specific 'sessions'
that are planned, so the video should be available afterward, I'll link in
a follow up post when they are ready.
Three planned topics to record:
* Ahmad Bawaneh presenting domino-history, a simple routing tool to
> In the long run, as JDK9+ tests grow, supersourcing might become
>>> unsustainable, but the impact on the CI server et al. is non-negligible. We
>>> could still possibly, at least temporarily, build only with JDK8, and only
>>> run the JDK9+ tests once in a whil
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.
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
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
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
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
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
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
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/
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
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.
>
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
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
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
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
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
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
9saW5AdmVydGlzcGFuLmNvbQ=colin%40vertispan.com
--
Colin Alworth
co...@colinalworth.com
On Tue, Jul 21, 2020, at 8:24 AM, Michael Conrad wrote:
> How did it go?
>
>
> On 7/15/20 5:02 PM, Colin Alworth wrote:
>> We have a shorter itinerary this week - I'll record a short
I'm looking for reviewers and help for the above issues so I can finalize
them and begin testing. There are a few dependency chains here - I have
IE8/9/10 removal just about complete, but before that can merge we need the
apichecker updated, and after that merges, we can remove the poorly
I've just filed https://github.com/gwtproject/gwt/issues/9739, where a
workaround exists in java.util.Date that nearly doubles the time it takes
to parse date strings and build date objects. This workaround exists for
IE8 and IE9, as all more recent browsers implement the same behavior as we
Note that it appears I'm mistaken, Runtime.java polyfilled Date.now()
(though code in JsDate and others still believed that this method might not
exist), so GWT 2.8.2 and 2.9.0 likely function properly in IE8.
On Thursday, September 30, 2021 at 11:49:56 AM UTC-5 Colin Alworth wrote:
> I
We've got a few changes that have been brewing or waiting to be made
available, and it sounds like it is about time to collectively push to make
these things happen. Given the nature of some of these, I am suggesting
that they not be folded into a bugfix release, but instead that the next
the same.
>>
>> -- J.
>>
>> ManfredTremmel schrieb am Montag, 4. Oktober 2021 um 11:07:11 UTC+2:
>>
>>> Am Donnerstag, 30. September 2021, 18:49:56 CEST schrieb Colin Alworth:
>>>
>>> > So, is there any objection at this time to dropping what r
We've successfully migrated the gwtproject.org website to a new domain name
server and new hosting, at Google's request. There are a few small
differences from the old hosting:
- HTTPS is now supported and enabled, though not yet mandatory, to allow
a period of migration, and making
See the question raised at
https://github.com/gwtproject/gwt-site/issues/328.
While gwtproject explicitly licenses all "software and sample code" as
under the Apache License 2.0, it appears that we don't have a license
specified for the contents of the gwtproject website
TL;DR: If you have the capability to do so, now would be an excellent time
to help us test GWT in anticipation of a release, especially around the
groupId change we're going to make.
--
We think that we're one merge away from being ready for a GWT 2.10 release,
so I'm starting the release
rit and did require a CLA?
>
> --J.
>
> Colin Alworth schrieb am Donnerstag, 21. April 2022 um 17:34:49 UTC+2:
>
>> See the question raised at
>> https://github.com/gwtproject/gwt-site/issues/328.
>>
>> While gwtproject explicitly licenses all "software a
ethod
> create(ObservableMutableDocument) in the type
> DefaultDocumentEventRouter is not applicable for the arguments
> (ObservableMutableDocument)
> [ERROR] Line 963: The method
> createGadgetStatesDoc(DocumentEventRouter,
> ObservablePrimitiveSupplement.Listener) in the
I've pushed a new build with version 2.10.0-new-groupid-3 that has several
@SuppressWarnings("deprecation")s added, and hopefully will solve the WARN
logging issue.
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this
Hello all,
All of the preliminary testing that I'm aware of for the upcoming release
is complete, leaving us with a decent level of confidence in the changes.
We have a document that outlines the release plan (with a link to the
standard release steps and the testing process) that has
The last step of the release process is under way, Google's 2.10.0 release
is underway, we're just waiting for the release to be performed and
synchronized to Maven Central. When that has finished we can formally
announce the release.
I've created an issue for next steps to finish our
2022 à 21:34:23 UTC+2, juan_pablo_gardella a écrit :
>>
>>> Tried with Maven 3.8.5 and still fails with same issue. Reported at
>>> https://github.com/tbroyer/gwt-maven-plugin/issues/152
>>>
>>> On Sun, Apr 24, 2022 at 3:59 PM Colin Alworth wrote:
>
If there’s one thing that GWT has tried to be consistent about, it is
retaining support for technologies past their “best by” dates. This is a
sore point from time to time, as it makes the tooling feel dated even right
after a release, but it has some specific advantages with regards to
l finally force people to move on faster. They tend to complain that
> we are using old technology (GWT) but at the same time they stick with Java
> 8.
> On 4 Aug 2022, 06:05 +0300, Colin Alworth , wrote:
>
>
>
> If there’s one thing that GWT has tried to be consistent about, it is
> r
I'd welcome a separate discussion about a backward compatibility contract,
but clearly we have to contrast the "technically Java 8 is supported" with
"realistically, any project that uses standard up-to-date tools can't use
Java 8 by the end of 2023". We support _end users_ to the extreme, as
The GWT Eclipse Plugin has become unmaintained, and over the last several
months several community members have stepped up to update it to run on
recent Eclipse versions, and support the new GWT groupId.
As part of that process, we've created a new marketplace entry, and while
it is still
That patch is delayed since it turns out there are some tests that rely on
specific behavior from the JVM - a few JPMS violations in legacy dev mode,
and apparently Annotation.toString() changed slightly breaking a few other
tests. I think it is just about ready, but each round of testing takes
ger with password
> sharing between trustworthy community members. I appreciate the commitment
> of Vertispan but there should be a backup plan in case something unexpected
> happens.
>
> -- J.
>
> Colin Alworth schrieb am Samstag, 28. Januar 2023 um 03:45:13 UTC+1:
>
>>
There have been a few suggestions of making a release in the near future,
and it seemed like it might be a good idea to summarize pending
development, ask for help to land these, and see if anything else needs to
be addressed before shipping.
- There is a pending branch (not yet a PR for
we now use are not compatible there.
On Thursday, November 23, 2023 at 7:36:55 AM UTC-6 Juan Pablo Gardella
wrote:
> Hello, is gwt-2.11 artifacts available somewhere for testing against the
> applications I am currently working on?
>
> On Tue, Nov 14, 2023, 11:37 PM Colin Alworth wrote:
>
>&
Thanks for reporting - perhaps better for the bug tracker, and indeed we do
this (or something like it) filed already, see
https://github.com/gwtproject/gwt/issues/9840.
Your email title says that this is a compile time infinite loop, but then
the body suggests that it was a runtime error. If
with Java 11 and Chrome/Edge/Firefox.
> Will the jars for testing be available in some Maven repo?
>
> Cheers,
> Zbynek
>
> On Wednesday, November 15, 2023 at 3:37:38 AM UTC+1 Colin Alworth wrote:
>
>> It has taken longer than we had hoped, but I think we're just about read
e help, I'm feeling to help.
> Specially the jakarta stuff is important for us.
> Do you find the time to have a look to the open PR?
>
> BR
> Rocco
>
> Colin Alworth schrieb am Mittwoch, 17. Mai 2023 um 16:44:58 UTC+2:
>
>> There have been a few suggestions of making a r
401 - 470 of 470 matches
Mail list logo
