Should we remove the included GWT SDKs from the plugin?

[keinhaar]

Why we maybe should remove the SDKs.

• I think nobody is using all of the included SDKs at once
• GWT 2.10 is missing
• Only the main Versions are included. GWT 2.8.2 for example is missing.
• Increases the download time of the plugin
• Increases the build time
• Increases the disk consumption
• It's easy to specify your currently used version

Maybe somebody could create an Popup that asks for a GWT version if no SDK is configured.

Any thoughts on this?

[niloc132]

Agreed.

Long term we could use this to encourage developers to use maven or gradle as well, rather than specific downloaded SDK directories.

It would also be nice to stop checking in copies of GWT directly, but instead use the maven tooling to fetch what we need to test and build.

Also, the GWT project historically doesn't backport fixes to old versions, so only the current version (2.10.0 as you pointed out) is supported anyway - following this reasoning, we should never have more than one or maybe two versions supported at a time.

That said, we've had some recent pushback about it being difficult to set up a new project - keeping the current GWT version rather than forcing setup of the desired SDK might be helpful.

[protoism]

@keinhaar I don't get the point. Plugin download is opt-in, you're not forced to download an SDK. Let's suppose you don't download any SDK with the plugin, nor any stand-alone SDK, what should happen?

• Maven / Gradle care about classpath, and Plugin simply finds the SDK in the classpath
• The plugin exposes a "virtual" container, which downloads the SDK when needed
• Other options I did not think of

[niloc132]

On the other hand, many users just check all and install. And the install size is huge on the server, to include a new copy of every old version of GWT on each update. Eventually that will add up.

[keinhaar]

@protoism There are already some Warnings about a missing SDK from the Plugin

• On the Console: "GWT SDK not installed."
• In the Error Log: "GWT SDK not found"
• In the Problems View: "The project XXXX does not have any GWT SDKs on it's build path"
• In the Problems View: "Unbound classpath container"...

We could create a compound update site, so the SDK Plugins could be separated. That would still allow the users to install the SDK (also different versions) together with the plugin, but the SDKs would not be inside the gwt plugin itself. Each SDK version would be only one time on the server. The same way could be used to reintegrate SDBG with an always current version. I don't know if the Marketplace accepts compound update sites, but i don't see any reason why it should not. By the way, what is the Update Site URL used for the Marketplace entry?

Or we could do as @niloc132 said, and add just the latest SDK. But that does not solve the problem completely, because then we would need to update the plugin, if a new SDK version is released.

[protoism]

@keinhaar so you don't want to overhaul the plugin architecture,... It's just about SDK distribution. @niloc132 is pushing a bit more: the "classpath", in a maven/gradle build already contains an SDK, so there is really no need for an eclipse delivered SDK

Here what a maven project produces

Summarizing:

• The plugin can contribute with a GWT container, which is a classpath contributor. This container is only needed by non maven / gradle projects
• The plugin still needs an SDK, which is more than the bunch of GWT jars already in the classpath,

My doubt is: what is the SDK (not the GWT container) used for?

[keinhaar]

so you don't want to overhaul the plugin architecture,... It's just about SDK distribution.

Yes. At my company we have the SDK separately downloaded (version 2.10), and don't need the packaged version, but for beginners, it may be easier if they could just start by installing the plugin and the SDK at once. And yes maven does download the SDK anyway, but not every project is maven based.

[protoism]

@keinhaar do you feel like contributing a PR for this? I'm afraid that it won't be that easy... @niloc132 you're the maven guru, here. Do we need to create a new repo, or it makes sense to have different maven targets?

[niloc132]

@niloc132 you're the maven guru, here. Do we need to create a new repo, or it makes sense to have different maven targets?

I'm afraid I don't understand what you're asking me - we already have a gwt.version property that can in theory be set to different versions of GWT to test with (but shouldn't change build output as far as I'm aware).

The plugin still needs an SDK, which is more than the bunch of GWT jars already in the classpath,

What else is the SDK if not just the jars? Something that isn't shipped in GWT's jars (user, servlet, dev), but needed by the plugin itself? Or are you saying that the plugin can't function without the jars, and so the jars/SDK are needed for more than the project classpath?

[protoism]

I'm afraid I don't understand what you're asking me - we already have a gwt.version property that can in theory be set to different versions of GWT to test with (but shouldn't change build output as far as I'm aware).

@keinhaar proposes to distribute separately plugin and SDK. Currently the build produces both. We need two builds, one for the plugin, one for the SDK. How would you organize these two builds?

What else is the SDK if not just the jars? Something that isn't shipped in GWT's jars (user, servlet, dev), but needed by the plugin itself? Or are you saying that the plugin can't function without the jars, and so the jars/SDK are needed for more than the project classpath?

I send you an image of the contentf of an SDK. There's docs, scripts, requestfactory, i18nCreator script... DTD, A lot of things which the plugin might be using, and which I guess are not available to maven.

[keinhaar]

@niloc132 @protoism I've managed to create a project, that builds only the SDK plugins and features. I've uploaded the resulting update site here: http://www.keeitsi.com/software/eclipse-plugins/gwt-sdk-plugins I added it to my composite update site (http://www.keeitsi.com/software/eclipse-plugins), and now i can install gwt-plugin, sdbg, and sdks, all at once. Also added SDK 2.10.0. Because the SDK Plugins do not depend on anything else, there is no need to have them rebuild if new gwt-eclipse-plugin versions are build.

So it seems to work.

Should we then create a new sub project? gwt-sdk-plugins?

[protoism]

Hi all, I like the idea of splitting plugin / sdk. I wonder if integration tests require a plugin, but I doubt it.

@niloc132 any opinion about it @keinhaar are you willing to contribute patches to the plugin?

We could even think of having an "aggregator" repo just for the composite site, and separate repos for gwt plugin / SDK / SDBG.

[keinhaar]

@protoism, @niloc132 I've created a separate sdk project here as a starting point:

https://github.com/keinhaar/gwt-sdk-plugins

It builds the 2.7 up to the 2.10 SDKs. You may review it there, but it should better be a separate project here: https://github.com/gwt-plugins.

Because of my limited maven knowledge, i've just stripped down the gwt-eclipse-plugin project until it only build the SDKs, and added 2.10 support.

I don't see any need for an aggregator repo, because the composite site consists of only 2 files with static references to the real repos.

I wonder if integration tests require a plugin, but I doubt it. I've removed the sdk builds from my gwt-eclipse-plugin branch, and it builds just fine. Tests are running.

[protoism]

Great job. @keinhaar

I tried to look on your repo for the gwt plugin branch without gwt sdk, but couldn't find it. Can you just verify, perhaps you already did, that mvn verify (integration tests) works?