On Thu, May 31, 2012 at 12:07 PM, Thomas Broyer <[email protected]> wrote:

> 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 <[email protected]>
> 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).
>

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
>

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

Reply via email to