Thinking about the future: GWT 3, J2Cl, modularization, etc.

[Thomas Broyer]

Hi all,

We've talked about modularizing GWT for several years now, and I gave it a try at several occasions, with Maven, then Gradle, then Buck… and last year I completely gave up, knowing the J2Cl was coming which would be quite disruptive, with the hope that we could start on new grounds (including a fresh start from the built tool side; farewell Ant!). As GWT 2.8.0 is approaching (RC1 is imminent), I think it's time we start talking about that GWT 3 future with J2Cl at its core.

As I understand it, Google would rather have things as "exploded" as possible: J2Cl and emulation in one repo (or possibly even split in 2), then each "module" in its own repo (elemental2, etc.) with its own maintainers and moving at its own pace (and possibly even its own contributing guidelines: using GitHub+Travis? Gerrit+Jenkins? GitHub+GerritHub+Travis? and its own build tools: Maven vs. Gradle vs. whatever)

First: I'm all for it!

The way I see it, Google would opensource J2Cl, and we (the community) would start moving bits from GWT out to their own repos (either removing them from GWT proper –the challenge then is to make sure it stays compatible with both GWT 2.x and J2Cl/GWT 3.x– or duplicating them –the challenge being to keep both versions in sync, as we don't want to abandon GWT 2.8.x users; but 2.x maintenance is another, though closely related, topic).

It's been suggested during the last Steering Committee meeting that the community (i.e. "outside Google") may want to package/bundle many such things together into "GWT 3.x" releases; probably a bit similar to how Eclipse cuts yearly releases bundling many plugins/features together into downloadable packages.

On one hand, it requires picking (or cutting?) specific "releases" of each module to be bundled and testing them all together to make sure they all play well with each other, which is relatively time-consuming (and one reason Google doesn't want to do it, given they don't even use "releases" internally but always run "from trunk").

On the other hand, it makes it easy for users, particularly newcomers, to refer to their setup: “I use GWT 3.0.1” vs. “I use J2Cl x, emul y, elemental2 z, polymer-jsinterop i, places j, activities k, etc.”

Also, without such bundles, what it is that we would call “GWT 3”? Would it become an “umbrella term” a bit like “HTML5”?

There's also been pushbacks from the community that we should have (possibly semi-automated) releases several times a year (every month, every quarter, or twice a year), even with minimal testing (not as "unstable" as "nightlies" –which we currently have with SNAPSHOTs– but more similar to a "canary" release channel).

That being said, if we use a "rather standard" build tool (Gradle?), people could use JitPack to "pin" a specific commit/snapshot without the need to have formal intermediate releases (with jitpack.yml one could probably build using Bazel or Buck too, after wget'ing them).

So, WDYT? What should “GWT 3” look like? one bundle like today or a set of projects? or possibly a set of projects with a scaffolding tool (yeoman?) and build tool integrations?

Also, what would gwtproject.org say? would it talk about each module? or leave each module's documentation to the modules themselves? (note that we could come up with a rule saying that each maintainer is responsible for updating the documentation on gwtproject.org, with someone to "unlist" projects that don't comply for too long). Would GWT 3 become an "ecosystem" around J2Cl more than a "project" by itself? (note that there are branding –i.e. legal– issues too around that).

I, for one, would be OK with just "a set of projects" on a "practical" basis, though I easily admit that it probably wouldn't help "marketing" it.

[Manuel Carrasco Moñino]

Since  3.0 details aren't yet clear enough, I agree that it should be modular, and eventually  modules from 2.8.x could be used or ported to 3.0

So the ideal situation is that we are able to split gwt 2.8.x into as much independent modules as possible, making GWT easier to maintain, and assign maintainers.

I agree also with the idea of 2.8.x being a long term support product.

So to me the roadmap could be,  make 2.8.x support modules (via maven or whatever), and split it. 

IMO 2.9 might be the modular release of GWT, fully compatible with 2.8.

- Manolo

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEPpGsGk1YZsAMKg_5mXwvxU7F1wJT1y9aWL-Wj8ybvxFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ignacio Baca Moreno-Torres]

Sound really good for us! Also similar to JEE which sync a group of libraries and freezes its version in each releases. The idea of 2.9 to be the modular release without J2CL involved sound good too!

I have been thinking in two ideas that might reduces the release and marketing problem respectively.

1. A public continuous project compatibility. In the release workflow, always came to the conversation that google continuously compile the master branch with all its internal project, so is like a massive test on the trunk that assert that all projects works. The idea is to makes the same strategy but in the public face. So open source projects can propose its project to get part of this continuous project compatibility test, this will makes a really good metric of the quality of the master branch, and I hope this might help to make semi-automatic releases much more 'community stable'. The project do not need to be compiled in a central server, alternatively subscribed project can compile itself and sent just the compilation report to GWT for each commit.

2. A centralized gwt lib repo. Actually maven central with the gwt-lib type might be a starting point, but I think that something like the vaadin directory is really the key point improve the "marketing" of GWT. Libs comes with lot of activity, and a centralized lib directory centralize the activity in this place, and also obviously, help find the lib you want specially if you have no experience in GWT. If GWT core is going to be modularized, GWT should maintain at least a sanitized and centralized list of libraries, actually GWT just need to expose some API (which might be just an specification of how to add an app.json in a github repo with some metadata, or type:gwt-lib in maven libs, etc) and I hope that the community will push its libs.

Both ideas are around the same concept, modularization is much agile, but GWT should keep track of all this libs in one place, GWT will not maintain but should organize all around its core (transpiler and emulation).

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.