>
> 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.
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.
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.
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.
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.
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.
> 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
