https://gist.github.com/niloc132/5cf8162ccc3503215f12d151f4c03168
Patch is done, will have it up soon after a bit more poking.
On Friday, April 29, 2016 at 4:38:15 AM UTC-5, Thomas Broyer wrote:
>
>
>
> On Thursday, April 28, 2016 at 11:47:48 PM UTC+2, Colin Alworth wrote:
>>
>> I didn
A few issues have come up (both in my own projects and in the issue
tracker) where it seemed that continuing to maintain and update the GWT
Generator and Linker types may be necessary. At least one was fairly
low-hanging fruit (up for review
at https://gwt-review.googlesource.com/#/c/14750/), b
Thanks everyone. Since we don't really have much of a consensus on this,
perhaps we can take some middle ground here?
I certainly agree that we want people to move away from generators in
general, though without finished solutions for some of the tricks
generators can do, this will be tricky. A
Unfortunately, you can't add the annotation to an interface with more than
one method, even if those methods are default methods, at least as it is
currently implemented.
I can't remember the exact specifics around why this is the case, but
believe it has to do with handling functions passed from
@googlegroups.com> wrote:
> We cannot impose @JsFunction restrictions on standard library
> @FunctionInterfaces. You can see some of the limitations in the Javadoc.
>
> @Colin: I didn't understand your solution. Feel free to propose something
> more concrete and we can discuss
What maven repo has the SNAPSHOT in it?
Is https://github.com/ManfredTremmel/gwt-bean-validators the source for
this? Great work, looking forward to putting this to use, and porting it to
annotation processors for long-term GWT support!
I'm working with Frank Hossfeld on porting Editors to APT as
Kay, can you offer a reproducible example of this, and confirm that you
have no older copy of GWT (like gwt-user/gwt-dev from 2.8.0-beta1) on your
classpath? To test this, I just built some quick autobeans in a simple
project (so that I didn't need a full server to back it):
public DefaultMethodIn
Part of the problem would come from figuring out how to call from JS back
into Java - if you called resolve(null), was null a T or was null a
Promise? And from JS, how could you typecheck to figure out whether to call
the resolve_1(value) or resolve_2(promise)?
Its also possible in JS to call with
Looks like somehow the JsInterop jars are missing from the google-snapshots
repo now, making it difficult to use the latest nightlies.
http://build.gwtproject.org/job/gwt/615/console shows creating, signing,
and deploying:
Signing and Deploying ./poms/jsinterop/pom.xml to
https://oss.sonatype.o
Another issue at may warrant attention -
https://github.com/gwtproject/gwt/issues/9424. This was brought up some
time ago, but wasn't reduced to be reproducible until now (which is funny,
given how minimal the test case is).
On Fri, Sep 9, 2016 at 9:30 AM 'Daniel Kurka' via GWT Contributors <
goog
With 3.0 on the horizon, we've promised consistency of a sort in 2.x, and
without 3.0 actually in sight, 2.x is going to need to see active
development. Encouraging a third generation of url tools is not a bad
thing, but only switching over half-way leaves something to be desired.
I'll play dev
I agree entirely, just trying to see this as a potential contributor with
its associated steep learning curve, and address the question of "Should we
stop adding new features?".
we're rather in a situation of "I'd like to add this new feature to GWT;
> and this is something I could do in my own
I've spent a little time over the last week trying again to tease apart GWT
into smaller modules and working out dependencies between them. This is in
part to see about a not-ant build system, and in part to see why a minimal
GWT app is surprisingly big. The target here isn't the user lib, but t
As previously mentioned, I'm walking over a lot of old GWT and playing with
some ideas around structure changes. Along the way, I've found some
apparently dead classes, and some very rotten docs.
For example, at the root of each zip release including 2.8.0, we have
about.html, which proudly sta
Without actually compiling the code (see my final paragraph...), you
might not even need the safari permutation, but might get by with no
UserAgent wiring at all. You could experiment with your inherits
statements, and see if you can remove User, and only depend on
com.google.gwt.core.Core from t
Class literals for any object which can be created need to exist for
getClass(), which is called by toString() at the very least - if the
compiler sees any Object.toString, it must leave in all getClass methods -
further reasoning about that might be tricky, and is a little out of my
wheelhouse
I'm trying to keep to good practices in my projects and tools going
forward, and seem to either be doing something very wrong, or have hit a
possible bug in GWT. Specifically, the selection script seems to look at my
one property with three different values, and believes that not only are
there
Alas, changing the property in the java and .gwt.xml to "my.locale" does
not result in less incorrect code:
unflattenKeylistIntoAnswers(['en'],
'85A0B45105661378F351C4FA6230BF99');
unflattenKeylistIntoAnswers(['es'],
'85A0B45105661378F351C4FA6230BF99');
unflattenKeylistIntoAns
On Wednesday, February 15, 2017 at 4:01:01 PM UTC-6, Goktug Gokdogan wrote:
>
> Thanks for the feedback.
>
> On Wed, Feb 15, 2017 at 1:05 PM, Ming-Yee Iu
> > wrote:
>
>> Well, ok. Thanks.
>>
>> Just in terms of general feedback on Elemental2:
>>
>> 1. I'm not sure whether the conversion of JavaS
Yes, there is a plan to do a release - this is in part my fault for failing
to communicate this correctly (by way of steering committee meeting notes).
We are waiting on a few patches before we can start the testing process and
get the release under way.
On Friday, March 17, 2017 at 9:13:09 AM
We're about ready to release GWT 2.8.1, a bugfix release a variety of
issues, including getting a stable release out that works with the new
jsinterop.base and elemental2 beta jars. I will need some help in
validating this release on our supported platforms, please contact me if
you are availab
Is the current plan to open source the experimental part as well? I suspect
there are people on this list who would be very interested in helping to
continue that effort.
On Tuesday, April 18, 2017 at 6:52:57 PM UTC-5, Julien Dramaix wrote:
>
> We are working internally on a jsinterop generator
Dissenting opinion, mostly for the sake of discussion (though I'll admit to
being an RPC fanboy too):
This came up in discussion in ##gwt today, from the other perspective - the
stockwatcher app uses JsonpRequestBuilder, which is incompatible with
JsType without some seriously fugly casts (as f
I'm very pleased to announce the release of GWT 2.8.1. This contains many
bugfixes and a few enhancements to JsInterop.
Highlights from release notes:
-
Elemental1's JSON parser now correctly throws an exception when a
string, object, or array is not correctly ended.
-
What had been the care previously? Were you calling the chrome methods in
some way other than through JSNI? Java methods can't call raw JavaScript
without JSNI (or JsInterop, which didn't exist in GWT 2.6).
Otherwise I'm not sure what you changed it _from_ to get to the psuedocode
in your post.
If it is the linker, going back to your 2.6 code and changing to the
current xsiframe linker might show the bug - if so, you know it is related
to the default linker change. If not, debugging your JSNI to see what the
value of chrome is before and after the GWT version change will be helpful,
o
Are there specific Java9 JRE classes that we should focus on to get into
GWT?
Would making GWT support Java9 sources and running in a Java9 env cause
backward incompatible changes that prevent GWT from running in Java8?
On Wednesday, June 7, 2017 at 2:56:46 PM UTC-5, James Nelson wrote:
>
> As
and the response shouldn't be
able to throw in setHeader). Or is there something concerning in
handleRequest that you see which can surprisingly error out before
page.send(...) can be reached?
--
Colin Alworth
co...@colinalworth.com
On Mon, Jun 12, 2017, at 04:29 AM, Thomas Broye
aye need 3 more, , ,
, so I don't think this is a serious suggestion).
Otherwise your email seems to suggest that we need a type in
jsinterop.base for all JS arrays instead of our current situation of
pretending that java arrays and js arrays are compatible.
--
Colin Alworth
co...@colinalwort
Using GWT 2.8.1, I'm trying to iterate through items found via a query
selector:
Arrays.asList(document.querySelectorAll("button.with-some-class").asArray
()).forEach(
item -> doSomething(item)
);
Unfortunately, this seems to always fail - querySelectorAll returns a
NodeList, and while
Seems like a good reason to defer to GWT 2.9.
On Mon, Oct 2, 2017, at 02:48 AM, Thomas Broyer wrote:
> 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)>
> https://www.eclipse.org
Juan, you just signed up, thanks to you and Boris for being so
consistently helpful with GWT.
Anyone else can feel free to either reply to the list, or email me
personally.
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from
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 does
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 maintai
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 fr
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
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 Goo
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 t
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 pick
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 from
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 A
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
art
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
s us the ability to
look back in history, and see 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,
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 forw
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
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
'jar:file:/Users/colin/.m2/repository/com/goog
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
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 late
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 t
TimeFormat.formatToParts 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
O
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
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 list
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, Go
>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 t
, 2018 at 1:59:12 PM UTC-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, F
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 di
"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 org
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:
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 t
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.
ownloaded a
> 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:
>>
>> F
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
qui
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
p
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.
--
Col
o git, so 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 generat
quick 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 t
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 t
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,
correct
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
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 r
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
* JV
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
releas
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 runn
jsinterop-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'
in what I 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
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.
--
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 U
all tests pass, 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, Thom
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
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 me
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
org.
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
concrete experiments.
On Wednesday, 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
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 m
some 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 w
f 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
tools repo 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, 2
locate 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://git
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...@c
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 appears to
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 le
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.
W
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:
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 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 ve
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
soon. Again, not 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 Contri
1 - 100 of 261 matches
Mail list logo
