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 El jue., 28 jul. 2016 a las 17:57, Thomas Broyer (<t.bro...@gmail.com>) escribió: > 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. > > -- > 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 on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEPpGsGk1YZsAMKg_5mXwvxU7F1wJT1y9aWL-Wj8ybvxFw%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHEPpGsGk1YZsAMKg_5mXwvxU7F1wJT1y9aWL-Wj8ybvxFw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvGwgyJ1aiaLZQdfAh61tZCYvnTR3NksbpaO9QVAVwHvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
