Re: [gwt-contrib] GWT 2 Roadmap as it applies to future deprecations

with '--release 8' should be enough, at least to begin with. Using retrolambda or similar might be a possibility (either when producing/packaging gwt-servlet, or asking users to do it on their side when consuming gwt-servlet for a Java 8 environment). This should make it possible to: - update pr

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

hText explicitly uses the RichText widget. >> >> However, both maven and gradle projects do correctly include the >> warnings, if you happen to include those gwt modules in your project. That >> does make the iteration time a bit longer to test, but it appears we can

Re: [gwt-contrib] Preliminary testing for GWT 2.10 release

oups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/dad1685b-9ad0-4a1a-88f4-dd0332d7b91dn%40googlegroups.com?utm_medium=email_source=footer> > . > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- You received this message because you a

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

hat's unrelated to GWT (had you used Gradle for instance, it would have been different, because it would have picked the highest ASM version), and of course this is because you put your server-side dependencies in GWT's classpath (with a very convoluted setup; https://xkcd.com/1172/). -- Thomas

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Where you're starting your Spring Boot server separately from DevMode (so you have 2 processes, not just one, contrary to what you're saying above), whose embedded server only serves a (development-only) static HTML page. That's probably not how I would work with Spring Boot, but indeed that works

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

setup a lot (say goodbye to those 4 gwt-eclipse projects). You apparently already have clearly separate projects for client and server code, so running them separately doesn't seem completely crazy. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- You received this messa

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

inevitable. One day or another you'll probably have to change the way you run your project. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

ce0909-56fc-4804-a032-103184c05af1n%40googlegroups.com?utm_medium=email_source=footer> >>>>> . >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "GWT Contr

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

om >>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/4486df4d-553d-409f-b3a8-4b4887ff0b9fn%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >>> CAUTION -- EXTERNAL E-MAIL - Do not click links or open attachments >>&g

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Le sam. 17 avr. 2021 à 21:15, Jonathon Lamon a écrit : > I have just recently set this up.. with the current GWT plugin for Eclipse > because I actually needed to run some JaxB servlets. I ran into problems > with JaxB servlets not loading when running in embedded Jetty, but setting > up

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Le sam. 17 avr. 2021 à 20:45, eliasbala...@gmail.com a écrit : > During development, > with "SuperDevMode"+"Jetty" and "Google Plugin for Eclipse", > GWT client-side code compilation (including the nocache.js files) is done > at runtime by DevMode. > Same with CodeServer with -launcherDir, or

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

If it's not a problem for you to serve servlets separately, could you explain why you couldn't have this other server also serve the host page and nocache.js file? Is that due to, maybe, how your projects are structured? (Could you give more details then?) Trying to understand what's blocking

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Moreover, we have to be careful when we say "remove Jetty", because Jetty is used in CodeServer and JUnitShell. Really the question here is about removing the ability to serve webapps, with servlets, from DevMode. Le sam. 17 avr. 2021 à 19:34, eliasbala...@gmail.com a écrit : > This is a very

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

ClassLoader that loads from both the WEB-INF/classes+WEB-INF/lib and the classpath), and even conflicts between Jetty and the WEB-INF/lib, and of course issues with the version of ASM from GWT used by Jetty to scan the webapp classloader when it encounters module-info.class files. -- Thomas Broyer /tɔ.m

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

/groups.google.com/d/topic/google-web-toolkit-contributors/iU9hckIab2o/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > google-web-toolkit-contributors+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.co

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

app > server for pure gwt frontend development (for dev purposes). My > understanding is that it's a choice of bumping up Java version or losing > Jetty. > > On Tue., Apr. 13, 2021, 12:04 Thomas Broyer, wrote: > >> Which features are you talking about? Which would you lose by

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Le mar. 13 avr. 2021 à 20:42, eliasbala...@gmail.com a écrit : > Our developers are using "Google Plugin for Eclipse" from which they can > start DevMode for any of our GWT application with a single step. > > If we wanted to use a CodeServer we would have to perform more steps. e.g. > compile

