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
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:
>
>&
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
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
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:
>
>>
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
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
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
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
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
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
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:
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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.
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
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
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
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
*
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
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
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
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
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
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
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
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
Patch is accepted and merged into upstream HtmlUnit, see
https://sourceforge.net/p/htmlunit/bugs/1924/ for more detail.
Daniel, when you can take a look at Thomas's question, we can get this
change made to open source GWT as you requested.
--
You received this message because you are subscribed
Like we do for
com.google.gwt.junit.RunStyleHtmlUnit.HostedJavaScriptEngine so we can
hook in the "plugin". Looks like that idea might be a winner! Just make
sure to swap it in both cases, don't want to kill tests in old dev mode.
--
You received this message because you are subscribed to the
Exactly - I wasn't planning on adding the javaToJs(), but was going to
unwrap the exception before calling onerror (or have ScriptException
implement Scriptable). Have a short test that demonstrates the issue
without gwt (but wow they have a lot of GWT in their source tree), and am
was waiting
It was not my intention to get this into 2.8.2, but to wait for 2.9. If
we think it is important enough, I can look into it, but I figure we
have to draw the line somewhere...
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe
Okay, I'm about 80% sure that I understand and can remedy the problem
within HtmlUnit itself. Will update once I finish syncing the apparently
canonical SVN repo to git, so I can go over the history more carefully and
ensure that this break isn't deliberate.
A question for my fellow GWT
Good news is that getting past the failed to start shell issue isn't that
bad, mostly transitive dependency changes (man there are times I love
maven, mostly when I'm not using it...), but also losing the ability to run
tests in IE8, IE11. Not sure that is a great loss.
Bad news is that it
1 - 100 of 247 matches
Mail list logo
