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.bro...@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). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