Re: [gwt-contrib] Asking for decision on DevMode embedded Jetty support

Which features are you talking about? Which would you lose by switching to using a *real* Jetty server alongside GWT CodeServer? Le mar. 13 avr. 2021 à 20:01, Richi Plana a écrit : > As a user and non-contributor, I would vote for bumping up versions (Java > 7 to 8, Jetty to 9.4). The move to

[gwt-contrib] Goodbye IE 8–9 

Fwiw, a change in GWT emulation of longBitsToDouble and doubleBitsToLong (https://gwt-review.googlesource.com/c/gwt/+/23140) has landed that uses Typed Arrays. This means they won't work in IE8 and IE9 anymore: https://caniuse.com/typedarrays Maybe it's time to remove support for those old

[gwt-contrib] Re: First org.gwtproject.* modules published to Central

FYI, gwt-http and gwt-window have had a 1.0.0-RC2 recently that bring J2CL compatibility (and on GWT2 side add META-INF/gwt/mainModule for use with the gwt-maven-plugin's generate-module goal). On Saturday, May 23, 2020 at 12:08:34 AM UTC+2, Thomas Broyer wrote: > > Hi all, > > I

Re: [gwt-contrib] Re: Required JDK version to build GWT?

something older than Java 11 in anticipation of >this emulation to be finished, 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: > > > >

Re: [gwt-contrib] Re: Required JDK version to build GWT?

es available to gwt > projects. Tests are a different story, as discussed. > > > > > On Tuesday, June 30, 2020 at 4:40:29 PM UTC-5, Goktug Gokdogan wrote: >> >> (which you already pointed but what matters me the most :)) >> >> On Tue, Jun 30, 2020 at 11:39 A

[gwt-contrib] Re: Required JDK version to build GWT?

So, IIUC, there are 2 distinct issues, but both related to JDK versions. First, the doclet/taglet where JDK8 has com.sun.javadoc and JDK9+ have jdk.javadoc.doclet. This is an internal tool, so it would be wasted effort to maintain 2 versions. Either we keep the current code and require JDK8,

Re: [gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

On Monday, June 29, 2020 at 8:43:25 AM UTC+2 frank.h...@googlemail.com wrote: > Thanks everybody for input. > > As @Colin already mentioned I was talking about option 4 of Thomas list. I > have moved gwt-safecss as separate modules into gwt-safehtml. (Need to add > a note at the existing

[gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

AFAICT, safecss depends on SafeUri only, which currently is in com.google.gwt.safehtml, and safehtml depends on both SafeUri and SafeStyles (though only for their class names during codegen, so optional except for tests). This means that either: 1. we split up a gwt-safeuri (with UriUtils,

Re: [gwt-contrib] CI / Jenkins configuration issue

On Wednesday, June 17, 2020 at 5:29:23 PM UTC+2, Roberto Lublinerman wrote: > > If you want to have a look on why the presubmit trigger ( > https://gwt.googlesource.com/buildglue/+/refs/heads/master/jenkins/jenkins.go) > > is failing you could probably replicate it locally and if anybody >

Re: [gwt-contrib] Re: Discussion on changing gwt release groupid

On Monday, June 15, 2020 at 7:44:34 PM UTC+2, Thomas Broyer wrote: > > FYI, I've made a couple more tests, and added the results to the README: > https://github.com/tbroyer/gwt-relocation-tests > Unsurprisingly, the "dumb" resolution rules ("nearest def

Re: [gwt-contrib] Re: Discussion on changing gwt release groupid

ting > the "easier" ones at this time. > > -- > Colin Alworth > co...@colinalworth.com > > > > On Sun, Jun 14, 2020, at 3:16 PM, Thomas Broyer wrote: > > > > On Sunday, June 14, 2020 at 10:07:48 PM UTC+2, Colin Alworth wrote: > > Nice, I

Re: [gwt-contrib] Re: Discussion on changing gwt release groupid

On Sunday, June 14, 2020 at 10:07:48 PM UTC+2, Colin Alworth wrote: > > Nice, I have something very similar. My main finding is putting relocation > in the BOM doesn't work, unless you _also_ include the previous version's > dependencyManagement tag, so that it tells the projects which include

Re: [gwt-contrib] Re: Discussion on changing gwt release groupid

Fwiw, I started setting up some tests here: https://github.com/tbroyer/gwt-relocation-tests Feel free to contribute issues or pull requests. For now, Maven actually fails because the repository only includes POMs and not JARs. I'll add empty JARs soon. On Friday, June 12, 2020 at 5:47:12 PM

Re: [gwt-contrib] Re: Ant, ZipScanner, and GWT

On Friday, June 12, 2020 at 11:05:34 PM UTC+2, Colin Alworth wrote: > > So, given either "make a git repo on gwtproject/ and add a jar to > gwtproject/tools" with the minimal history, or a single commit adding all > already-modified classes to gwt in one go? I should be able to turn out >

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

supported and keep the current behavior in the ie8 permutation. On Friday, June 12, 2020 at 8:45:10 PM UTC+2, Thomas Broyer wrote: > > Fwiw: IE11 will be EOL for mainstream in October this year: > https://www.swyx.io/writing/ie11-eol/ (of course, for enterprise > customers

Re: [gwt-contrib] Re: HashCode H$ property should be not enumerable

Fwiw: IE11 will be EOL for mainstream in October this year: https://www.swyx.io/writing/ie11-eol/ (of course, for enterprise customers this will be longer; my opinion is that those companies that have enough money to pay for special Microsoft support contract could also pay a company to fork

[gwt-contrib] Re: Ant, ZipScanner, and GWT

To minimize the work, and because 1.6.5 works well for us without known vulnerability, I would either copy/paste the code into gwtproject/gwt or provide it in a JAR in gwtproject/tools and call it a day. We already have a copy of Rhino (with changes for JSNI), and a slimmed down version of

[gwt-contrib] Re: Discussion on changing gwt release groupid

ogle (which is what we're trying to avoid in the > first place) such as for Gin, GwtQuery, possibly others like GwtMockito. > > I feel like I might be being dense here, is this cleaner than I'm > imagining it? I'll try spinning up a few sample projects and artifacts with > dummy g

[gwt-contrib] Re: Discussion on changing gwt release groupid

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/gwtproject/ repositories > and jars, so they can be released separately and managed directly on

[gwt-contrib] First org.gwtproject.* modules published to Central

Hi all, I updated gwt-http, gwt-events, gwt-window, gwt-history, and gwt-places to GWT 2.9.0 and Elemental2 1.0.0, and just released 1.0.0-RC1 versions of each of them. Time to test and report any issues with them: - https://github.com/gwtproject/gwt-http -

Re: [gwt-contrib] CI / Jenkins configuration issue

On Sunday, May 3, 2020 at 3:37:30 PM UTC+2, Colin Alworth 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

[gwt-contrib] Re: Testing GWT 2.9.0 for release

On Tuesday, April 28, 2020 at 3:52:32 PM UTC+2, Alexander Bertram wrote: > > Hi, > > When moving to gwt-2.9.0-RC1 and elemental2 1.0.0 (from elemental2 > 1.0.0-RC1), it seems that HTMLElement no longer has a click() method > defined. Is that intentional? Is there alternative? We use this to

Re: [gwt-contrib] Testing GWT 2.9.0 for release

On Sunday, April 19, 2020 at 6:53:23 PM UTC+2, ManfredTremmel wrote: > > correct inherit order, supersource replacements of existing gwt classes). > Speaking of that, it's breaking HEAD-SNAPSHOT: https://groups.google.com/forum/#!topic/google-web-toolkit/7_-tpK8s_cM (see discussion in

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

On Wednesday, June 5, 2019 at 4:53:33 PM UTC+2, Jens wrote: > > > I looked at the file and the GWT code using it and the format seems pretty >> clear to me. >> > > Totally forgot to write the format down for documentation: > > europeBerlin = { > > // Time Zone Id > "id": "Europe/Berlin", >

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

On Wednesday, June 5, 2019 at 11:01:59 AM UTC+2, Jens wrote: > > I looked at the file and the GWT code using it and the format seems pretty > clear to me. Writing a new tool looks pretty simple, we just have to decide > which implementation strategy to choose. > > > 1.) use JDK java.time

[gwt-contrib] Re: Java 9, 10 JRE emulation reviews

On Thursday, January 31, 2019 at 8:35:15 AM UTC+1, Jens wrote: > > > Likewise, has someone had the chance to look at Java 9+ support for our >> ant build? >> > > I tried building GWT a few days ago with Java 11. Seems like we first have > to apply the patch of Andrei ( >

[gwt-contrib] Re: Template for porting GWT modules

The google-java-format plugin is not compatible with Gradle 5.0 (yet, fix has been made, but not yet released). Use ./gradlew, not gradle. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving

Re: [gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

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 TimeZoneConstants.properties, it says it is > generated from CLDR

[gwt-contrib] Re: Template for porting GWT modules

Setting a reminder for tomorrow. I'll see what I can do this weekend. On Friday, December 7, 2018 at 12:39:52 PM UTC+1, Ahmad Bawaneh wrote: > > Hi > > For maven we have a template for ported GWT modules to GWT 3.0 here > https://github.com/Vertispan/some-gwt-module > It would be realy helpful

[gwt-contrib] Re: What tool generates TimeZoneConstants.properties?

On Friday, December 7, 2018 at 1:54:09 PM UTC+1, Ahmad Bawaneh wrote: > > Anyone know what is generating TimeZoneConstants.properties, it says it is > generated from CLDR version 25 .. but i cant find any thing that generates > this gile in gwt code nor in gwt-tools code, was it generated

Re: [gwt-contrib] Re: 2.9 progress

I'd vote for only supporting zone offsets at first. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[gwt-contrib] Re: "GWT RPC" and its role in the future of GWT

Everyone knows I don't like GWT-RPC (specifically related to some of the points "Learner" listed), but I cannot deny that it's been a big selling point of GWT over the years. For that reason alone, I won't oppose to it being in the org.gwtproject namespace. So let's do that (but IMO make it

[gwt-contrib] Re: Java10 support

On Thursday, July 12, 2018 at 4:18:38 PM UTC+2, stuckagain wrote: > > Thomas, > > would you mind pushing a new snapshot release of your maven plugin release > to sonatype ? > I see that you have migrated to a newer version of the surefire plugin on > github, but this version is not yet

Re: [gwt-contrib] Re: Migrating and update gwt-user.jar modules to github.com/gwtproject

FYI, I just finished transferring ownership of all my modules to the gwtproject organization on GitHub; and published them all (HEAD-SNAPSHOT) to Sonatype OSSRH. On Thursday, April 12, 2018 at 6:58:12 PM UTC+2, Colin Alworth wrote: > > >

[gwt-contrib] IntelliJ IDEA project config

Have you tried importing the Eclipse projects? This is what I did I believe, and didn't remember changing many things afterwards. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from

Re: [gwt-contrib] Re: Porting gwt-i18n module to gwt3

on and get more involved. > I agree that we should aim for maximum backwards compatibility, but there *will* be breaking changes anyway (if only to replace GWT.create() with calls to a –generated– static factory). I'll try to setup a document today with what I have in mind so we can discuss. > > Tha

Re: [gwt-contrib] Re: Porting gwt-i18n module to gwt3

On Saturday, April 7, 2018 at 3:03:39 PM UTC+2, Learner Evermore wrote: > > I think I18N is important. However, we never liked or used the GWT 2.x > style of it because it requires dev time knowledge of locales and > multiplies permutations (compile time). It was also inflexible another way >

[gwt-contrib] Re: Naming convention for ported GWT modules

On Saturday, April 7, 2018 at 6:48:53 PM UTC+2, Jens wrote: > > > Fwiw, I can see zero reason why examples would be published to a Maven >> repo. > > > Well right, although quite a lot projects do so. But maybe just because > examples are part of a multi module project and they just deploy

[gwt-contrib] Re: Naming convention for ported GWT modules

On Friday, April 6, 2018 at 6:16:50 PM UTC+2, Ahmad Bawaneh wrote: > > Hi > i am working on date pickers for domino-ui, mean while i found that in > order to support different locales in the date picker i need the > DateTimeFormat information for each locale, gwt in the other hand has a >

[gwt-contrib] Java 9+ modules for GWT

J2CL has no notion of modules (no "source path" or other "classpath subsetting", no "public path", no defined properties and no predefined values, no "entry point", no deferred binding). GWT 3 might still have some of them (entry point, matrix of properties, some kind of "public path" or custom

[gwt-contrib] Re: Java10 support

On Tuesday, April 3, 2018 at 9:00:32 AM UTC+2, Alexander Leshkin wrote: > > Is there anyone who works on Java10 support? I mean dependencies update > (ASM, JDT) and new language feature - Local-Variable Type Inference > . > If not, I can try to create PR. >

[gwt-contrib] Re: Naming convention for ported GWT modules

Fwiw, I can see zero reason why examples would be published to a Maven repo. Wrt events, each corresponds to a different GWT module: c.g.g.event+c.g.w.b.event, c.g.g.event.logical, and some adapters for when you need to mix org.gwtproject.event with c.g.g.event or c.g.w.b.event. We could also

[gwt-contrib] Re: Naming convention for ported GWT modules

On Saturday, March 24, 2018 at 10:30:10 AM UTC+1, Mincong Huang wrote: > > Hi, > > I'd like to have a clarification about the naming convention for ported > GWT modules. Because I'm porting the module `gwt-safecss` and > `gwt-animation`. When I go to Vertispan repository [1], the available >

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

On Friday, February 16, 2018 at 11:42:14 AM UTC+1, Nándor Előd Fekete wrote: > > The fix for this bug got backported to the 4.7 line of Eclipse. Will there > be a 2.8.3 GWT release and do you guys plan to upgrade to this version of > JDT if so? > I don't know when (or whether, but that's

Re: [gwt-contrib] JUnit tests without Generators

Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit

[gwt-contrib] Re: Porting gwt-i18n module to gwt3

On Sunday, January 7, 2018 at 7:00:45 PM UTC+1, Thomas Broyer wrote: > > > On Friday, January 5, 2018 at 6:33:48 PM UTC+1, Ahmad Bawaneh wrote: >> >> Dears >> I am working on porting the *i18n* module, so far all i did is extract >> the module and the tests into

[gwt-contrib] Re: Porting gwt-i18n module to gwt3

On Friday, January 5, 2018 at 6:33:48 PM UTC+1, Ahmad Bawaneh wrote: > > Dears > I am working on porting the *i18n* module, so far all i did is extract > the module and the tests into and external repository and make the tests > pass, not real change to the code have been yet. but the *i18n*

[gwt-contrib] Re: Which API for a future, modern JSON library?

On Monday, December 11, 2017 at 10:44:07 PM UTC+1, Slava Pankov wrote: > > I think it's better to replicate GSON like API on client side. Another > option is doing better version of RestyGWT without GWT.create() > Do you mean GSON's JsonElement API, or mapping to POJOs? If the latter, then

Re: [gwt-contrib] Which API for a future, modern JSON library?

On Monday, December 11, 2017 at 9:39:52 PM UTC+1, Peter Donald wrote: > > Hi, > > Have you considered the javax.json API? No, just like I didn't consider org.json. > There are some parts that may > not be able to be directly translated but from memory it should mostly > work. The

[gwt-contrib] Which API for a future, modern JSON library?

Hi all, Following up on https://github.com/gwtproject/gwt/issues/9484#issuecomment-277216304, I've been toying around to build a new JSON library for GWT. Note that my goal is to have a lightweight library that could be used both on the client-side with GWT (and then j2cl), and on the

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

On Friday, November 17, 2017 at 5:37:59 PM UTC+1, 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

Re: [gwt-contrib] Re: Elemental2:1.0.0-beta-2 released

There must be some cases where it requires the current head, but so far I haven't had any issue with 2.8.2. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [gwt-contrib] Re: Elemental2:1.0.0-beta-2 released

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

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

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 be deciding if we think the CLA > Some links about CLAs:

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote: > > 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

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

On Wednesday, November 15, 2017 at 5:40:11 PM UTC+1, Andrei Korzhevskii wrote: > > I vote for boring way, ie allocate these (module) projects on github and > follow usual pull requests workflow and deploy it as snapshots during > development. > Reasoning is that I don't see much sense in

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

On Wednesday, November 15, 2017 at 5:00:59 PM UTC+1, Colin Alworth wrote: > > 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 Kurk

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Wednesday, October 11, 2017 at 9:02:26 PM UTC+2, Goktug Gokdogan wrote: > > There should be something around syncToServer + HtmlUnit causes the issue > (I guess RPC gets called back sooner than timeout(0) but didn't debug) but > I don't think this in practice will effect anything else. > >

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

, October 11, 2017 at 10:52:41 AM UTC+2, Thomas Broyer wrote: > > > > On Wednesday, October 11, 2017 at 4:52:06 AM UTC+2, Goktug Gokdogan wrote: >> >> tbroyer: Are you using batch mode while testing? We are using -batch >> module internally and maybe you guys do not

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

Scheduler.scheduleEntry and Scheduler.scheduleFinally commands called. Am I getting things right? > > On Tue, Oct 10, 2017 at 1:04 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > >> I'll try with the manual runstyle, i.e. with a real browser, and see how >> it goes. Thanks for the feedbac

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

I'll try with the manual runstyle, i.e. with a real browser, and see how it goes. Thanks for the feedback. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Tuesday, October 10, 2017 at 6:08:05 PM UTC+2, Colin Alworth wrote: > > 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

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Saturday, October 7, 2017 at 9:37:38 PM UTC+2, Thomas Broyer wrote: > > > > On Saturday, October 7, 2017 at 5:20:15 PM UTC+2, Thomas Broyer wrote: >> >> >> >> On Saturday, October 7, 2017 at 4:54:28 PM UTC+2, Col

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Saturday, October 7, 2017 at 5:20:15 PM UTC+2, Thomas Broyer wrote: > > > > On Saturday, October 7, 2017 at 4:54:28 PM UTC+2, Colin Alworth wrote: >> >> Like we do for >> com.google.gwt.junit.RunStyleHtmlUnit.HostedJavaScriptEngine so we can hook >> i

Re: [gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Saturday, October 7, 2017 at 4:54:28 PM UTC+2, Colin Alworth wrote: > > 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

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Saturday, October 7, 2017 at 3:01:52 PM UTC+2, Colin Alworth wrote: > > 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 >

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Friday, October 6, 2017 at 7:55:15 PM UTC+2, Colin Alworth wrote: > > 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

[gwt-contrib] Re: Jetty upgrade broke HtmlUnit for window.onerror

On Friday, October 6, 2017 at 7:55:15 PM UTC+2, Colin Alworth wrote: > > 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

[gwt-contrib] Re: Last call for GWT 2.8.2 patches, and testers needed!

On Tuesday, October 3, 2017 at 12:28:48 PM UTC+2, Colin Alworth wrote: > > As you can see from https://github.com/gwtproject/gwt/milestone/18 > , > > GWT 2.8.2 is

Re: [gwt-contrib] Super slow compilation in projects with many wildcard generics

Note that this means GWT will effectively require JDK 8 for development (gwt-servlet could possibly still work with 1.7, though at that point I'd push for 1.8 too)

[gwt-contrib] Re: Make GWT fun again - what's the status of faster GWT compilation from scratch?

On Friday, August 4, 2017 at 9:37:12 AM UTC+2, Geoffrey De Smet wrote: > > Currently we suffer a lot from time-consuming and memory-hungry GWT > compilation on a big project, especially during a "mvn clean install", the > GWT compilation takes several minutes. > GWT super dev mode does

Re: [gwt-contrib] Re: Question about contributing with java.util.concurrent emulation

+1 I think it's better to refactor code than have partially emulated (breaking contracts) classes. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[gwt-contrib] Re: $entry() wrapper and JsInterop

On Tuesday, July 11, 2017 at 1:46:55 PM UTC+2, Ignacio Baca Moreno-Torres wrote: > > What is going to happen with $entry() utility? Some guidance in the > JsInterop gdoc will be a good idea so libs-creator can apply a uniform > strategy. > > Elemento, for example, is waiting to see what to do

Re: [gwt-contrib] Fwd: jsinterop: @JsFunction .length always 0

On Wednesday, June 28, 2017 at 2:21:16 PM UTC+2, Vassilis Virvilis wrote: > > I am not following the implementation details and I cannot judge on the > compromises front. > > But from a user standpoint this should be implemented because a > @JsFunction should generate a js function() and a js

Re: [gwt-contrib] Fwd: jsinterop: @JsFunction .length always 0

I suppose makeLambdaFunction could be "inlined" (possibly into a static factory, one per class), with the 'lambda' then generated with the proper number of formal arguments to "initialize" its 'length' property? Would that hurt "optimizability" a lot? Or is that not worth it (too much of an

Re: [gwt-contrib] Fwd: jsinterop woes: Part 1: instanceof function in generics casting

On Sunday, June 25, 2017 at 1:24:40 PM UTC+2, Vassilis Virvilis wrote: > > Ηι, > > thanks for answering > > d3.ordinal does not exist as you said. However d3.scale.ordinal exists and > that part works great. > But it is not a type, so you cannot use 'instanceof' on it. > in d3 ordinal is

[gwt-contrib] Re: Java 9

On Tuesday, June 13, 2017 at 5:55:33 PM UTC+2, James Nelson wrote: > > >> Could that work if we complemented the "instanceof URLClassLoader" with >> some check for "is the system classloader" and then use >> System.getProperty("java.class.path") (or the equivalent >>

[gwt-contrib] Fwd: Usage of file handles/file streams in GWT source code

Moving discussion to GWT Contrib. On Sunday, June 11, 2017 at 9:35:30 PM UTC+2, mr.g...@gmail.com wrote: > > Reading and writing of files should only be done using try-with-resources. > This might not be an issue on Linux, but it is a serious issue on Windows > where I repeatedly get conflicts

[gwt-contrib] Re: Java 9

On Thursday, June 8, 2017 at 12:13:35 AM UTC+2, James Nelson wrote: > > So, to be pedantic: > > Language features -> no issues there at all, since JDT happily compiles > java 8 code w/ a java 9-compatible compiler. > Emul updates -> standard "don't use java 9 methods if you need java 8 >

[gwt-contrib] Re: Adds Event.ONINPUT (issue 4549). (issue1248801)

Related: https://groups.google.com/forum/#!topic/google-web-toolkit/k_o1fYjETY4 (tl;dr: it *is* possible, it just needs a bit more work on your part; JSNI or JsInterop/elemental2 are also an option) On Tuesday, June 6, 2017 at 4:49:28 PM UTC+2, Maciek Smolczewski wrote: > > I'm trying to

Re: [gwt-contrib] Using GWT libraries from J2CL

On Sunday, June 4, 2017 at 11:57:50 AM UTC+2, Thomas Broyer wrote: > > With a small modification to EventBinder (adding an inherited annotation), > one could write an annotation processor that's fully backwards-compatible > with the current approach. The GWT generator coul

Re: [gwt-contrib] Using GWT libraries from J2CL

I'll transition to it without having to wait > for GWT3. > > On Friday, June 2, 2017 at 7:10:24 PM UTC+2, Thomas Broyer wrote: >> >> GWT 3 will likely still have SimpleEventBus (and it would compile with >> j2cl without change). >> >> And gwteventbinder could

Re: [gwt-contrib] Using GWT libraries from J2CL

GWT 3 will likely still have SimpleEventBus (and it would compile with j2cl without change). And gwteventbinder could quite easily be ported to an annotation processor. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from

  1   2   3   4   5   6   7   8   9   10   >