4

Lets assume that I have a fairly large organization of Spring Tool Suite (STS) users. Those users are using some out-of-date version of STS (e.g. 3.1.0).

What is the recommended and least painful way to upgrade those users to latest STS+Eclipse?

I basically see two main approaches.

Use Eclipse built-in P2 update mechanism to update STS+Eclipse from within Eclipse/STS. Is this an officially supported way? Assuming that I stick to the "officially released" STS+Eclipse version combinations of STS (e.g STS 3.1.0 + Eclipse 3.8.0, STS 3.1.0 + Eclipse 4.2.0, STS 3.2.0 + Eclipse 3.8.2, STS 3.2.0 + Eclipse 4.2.2, etc).

This has the benefit of keeping all already installed plugins and settings.

Install a fresh copy of STS and import settings from old STS installation. Users would need to re-install plugins.

I prefer the first option, but before investing significant time to make this process as seamless as possible to the users, I would like to confirm that this is "officially supported".

And, how dependent is STS on underlying Eclipse version? For example, I have installed STS 3.1.0 on top of Eclipse 3.8.0 -- can I assume that upgrading underlying Eclipse version to 3.8.1 or 3.8.2 will not cause any compatibility issues? Or should I stick to the combinations listed on the STS download page (meaning that I should upgrade also STS to 3.2.0)?

UPDATE

I looked into STS update sites for different Eclipse versions, to see which STS versions are available for each (current latest STS version is 3.6.4). I found out that:

(I searched for "org.springsource.sts.ide" IU/plugin/bundle ID)

This seems to imply that by using a correct update site, it should be possible to upgrade STS to quite recent version even if underlying Eclipse platform version is quite old -- resulting in Eclipse+STS combinations for which there is no full-download-package available.

Neeme Praks
  • 8,956
  • 5
  • 47
  • 47

1 Answers1

6

This is a more complicated question, so let me explain my thoughts on this in more detail.

First, there is the update site compatibility question. For each new release of STS, we usually provide between two and three different update sites:

  • one for the latest Eclipse release (Eclipse 4.4 at the moment)
  • one for the previous Eclipse release (Eclipse 4.3 at the moment)
  • maybe one for the upcoming Eclipse release (Eclipse 4.5 at the moment)

This is the reason why do don't see updates for the 3.7 - 4.2 based update sites anymore (in your list above). We continued to provide 3.7-4.2 compatible versions for so long due to the migration of Eclipse to the new 4.x stream (which caused some trouble in the past). But this "extended period of supporting older Eclipse versions" is over. From now on, we are back to our strategy outlined above.

You can use those update sites to update an existing STS installation to the next version of STS. Those updates don't change the underlying major Eclipse version automatically. This caused too much hassle in the past. And this is my recommendation as well: if you would like to continue to use the same underlying Eclipse version, you can use those update sites (and the "Check for Updates" in the help menu) to update STS to the next version of the STS components.

If you would like to upgrade to a new version of Eclipse, I recommend to download a fresh copy of STS for this newer Eclipse version and migrate the preferences (as you described). The workspaces are usually compatible, so you don't need to setup a new workspace.

But this requires to re-install third-party plugins that you installed previously in your STS installation again. This is usually a quite tedious and time-consuming task. Therefore I am using a script that automates this:

https://gist.github.com/martinlippert/5155155

This is an example of a script that I use (on my OSX machine) to install a bunch of additional features from the listed update sites in a batch automatically. You might need to modify this to get your third-party features and update sites correctly, and maybe modify it a bit to make it work on Windows (never tried that), but the basic idea should work for all the various platforms (in the end it runs a JVM with command-line args).

Hope this explains the various strategies and helps you a bit. If you have further questions, I am happy to help!

Cheers!

Martin Lippert
  • 5,988
  • 1
  • 15
  • 18
  • 1
    Thank you for a thorough answer! Quick comment about re-installing 3rd-party plugins, there is an alternative solution as written in http://stackoverflow.com/a/11264964/74694 (I haven't tried it myself so I do not know how well it works). – Neeme Praks Apr 08 '15 at 14:20
  • 2
    [This answer](http://stackoverflow.com/a/18120071/606662) worked well for me: In short: Use the Eclipse migration feature: File -> Import... -> Install / From existing installation. – Markus Pscheidt Mar 29 '16 at 09:26