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