Packaging issue: org.json and RequestFactory

[Thomas Broyer]

Hi all,

it looks like there's an issue in packaging the GWT SDK (and GWT maven artifacts): org.json is not bundled gwt-user. That makes it harder to use RequestFactory out-of-the-box, as DevMode will have NoClassDefFoundErrors when trying to *send* a request to the server. org.json is bundled into requestfactory-server.jar and gwt-servlet-deps.jar, which makes it usable out-of-the-box on the server-side; it's also bundle into requestfactory-client.jar so you can easily run VM client-side code too (in unit-tests, an Android app, etc.) To run RF code in DevMode, you'd have to add the org.json JAR (downloaded somewhere on the internet) or the requestfactory-client.jar (which duplicates a lot of classes from gwt-user.jar), or the gwt-servlet-deps.jar (which is supposedly related to server-side code only) to your classpath; this is not intuitive.

What's striking is that javax.validation is *not* bundled that way (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as a separate JAR in the SDK; it's not even bundled into gwt-user.jar.

There's a real discrepancy between org.json and javax.validation wrt packaging in the SDK, and none of them is satisfactory.

• requestfactory-* JARs contain org.json but not javax.validation
• gwt-user contains none of them
• gwt-servlet-deps is made of only org.json and javax.validation, so why ship javax.validation in addition to it?

