search

gwt-plugins / gwt-eclipse-plugin

GWT Eclipse Plugin Documentation
http://gwt-plugins.github.io/documentation/
Eclipse Public License 1.0
113 stars 48 forks source link

Should we remove the included GWT SDKs from the plugin? #458

Open keinhaar opened 1 year ago

keinhaar commented 1 year ago

Why we maybe should remove the SDKs.

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

Any thoughts on this?

niloc132 commented 1 year ago

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 commented 1 year ago

@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?

niloc132 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

@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 image

Summarizing:

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

keinhaar commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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.

image

keinhaar commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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?

protoism commented 2 months ago

I think it's time to revive this ticket. @keinhaar, do you feel like contributing a PR?

keinhaar commented 2 months ago

We will need a new Project, but yes, i will look at my prototype and start right after 4.1 is out.

keinhaar commented 1 month ago

@protoism I started a new project "gwt-sdk-plugins" as part of gwt-plugins. I've added my prototype from the last year, but updated it with removing SDK 2.7, and adding 2.11 as you did it here. The update repository builds, and SDKs can be installed to eclipse (testet 2024-06). Currently there is no code signing or automated build pipeline. Please check if you can build too.