Blocking RC1: Fold gwt-codeserver into gwt-dev

[Daniel Kurka]

Hi all,

right now GWT builds with RC1 are failing in Eclipse with GPE since the gwt-codeserver.jar is not on the build path. The next GPE release (with changes that fix this) is still a long way out. In order to not be blocking on this I propose we fold gwt-codeserver.jar into gwt-dev.jar.

This way people do not have to deal with the extra complexity of adding yet another entry into the classpath and all the old tools just work.

If I do not hear any objections as of today, I go ahead and change the OS build (I could need some help here). So please speak up.

-Daniel

[Brandon Donnelson]

I like this idea of moving codeserver into core. I think this would make it easier. 

-Brandon

[Thomas Broyer]

Fine for me.

Do you intend to move the sources or just merge the JARs during dist-dev/dist?

[Daniel Kurka]

I think moving sources right now is too risky and too much work we should just merge the jars in dist.

On Tue, Oct 28, 2014 at 8:02 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Fine for me.

Do you intend to move the sources or just merge the JARs during dist-dev/dist?

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Brian Slesinsky]

Yes, merging the jars should be fine as a short-term fix.

Codeserver should be built as a separate library to enforce that there are no circular dependencies. (We already have one for DevMode -superDevMode but that should be fixed by splitting out DevMode; it doesn't belong in the same library as the compiler.)

Long term, we will also want to split gwt-user into multiple jars. It seems like we should either give plugins a way to set up the classpath properly without hard-coding exactly which jars to use, or else plan on building the traditional all-in-one jars when creating the distribution.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiq25ZHfMsk4cDrnGNE54Wfhvv%2BNEB0YSSZenxyNEv-5Jw%40mail.gmail.com.

[Thomas Broyer]

On Tuesday, October 28, 2014 9:09:47 PM UTC+1, Brian Slesinsky wrote:

Yes, merging the jars should be fine as a short-term fix.

Just though that it could break some plugins out there that would expect to find a gwt-codeserver 2.7.0 in Maven Central.

For the gwt-maven-plugin, we release a new version for each new version of GWT, so we can adapt.

It's a different story for the gwt-gradle-plugin though (it already has to handle the case where gwt-codeserver doesn't exist for pre-2.5 versions of GWT, it'll have to be updated to support GWT 2.7): https://github.com/steffenschaefer/gwt-gradle-plugin/blob/4ecc5b8c022ceaf16b600c4ebaabcf703bd54fd7/gwt-gradle-plugin/src/main/java/de/richsource/gradle/plugins/gwt/GwtBasePlugin.java#L142-L145

Or maybe, for 2.7 we could deploy a dummy gwt-codeserver JAR? (I hate such hacks, but it would give some time for tools out there to adapt; note that for gwt-gradle-plugin, there's a "workaround": just declare your GWT dependencies explicitly rather than letting the plugin do it "automagically" for you)

 

Codeserver should be built as a separate library to enforce that there are no circular dependencies. (We already have one for DevMode -superDevMode but that should be fixed by splitting out DevMode; it doesn't belong in the same library as the compiler.)

Long term, we will also want to split gwt-user into multiple jars. It seems like we should either give plugins a way to set up the classpath properly without hard-coding exactly which jars to use, or else plan on building the traditional all-in-one jars when creating the distribution.

This is going to be tricky.

We want to externalize dependencies to make it easier to handle conflicts with other libs (e.g. using a newer version of Guava) so the "all-in-one jar" won't work. It's already an issue for some projects (e.g. Gerrit) that don't use the embedded Jetty and don't use GWTTestCase (so they have absolutely no direct dependency on the version of Jetty we bundle) but want to use a newer version of Jetty (through the extension point in DevMode; the same that's used by GAE to plug its own server). BTW, for this use-case, having SuperDevMode being "embeddable" in a webapp rather than running side-by-side would probably help (Gerrit maintainers would rather have a single process running; maybe they're wrong striving for that)

We could use all-in-one jars in the SDK to make classpath management easier, but then IDE plugins would have to do things differently for projects that use the SDK vs. projects that use "manage dependencies" (Maven, Gradle, Ivy, etc.) Well, they already have to do things differently, so maybe it's a false issue, but still, we probably want to ask IDE plugin maintainers before making a choice.

For "managed dependencies" builds (and some others; e.g. Gerrit with Buck), we'd rather want many small libs so you can cherry-pick only the ones you need, and leave out transitive dependencies that you don't need (e.g. no dependency on HtmlUnit if you don't use GWTTestCase; it could even be optional if you only run your tests in real browsers through Selenium/WebDriver, or with PhantomJS). IDE and build-tools plugins could then quite easily resolve transitive dependencies of the JARs they need (this is what I recently added to the gwt-maven-plugin, which previously assumed GWT JARs had no external dependencies). I believe all builds would benefit from smaller JARs, even if creating your Ant build.xml (for example) and then maintaining it when updating GWT would be harder than it is today (but if you decide to manage your dependencies manually, you know what you sign up for, and the added flexibility of small JARs with external dependencies is probably a good thing in the long run)

I don't have an answer for the IDE plugins (when using a downloaded SDK ZIP), but for other tools I think smaller JARs are better, and those tools are built around generating a classpath out of a description of transitive dependencies.

For humans (managing dependencies manually), we could probably generate a dependency graph quite easily (the hard part would be to make it straightforward for the people who will update the docs at each release), to help them pick the required and appropriate dependencies for their build.

On Tue Oct 28 2014 at 12:03:25 PM 'Daniel Kurka' via GWT Contributors <google-web-toolkit-contri...@googlegroups.com> wrote:

I think moving sources right now is too risky and too much work we should just merge the jars in dist.

On Tue, Oct 28, 2014 at 8:02 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Fine for me.

Do you intend to move the sources or just merge the JARs during dist-dev/dist?

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2649c79a-bc32-472e-9410-81401fe73de1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Brian Slesinsky]

It looks like the gwt-codeserver jar will still exist, but the same classes will also be in gwt-dev.jar. So it's ugly but should be backward compatible?

- Brian

[Brandon Donnelson]

This is a bit tricker to deal with in the GPE source than I imagined. 

The current GPE patch is looking ready to go, but it validates checking for CodeServer in the classpath if SDM is turned on. Although it adds gwt-codeserver.jar to the GWT_CONTAINER resolved classpath. If the gwt-codeserver.jar stays int the gwt-sdk moving forward this isn't an issue, although, if it doesn't the consistency between 2.5 to 2.7 will be different. This creates a challenge with testing in GPE because now that I've added validation, I have to change the unit tests around and it only has one GWT_ROOT, based on the latest sdk, which means the older SDK would need gwt-codeserver.jar and the newer won't. 

I think GPE plugin update could release first of next week, this could fix the need to fold it into gwt-dev and keep things simpler as it is now. I think I'm going to hold off on the GPE fold into gwt-dev changes until next week and see how the release looks. 

Brandon

[Thomas Broyer]

So, what does the latest GPE do now? Can we revert the change and go back to what we had in 2.6 (and beta1) with SDM in its own gwt-codeserver.jar and not in gwt-dev.jar?

(and what about IntelliJ IDEA? I must confess I haven't done any GWT dev –even bug repro checks– for a few weeks, and haven't actually launched DevMode from Eclipse for a while – last things I did were about Maven only)

[Brandon Donnelson]

GPE uses gwt-codeserver.jar in the GWT_CONTAINER and it asks the user to add it to the classpath if it doesn't exist and super dev mode is on. I think idea uses the gwt-codeserver.jar in the runtime classpath but I haven't confirmed.