IMO, both dependencies should receive equal treatment: either ship as separate JARs in the SDK (json.jar and validation-api.jar), or be bundled where needed (if you ask me, only in gwt-user.jar –similar to what's done with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or duplicated as requestfactory-deps.jar, as they are dependencies for both requestfactory-client and requestfactory-server).

Now, we have similar issues with Maven artifacts: gwt-user.jar depends on javax.validation but not org.json, so the DevMode will fail (whether you launch it with "Run As… Web Application" in Eclipse or "mvn gwt:run") unless you add a dependency on org.json. org.json is not even referenced/documented as an optional dependency (but given that javax.validation is not marked as "optional", there's no reason org.json would be marked "optional").

We're currently facing this issue in gwt-maven-archetypes and I'm not sure what we should do: add a dependency on requestfactory-client (contains duplicate classes from gwt-user) or on org.json (weird as we don't directly use org.json classes, and org.json is not marked as an optional dependency of gwt-user). https://github.com/tbroyer/gwt-maven-archetypes/pull/16

I'll try to submit a patch to have it fixed in 2.5 but we must first settle on the appropriate way to do it (both for the GWT SDK and for Maven artifacts), and I'd also like your feedback on what would be the appropriate workaround while waiting for 2.5.

[Thomas Broyer]

Additional note: requestfactory-client.jar is supposed to be used on Android (not only, but that's one of the advertized goal), so it shouldn't bundle org.json, as this is already provided by the Android platform: http://developer.android.com/reference/org/json/package-summary.html

As for Maven, we could add a com.google.web.bindery:requestfactory-dependencies artifact, with packaging=pom (see http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/), that requestfactory-client and requestfactory-server could depend on (or not)

Alternately, given that gwt-user.jar is only used for dev, it's not really an issue if it's "bloated" (other than the perf issues with GWT Compiler and DevMode with a large classpath), we could simply add org.json as a dependency to gwt-user inaddition to javax.validation (we could also instead add a dependency on the requestfactory-dependencies suggested above ;-) )

I still do not understand why javax.validation is not bundled within gwt-user. There might be some note in the issue tracker, commit log, or code reviews, but I haven't searched yet.

[Ray Cromwell]

For GWT 2.5, we might be able to use the elemental json
implementation, it has both pure JRE and super-source implementations,
and simultaneously replaces org.json and the com.google.gwt.json
packages.

-Ray

> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Thomas Broyer]

On Wed, May 30, 2012 at 12:24 PM, Ray Cromwell <cromw...@google.com> wrote:
> For GWT 2.5, we might be able to use the elemental json
> implementation, it has both pure JRE and super-source implementations,
> and simultaneously replaces org.json and the com.google.gwt.json
> packages.

That'd be great!

Any advice about what we should do with 2.4? (more specifically to fix
https://github.com/tbroyer/gwt-maven-archetypes/pull/16 )
add org.json? (means another version to manage)
add requestfactory-client? (means duplicated classes in the classpath,
but they should come from the same GWT build so there shouldn't be
conflicts)
...or simply wait for 2.5? (as it'll contain so many fixes to RF!)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Rajeev Dayal]

Hey Thomas,

Thanks for pointing this out. This is pretty whacked, and is probably a symptom of a problem that we've had for a long time - how do we handle dependencies on GWT? Should we bundle them, re-package them, or require the user to add them to the classpath?

Other replies inline:

On Tue, May 29, 2012 at 4:51 AM, Thomas Broyer <t.br...@gmail.com> wrote:

Hi all,

it looks like there's an issue in packaging the GWT SDK (and GWT maven artifacts): org.json is not bundled gwt-user. That makes it harder to use RequestFactory out-of-the-box, as DevMode will have NoClassDefFoundErrors when trying to *send* a request to the server. org.json is bundled into requestfactory-server.jar and gwt-servlet-deps.jar, which makes it usable out-of-the-box on the server-side; it's also bundle into requestfactory-client.jar so you can easily run VM client-side code too (in unit-tests, an Android app, etc.) To run RF code in DevMode, you'd have to add the org.json JAR (downloaded somewhere on the internet) or the requestfactory-client.jar (which duplicates a lot of classes from gwt-user.jar), or the gwt-servlet-deps.jar (which is supposedly related to server-side code only) to your classpath; this is not intuitive.

Is this a new problem? It seems that this would have always been present. Was a recent change made to expose this?

All those options that you mention are less-than-ideal. My preference would be to have them download org.json from the Internet, but it rubs me the wrong way that it won't work out of the box.

 

What's striking is that javax.validation is *not* bundled that way (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as a separate JAR in the SDK; it's not even bundled into gwt-user.jar.

There's a real discrepancy between org.json and javax.validation wrt packaging in the SDK, and none of them is satisfactory.

• requestfactory-* JARs contain org.json but not javax.validation
• gwt-user contains none of them
• gwt-servlet-deps is made of only org.json and javax.validation, so why ship javax.validation in addition to it?

IMO, both dependencies should receive equal treatment: either ship as separate JARs in the SDK (json.jar and validation-api.jar), or be bundled where needed (if you ask me, only in gwt-user.jar –similar to what's done with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or duplicated as requestfactory-deps.jar, as they are dependencies for both requestfactory-client and requestfactory-server).

I'd lean towards to having json.jar and validation-api.jar - even though it makes it harder to work with out-of-the-box, we're trying to move in the direction of breaking GWT into smaller components.

Also, when SuperDevMode becomes the default, we're not going to need org.json or javax.validation on the client-side.

Now, we have similar issues with Maven artifacts: gwt-user.jar depends on javax.validation but not org.json, so the DevMode will fail (whether you launch it with "Run As… Web Application" in Eclipse or "mvn gwt:run") unless you add a dependency on org.json. org.json is not even referenced/documented as an optional dependency (but given that javax.validation is not marked as "optional", there's no reason org.json would be marked "optional").

We're currently facing this issue in gwt-maven-archetypes and I'm not sure what we should do: add a dependency on requestfactory-client (contains duplicate classes from gwt-user) or on org.json (weird as we don't directly use org.json classes, and org.json is not marked as an optional dependency of gwt-user). https://github.com/tbroyer/gwt-maven-archetypes/pull/16

Maybe we need to mark org.json as a required dep of gwt-user? Is this possible?

 

I'll try to submit a patch to have it fixed in 2.5 but we must first settle on the appropriate way to do it (both for the GWT SDK and for Maven artifacts), and I'd also like your feedback on what would be the appropriate workaround while waiting for 2.5.

Whatever we do, we're going to have to make sure that we update GPE so that it knows to add the appropriate dependent jars to the classpath. 

 

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

 

[Thomas Broyer]

On Thu, May 31, 2012 at 5:00 PM, Rajeev Dayal wrote:
> Hey Thomas,
>
> Thanks for pointing this out. This is pretty whacked, and is probably a
> symptom of a problem that we've had for a long time - how do we handle
> dependencies on GWT? Should we bundle them, re-package them, or require the
> user to add them to the classpath?

I wouldn't be opposed to having differing rules for the GWT SDK
package downloadable at code.google.com and the Maven artifacts.
AFAIK, the original idea of bundling them into gwt-user.jar (and
gwt-dev.jar) was to make things simpler for users (just put gwt-dev
and gwt-user in the classpath).
For everyone using artifacts from "The Central Repository" (Maven,
Ivy, Gradle, etc.), bundled dependencies hurt more than they help.
As for repackaging (JarJar), this should definitely be done for
patched dependencies! (and deployed to Central as separate artifacts,
just like Sonatype deployed a pre-release andor patched versions of
Guice and Guava:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.sonatype.sisu%22
AFAICT, Sisu Guice is/was used in Maven 3.0)

> Other replies inline:
>
> On Tue, May 29, 2012 at 4:51 AM, Thomas Broyer <t.br...@gmail.com> wrote:
>>
>> Hi all,
>>
>> it looks like there's an issue in packaging the GWT SDK (and GWT maven
>> artifacts): org.json is not bundled gwt-user. That makes it harder to use
>> RequestFactory out-of-the-box, as DevMode will have NoClassDefFoundErrors
>> when trying to *send* a request to the server. org.json is bundled into
>> requestfactory-server.jar and gwt-servlet-deps.jar, which makes it usable
>> out-of-the-box on the server-side; it's also bundle into
>> requestfactory-client.jar so you can easily run VM client-side code too (in
>> unit-tests, an Android app, etc.) To run RF code in DevMode, you'd have to
>> add the org.json JAR (downloaded somewhere on the internet) or the
>> requestfactory-client.jar (which duplicates a lot of classes from
>> gwt-user.jar), or the gwt-servlet-deps.jar (which is supposedly related to
>> server-side code only) to your classpath; this is not intuitive.
>
>
> Is this a new problem? It seems that this would have always been present.
> Was a recent change made to expose this?

As you said, it's probably been there from the beginning.
I've always been using Maven since GWT 2.1-M1, and it had dependency
issues too (neither org.json nor javax.validation were declared as
dependencies), so I didn't noticed it; and we're depending on org.json
transitively from other dependencies so it didn't affected us with
newer GWT versions either.

> All those options that you mention are less-than-ideal. My preference would
> be to have them download org.json from the Internet, but it rubs me the
> wrong way that it won't work out of the box.

Well, org.json hasn't changed for a while, and validation-api is a
"standard" so it won't change either; so it's rather safe to bundle
them in the GWT SDK (but not within the JARs, that's a different
issue).

>> What's striking is that javax.validation is *not* bundled that way
>> (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as a
>> separate JAR in the SDK; it's not even bundled into gwt-user.jar.
>>
>> There's a real discrepancy between org.json and javax.validation wrt
>> packaging in the SDK, and none of them is satisfactory.
>>
>> requestfactory-* JARs contain org.json but not javax.validation
>> gwt-user contains none of them
>> gwt-servlet-deps is made of only org.json and javax.validation, so why
>> ship javax.validation in addition to it?
>>
>> IMO, both dependencies should receive equal treatment: either ship as
>> separate JARs in the SDK (json.jar and validation-api.jar), or be bundled
>> where needed (if you ask me, only in gwt-user.jar –similar to what's done
>> with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or
>> duplicated as requestfactory-deps.jar, as they are dependencies for both
>> requestfactory-client and requestfactory-server).
>
>
> I'd lean towards to having json.jar and validation-api.jar - even though it
> makes it harder to work with out-of-the-box, we're trying to move in the
> direction of breaking GWT into smaller components.

+1
(though it'd be even better to ditch org.json and use the upcoming
JSON lib; BTW, is it the one from PlayN?)

> Also, when SuperDevMode becomes the default, we're not going to need
> org.json or javax.validation on the client-side.

javax.validation would still be needed as a dependency in your code
(for RequestFactory and/or the Editor framework; and given that
c.g.g.editor.Editor is inherited by c.g.g.user.User, wouldn't you have
warnings from GWT about missing sources even if you don't use it?)

>> Now, we have similar issues with Maven artifacts: gwt-user.jar depends on
>> javax.validation but not org.json, so the DevMode will fail (whether you
>> launch it with "Run As… Web Application" in Eclipse or "mvn gwt:run") unless
>> you add a dependency on org.json. org.json is not even referenced/documented
>> as an optional dependency (but given that javax.validation is not marked as
>> "optional", there's no reason org.json would be marked "optional").
>> We're currently facing this issue in gwt-maven-archetypes and I'm not sure
>> what we should do: add a dependency on requestfactory-client (contains
>> duplicate classes from gwt-user) or on org.json (weird as we don't directly
>> use org.json classes, and org.json is not marked as an optional dependency
>> of gwt-user). https://github.com/tbroyer/gwt-maven-archetypes/pull/16
>
>
> Maybe we need to mark org.json as a required dep of gwt-user? Is this
> possible?

It's not possible to update an artifact that's already been published.
There could be a 2.4.1, identical to 2.4.0 except for the dependencies
declared in the POM; not sure it'd be worth it though, given that
we're finishing up 2.5.

>> I'll try to submit a patch to have it fixed in 2.5 but we must first
>> settle on the appropriate way to do it (both for the GWT SDK and for Maven
>> artifacts), and I'd also like your feedback on what would be the appropriate
>> workaround while waiting for 2.5.
>
>
> Whatever we do, we're going to have to make sure that we update GPE so that
> it knows to add the appropriate dependent jars to the classpath.

I don't know for the "AppEngine connected Android project" (or
whatever its exact name), but a "standard" GWT project currently is
missing javax.validation (and of course org.json).

[Rajeev Dayal]

Yes, that would be fine (bundling them with the GWT SDK, but not actually putting them in gwt-user.jar) 

>> What's striking is that javax.validation is *not* bundled that way
>> (except, as expected, in gwt-servlet-deps.jar), it's instead shipped as a
>> separate JAR in the SDK; it's not even bundled into gwt-user.jar.
>>
>> There's a real discrepancy between org.json and javax.validation wrt
>> packaging in the SDK, and none of them is satisfactory.
>>
>> requestfactory-* JARs contain org.json but not javax.validation
>> gwt-user contains none of them
>> gwt-servlet-deps is made of only org.json and javax.validation, so why
>> ship javax.validation in addition to it?
>>
>> IMO, both dependencies should receive equal treatment: either ship as
>> separate JARs in the SDK (json.jar and validation-api.jar), or be bundled
>> where needed (if you ask me, only in gwt-user.jar –similar to what's done
>> with javax.servlet– and gwt-servlet-deps.jar; possibly renamed to or
>> duplicated as requestfactory-deps.jar, as they are dependencies for both
>> requestfactory-client and requestfactory-server).
>
>
> I'd lean towards to having json.jar and validation-api.jar - even though it
> makes it harder to work with out-of-the-box, we're trying to move in the
> direction of breaking GWT into smaller components.

+1
(though it'd be even better to ditch org.json and use the upcoming
JSON lib; BTW, is it the one from PlayN?)

Hm, that I don't know. Added cromwellian for comment.

 

> Also, when SuperDevMode becomes the default, we're not going to need
> org.json or javax.validation on the client-side.

javax.validation would still be needed as a dependency in your code
(for RequestFactory and/or the Editor framework; and given that
c.g.g.editor.Editor is inherited by c.g.g.user.User, wouldn't you have
warnings from GWT about missing sources even if you don't use it?)

Oh shoot, yeah, we would. Don't know what I was thinking there. Sorry.

 

>> Now, we have similar issues with Maven artifacts: gwt-user.jar depends on
>> javax.validation but not org.json, so the DevMode will fail (whether you
>> launch it with "Run As… Web Application" in Eclipse or "mvn gwt:run") unless
>> you add a dependency on org.json. org.json is not even referenced/documented
>> as an optional dependency (but given that javax.validation is not marked as
>> "optional", there's no reason org.json would be marked "optional").
>> We're currently facing this issue in gwt-maven-archetypes and I'm not sure
>> what we should do: add a dependency on requestfactory-client (contains
>> duplicate classes from gwt-user) or on org.json (weird as we don't directly
>> use org.json classes, and org.json is not marked as an optional dependency
>> of gwt-user). https://github.com/tbroyer/gwt-maven-archetypes/pull/16
>
>
> Maybe we need to mark org.json as a required dep of gwt-user? Is this
> possible?

It's not possible to update an artifact that's already been published.
There could be a 2.4.1, identical to 2.4.0 except for the dependencies
declared in the POM; not sure it'd be worth it though, given that
we're finishing up 2.5.

Yeah, I don't think it would be worth doing a 2.4.1 at this point.

 

>> I'll try to submit a patch to have it fixed in 2.5 but we must first
>> settle on the appropriate way to do it (both for the GWT SDK and for Maven
>> artifacts), and I'd also like your feedback on what would be the appropriate
>> workaround while waiting for 2.5.
>
>
> Whatever we do, we're going to have to make sure that we update GPE so that
> it knows to add the appropriate dependent jars to the classpath.

I don't know for the "AppEngine connected Android project" (or
whatever its exact name), but a "standard" GWT project currently is
missing javax.validation (and of course org.json).

Yeah, I think we did that for simplicity, but we should probably add it (in GPE)..

 

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Rajeev Dayal]

On Wed, Jun 6, 2012 at 2:38 AM, James Nelson <ja...@wetheinter.net> wrote:

I wouldn't be opposed to having differing rules for the GWT SDK
package downloadable at code.google.com and the Maven artifacts.
AFAIK, the original idea of bundling them into gwt-user.jar (and
gwt-dev.jar) was to make things simpler for users (just put gwt-dev
and gwt-user in the classpath).  

For everyone using artifacts from "The Central Repository" (Maven,
Ivy, Gradle, etc.), bundled dependencies hurt more than they help.

For unfamiliar users, having everything bundled up into a single massive jar does reduce barrier to entry.

For anyone with a remotely complex build, being able to pick and choose dependencies can be of vital importance.

Aggressive bundling and excessive repackaging can lead to major bloat and potential classpath-order problems,

but just adding one jar is the simplest way to get started.

So, this suggests that gwt-user could be made a bloated super-jar, with validation and json et al. builtin by jarring in maven.

Build this jar from gwt-core, validation, json, elemental, etc. artifacts, but also export these artifacts independently, including a sparse gwt-core.jar.

Anyone who doesn't want the bloated omni-jar can take the sparse-jar and declare dependencies manually, then export only what they need to the server,

while everyone else can just carry on like normal.

I like that idea..

 

In maven, what's in gwt-user now would become gwt-core, and replace gwt-user with a pom stub that just bundles up the omni gwt-user.jar.

gwt-core would be a kernel module representing c.g.g.core.Core + all the .gwt.xml and interfaces / utilities needed to build the gwt environment;

the maven build for core could still suck in all the required dependencies to run with packaging pom, and just export a jar/gwtar in release stage.

Makes sense.

 

So, gwt-user.jar and gwt-core.jar would be mutually exclusive {emit warning that classpath is setup inefficiently}.

If you take gwt-core, you must also take all other jars you actually need, or deal with classpath manually.

If you take gwt-user, don't take any of the other jars; everything is right there.

Though gwt-user.jar would actually encompass gwt-core.jar, right?

 

For IDE / GPE, let it be known that gwt-user is the deprecated way to get up and running quickly,

and gwt-core + jars_you_need is the advanced way to get up to max performance.

 

Seems reasonable.

It may be more work to maintain, and gwt-user.jar updates can only be issued with a stable set of dependencies bundled,

but at least the component projects and artifacts can be updated independently in maven central, and then by hand in user classpath;

that way, if there is an update to request factory or elemental or widgetFrameworkXYZ, the sub-modules can release updates without waiting on a version release.

The problem I see here is if there are two different sub-components that require a different version of the same dependency. I think we'd have to make sure that this never happens.

So, you're saying that we only release a new gwt-user.jar whenever there's a major release? What does this mean with the Maven setup that you're proposing? That we only update the gwt-user.jar POM whenever we have a major release?

For anyone exporting third party libraries, they can just mimic the gwt-user pom to create their own omni-jar, and instruct clients to remove everything but gwt-server/dev. 

 

+1
(though it'd be even better to ditch org.json and use the upcoming
JSON lib; BTW, is it the one from PlayN?)

+1 more.  Some example syntax I saw somewhere suggests it's very PlayN like;

 

>> I'll try to submit a patch to have it fixed in 2.5 but we must first
>> settle on the appropriate way to do it (both for the GWT SDK and for Maven
>> artifacts), and I'd also like your feedback on what would be the appropriate
>> workaround while waiting for 2.5.

For maven, gwt-user 2.4 cannot be changed, but a gwt-core 2.4 can be added with packaging pom, and dependencies declared as needed.

For IDE users, a snapshot release with gwt-core and bundled jars, and maybe a pom.xml / generateProject.sh to do mvn eclipse:eclipse to setup classpath?

That or just a README with setup instructions / warnings.

I'd be inclined to leave 2.4 as-is, and move forward with any packaging changes in 2.5.

 

> Whatever we do, we're going to have to make sure that we update GPE so that
> it knows to add the appropriate dependent jars to the classpath.

I don't know for the "AppEngine connected Android project" (or
whatever its exact name), but a "standard" GWT project currently is
missing javax.validation (and of course org.json).

 

I bring along javax.validation et. al in an eclipse user library, so they're available to dev mode, but never on server classpath.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Thomas Broyer]

On Wednesday, June 6, 2012 8:38:04 AM UTC+2, James Nelson wrote:

I wouldn't be opposed to having differing rules for the GWT SDK
package downloadable at code.google.com and the Maven artifacts.
AFAIK, the original idea of bundling them into gwt-user.jar (and
gwt-dev.jar) was to make things simpler for users (just put gwt-dev
and gwt-user in the classpath).  

For everyone using artifacts from "The Central Repository" (Maven,
Ivy, Gradle, etc.), bundled dependencies hurt more than they help.

For unfamiliar users, having everything bundled up into a single massive jar does reduce barrier to entry.

For anyone with a remotely complex build, being able to pick and choose dependencies can be of vital importance.

Aggressive bundling and excessive repackaging can lead to major bloat and potential classpath-order problems,

but just adding one jar is the simplest way to get started.

So, this suggests that gwt-user could be made a bloated super-jar, with validation and json et al. builtin by jarring in maven.

Build this jar from gwt-core, validation, json, elemental, etc. artifacts, but also export these artifacts independently, including a sparse gwt-core.jar.

That's the plan, but GWT isn't yet mavenized ;-)

(I intend to work on it this summer)

 

Anyone who doesn't want the bloated omni-jar can take the sparse-jar and declare dependencies manually, then export only what they need to the server,

while everyone else can just carry on like normal.

I'm not sure the uber-jars should be deployed as Maven artifacts. If you're using Maven, it doesn't really matter whether it's a single JAR or a set of JARs from transitive dependencies, and uber-jars are more harmful than not. The uber-jars should IMO only be packaged within the downloadable GWT SDK.

When (if?) GWT will be mavenized, then the GWT SDK should be built from the deployed Maven artifacts (using the maven-shade-plugin and maven-assembly-plugin); contrary to what's done today of extracting the Maven artifacts out of the GWT SDK.

 

In maven, what's in gwt-user now would become gwt-core, and replace gwt-user with a pom stub that just bundles up the omni gwt-user.jar.

gwt-core would be a kernel module representing c.g.g.core.Core + all the .gwt.xml and interfaces / utilities needed to build the gwt environment;

the maven build for core could still suck in all the required dependencies to run with packaging pom, and just export a jar/gwtar in release stage.

I'm not sure I understand. To me, gwt-user in Maven, if/when the user libraries are modularized, should become a "grouping dependency", as described here http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps

 

For IDE / GPE, let it be known that gwt-user is the deprecated way to get up and running quickly,

and gwt-core + jars_you_need is the advanced way to get up to max performance.

Are you suggesting the GWT SDK has gwt-user and all of gwt-core+jars_you_might_need?

or that gwt-core et al. will only be published on Central?

I'd favor the latter, it would relegate the GWT SDK to a "quick start" bundle for people who want to quickly try out GWT, or a bundle providing uber-jars for people who don't use a build system with dependency resolution (Maven/Gradle/Ivy/etc.) and don't want to download all the smaller JARs one by one from Central (which would be fine for small or legacy projects; new+big projects are almost all using a build system with dependency resolution built-in, so there's no need providing all those small JARs in a downloadable zip bundle); and it would make the GWT SDK much smaller.

It may be more work to maintain, and gwt-user.jar updates can only be issued with a stable set of dependencies bundled,

but at least the component projects and artifacts can be updated independently in maven central, and then by hand in user classpath;

that way, if there is an update to request factory or elemental or widgetFrameworkXYZ, the sub-modules can release updates without waiting on a version release.

I'm really not sure this is a good thing.

1. AFAIK, gwtar files are currently dependent upon the version of the GWT Compiler that produced them, so you shouldn't generally pick components with different versions (just like currently you should not use a gwt-user, gwt-dev and gwt-servlet from different versions)

2. "user" components are likely to depend on new features of the "dev" parts (mostly the GWT Compiler)

In the end, it can quickly become a mess.

If there are "urgent" fixes in, say, elemental

Request Factory is kind of a different beast, as it has a stable protocol, so you can very well have servers and clients running different versions. What matters then is that you use the "requestfactory-gwt" artifact with the same version as the other GWT components.

But well, that's a discussion for post-2.5 anyway.