Eclipse Mars.2 (4.5.2, formerly known as Mars SR2)
The default STS distribution is now based on the recently released Eclipse Mars.2 release.
Early Access Builds for STS on Eclipse Neon available
There are early-access builds of STS 3.7.3 available that are built on top of the latest Eclipse Neon milestone (M5 in this case).
Highlights from this early-access builds on Eclipse Neon include substring code completion for Java content assist, word-wrap in text editors, commands/shortcuts/pinch gestures to zoom into text editors (especially useful when giving presentations), and more. Please find additional details in the Eclipse Neon Platform New and Noteworthy.
Pivotal tc Server updated to 3.1.3.SR1
The latest Pivotal tc Server release 3.1.3.SR1 is now included in the STS distribution bundle.
In the past the boot dashboard listed Spring Boot projects from your workspace and allowed you to pick a "blessed" launch config to use. This launch config was used when starting/debugging/stopping the app from the boot dashboard. However there was no way to deal with multiple running instances or variants of a project. This has changed dramatically in the new version of the Spring Boot dashboard.
In the latest incarnation the Spring Boot dashboard directly supports multiple launch configurations per project. If you already have multiple launch configs for a project, they automatically show up in the boot dashboard as items of the project.
All the existing features of the boot dashboard are now available for those individual launch configs. You can start/debug/stop them, jump to the associated console view, open a browser window for that running application, set a default path per launch config (in case you want to have different default path settings for your launch configs), tag them, and so on.
The project item in the dashboard becomes a shortcut for all those launch configs. It provides you a quick summary of the individual launch configs and allows you to execute bulk actions on them, like start or stop them all.
To reduce clutter and to maintain the simplicity of the UI for the common case where there's just one launch configuration per-project, a Hide Solitary Launch Configurations filter is applied to the Dashboard by default, but you can disable this filter if you wish:
This filter hides launch configurations from the tree, unless there is more than one for a given project. Disabling the filter will show all Configs:
A single configuration is created automatically when an app is launched. To help you deal with multiple launch configs for a project, the context menu got new actions. Those allow you to quickly open a launch config editor, to duplicate an existing launch config, or to delete one. And by the way: the duplicate action is smart enough to NOT use the same JMX port over and over again, but chooses a new one for each launch configs so that they can truly run in parallel.
Tip: If you want to run multple instances of a single local app simultaneously (e.g. you want to
bind multiple local instances of a service via Eureka), you can set the property
to let spring-boot pick a port dynamically (otherwise all but one of your launches will fail because the
port is already bound).
Nevertheless there might be some launch configs in your workspace that you find annoying to show up in the boot dashboard. For that case the Spring Boot launch configs got an option to be hidden from the boot dashboard. Switch that on and that launch config will never show up in the boot dashboard.
Cloud Foundry Manifest files are a configuration file used when deploying apps to Cloud Foundry. In the past the boot dashboard used a manifest.yml file from the project (if it existed) to deploy an app to Cloud Foundry. But changes to the running app on Cloud Foundry would not find their way back into the IDE and deploying different variants of the same app to Cloud Foundry was cumbersome. This changes in the new version of the Spring Boot dashboard. Cloud Foundry Manifest YAML files are becoming a first-class citizen when working with Spring Boot apps in the boot dashboard.
The first thing that you will notice is: when you deploy an app in the dashboard to a Cloud Foundry section, new dialog opens to let you select the manifest file to be used:
This allows you to pick a manifest file from your project or anywhere else in the workspace. And the boot dashboard remembers your decision. It will use the same manifest file the next time you re-deploy the app (for example when deploying and restarting the app with changes you made to the code in your IDE).
This explicit support for manifest files also allows you to use various manifest files in your project, for example one for each CF instance you would like to to deploy on, an additional one for a specific variant of the app, a dev version, etc. You can deploy the same project multiple times to Cloud Foundry using different manifest files.
In case you don't remember which manifest file you chose for which app or want to change that setting, you can use the "Select Manifest" action from the context menu. It will open the same dialog and show you which manifest file you chose last time for that application.
But what happens if you want to deploy your app without a having to create or keep a manifest file in your project? The dialog provides the "manual mode" option for this use case. Switch to the "manual mode" and you will be able to edit a temporary manifest file directly within the dialog.
The default content of the temporary manifest file will be generated for you, so no need to write everything up yourself. But you can change the generated content as well as add additional properties. This gives you the option to exactly specify how the project should be deployed to Cloud Foundry.
You will also notice that all the nice features for editing Cloud Foundry Manifest files (see below), like content-assist, validations, and hover help are available in this dialog, too.
By the way: this direct editing of the manifest file content also works if you select an existing manifest file. You can quickly change the content of that file directly from within the dialog. No need to close the dialog, open the file in an editor, make and save changes, and trigger the deploy action again. Just edit the content directly within the dialog. It will save the changes in the file for you.
The boot dashboard will use the content of the selected manifest file to deploy the application to Cloud Foundry - each time it deploys or updates the app. What happens if you changed the configuration of the application on Cloud Foundry in the meantime via the CF CLI or the web console of Cloud Foundry?
The Spring Boot Dashboard will now check for those changes each time it updates the application on Cloud Foundry. If it identifies a difference in the configuration, it will prompt you with a diff and merge dialog.
This powerful dialog visualizes the differences that exist between the selected manifest file and the configuration of the application on Cloud Foundry. And it allows you to merge those updates into the local manifest file with a single click.
You can also decide to not merge those changes into your manifest file and use the manifest file as it is to deploy the app or to forget the manifest file altogether and continue to use the configuration as it exists on Cloud Foundry. In that case, the boot dashboard will remember that decision and not use the manifest file anymore when updating the application.
Cloud Foundry Manifest files can contain configuration information for multiple applications in one file. The boot dashboard recognizes this situation and lets you pick the application section from the manifest file that you would like to use when deploying the app. The mechanics behind that also support multiple applications when showing the diff/merge dialog.
Known limitation: the "inherit" attribute is not yet fully supported for Cloud Foundry Manifest files. If you use the "inherit" attribute, the inherited attributes are not yet taken into account when deploying the file nor are they when doing a diff and merge of manifest files and config changes on Cloud Foundry.
Spring Boot Dashboard: new actions to deploy apps
You can now deploy apps directly in run or debug mode via new actions in the context menu. Select the apps you want to deploy to a Cloud Foundry instance in the local section of the boot dashboard, go to the context menu and take the "Deploy and Run On...". The submenu allows you to directly pick the CF target you would like to deploy the app to.
Cloud Foundry sections in the boot dashboard now visualize service instances with their name and selected properties of that service. Double-clicking on that service takes you directly to the management web UI of that service (by opening a web browser for the management URL).
Spring Boot Dashboard: improved connect/disconnect/activity handling for Cloud Foundry sections
Cloud Foundry sections in the boot dashboard now directly visualize their connected/disconnected status and you can manually connect and disconnect those connections to Cloud Foundry. The connected/disconnected state will be remembered the next time you start up STS. A disconnected Cloud Foundry section will not be connected automatically at next startup. This is particulary useful if you have Cloud Foundry targets defined in the boot dashboard that you don't use all the time.
In addition to that connection problems will be marked as an error on those Cloud Foundry sections, with more detailed information showing up when you hover over the section.
More details about background activity will also be visualized in the Cloud Foundry section, so that you can directly see what is going on when the boot dashboard tries to connect to a Cloud Foundry instance.
In case you have already organized your projects in your workspace using working sets, you can directly filter for those working sets in the boot dashboard. There is no need to add additional tags to the apps. Just type in a part of the working set name into the filter box and the boot dashboard will show those apps only.
Spring Boot Dashboard: visualize request mappings from apps on CF
The request mappings property tab now works for apps that are running on CF as well.
Spring Boot Dashboard: directly select the default path
The boot dashboard allows you to directly pick the default path for a local app (or an app on Cloud Foundry) in the request mappings property tab. Just select the request mapping you would like to use as default for the app and select "Make Default" from the context menu.
Spring Boot Dashboard: host in properties view now a hyperlink
The host field on the properties view has turned into a hyperlink that lets you jump to the app URL directly from the properties view.
STS 3.7.3 adds support for editing
Cloud Foundry Deployment Manifests. Double clicking a file
manifest.yml will automatically open our new Cloud Foundry Manifest Editor.
Tip: If your file has a slightly different name, the dedicated editor won't open automatically on the first double-click. So use the Open With context menu to choose it explicitly and STS will remember your choice for future double clicks:
The editor understands the expected structure and checks the manifest for problems as you type:
The editor provides content assist:
The editor has embedded documentation for all supported properties. This documentation is accessible from the content assist (see screenshot above) or by hovering over a property with the mouse:
Both the Yaml and Properties Editors now support property deprecation. Deprecated properties are marked as warnings in each editor:
Deprecated properties are still suggested by the content assist engine but are clearly marked as deprecated and are moved to the bottom of the list:
Both the Yaml amd Properties Editor now recognize properties of type
org.springframework.util.MimeType as special cases and provide
helpful content assist for them:
Spring Boot 1.3 defines an extension of its metadata format that allows providing hints to the IDE on how to provide content assist for specific properties. STS now parses this extended format and provides meaninful content assist for a subset of it (more complete support to follow in the next release). Wherever we added support, it works in both the yml and properties editor. STS 3.7.3 supports:
The logger-name Value Provider which is associated with the Mapping Keys of property
in Spring Boot 1.3:
The Edit Starters wizard is accessible by right-clicking a Maven project's
from menu Spring >> Edit Starters. This wizard provides a
way to change the project's dependencies, adding (or removing) starters that you might have forgotten to choose initially
when creating your project with the New Spring Starter Project Wizard.
The old implementation only provided an unorganized, long and incomplete list of dependencies. This has been replaced with a much nicer implementation that completely mirrors the New Spring Starter wizard's layout and contents:
The new implementation provides significant improvements over the old one:
ANSI coloring in console
STS 3.7.3 comes with the ANSI Escape in Console plugin installed by default and enables the Spring Boot option to produce ANSI colored console output automatically in case this plugin is installed and active.
SilentExitExceptions ignored by default
When running a Spring Boot app in debug mode (while having the Boot Devtools on the classpath), the debugger usually stops automatically at a SilentExitException (if you have "stop on uncaught exceptions" enabled). Since this can be really annoying, we configure the debugger for Spring Boot apps automatically to ignore exactly that exception.
A new milestone version of Cloud Foundry Tools (CFT) 1.0.M3 is included in 3.7.3 and includes many changes that occurred after CFT moved to Eclipse Foundation and became an Eclipse project. This replaces the old Cloud Foundry Eclipse 1.8.3 tools. If you are downloading a full copy of 3.7.3, CFT is already included.
Further information on the tools can be found at: Cloud Foundry Tools
Changes in M3 include:
If BuildShip does not yet meet your needs, you can still continue to use STS Gradle Integration for some time to come. However, STS Gradle Integration is in minimal maintenance mode. There will be no more new features and limited bugfixes. So please consider filing a BuildShip Bug Report detailing what is stopping you from making the switch.
Some known limitations of BuildShip that may affect STS users in particular are:
warpackaging can be created using our wizards, such projects are not officialy supported and consequently will not be correctly configured by BuildShip.
@ConfigurationPropertiesannotations in your code, this means that these annotations will not be processed as part of Eclipse workspace builds unless you manually configure JDT APT.
Since the end of March Pivotal is no longer sponsoring the Groovy and Grails projects (as described here). Therefore we don't ship new versions of the GGTS bundle anymore. Groovy-Eclipse remains on the dashboard and was fully updated for Eclipse 4.5. It was *not* updated for Eclipse 4.5.1 so beware that if you install Groovy-Eclipse you will be downgrading your Java compiler and missing all the JDT related fixes that went into 4.5.1.
Here is a full list of resolved bugs and enhancement requests for 3.7.3:
Download STS: https://spring.io/tools/sts/all
STS Issue tracker: https://issuetracker.springsource.com/browse/STS
The Spring Boot Dashboards ngrok tunnel feature doesn't work yet with remote service registries from Spring Cloud Services. Instead it works with self-deployed Eureka service registry apps on CF only (as described here). We are working on enhancing the ngrok tunnel feature to directly support Spring Cloud Services in the near future. In the meantime we published a tech note that describes how to setup ngrok tunneling in combination with SCS manually.
Sometimes Maven projects show up with a red error (talking about a duplicate lifecycle mapping conflict) after upgrading STS from 3.6.x to the latest 3.7.2 version. In this case, please update the Maven support for Eclipse/STS to the latest version, as described here: STS-4236.
Sometimes after updating an existing STS 3.7.0 installation to 3.7.1 an error dialog pops up and STS doesn't start. This is a known but not yet solved problem. If you come across this issue, please press "OK" on the dialog and restart STS. It will open up fine, including all the updated components.
If you have used a pre-release version of Eclipse Mars or STS, the embedded Eclipse Oomph technology created a cache of p2 repositores in your home directory. This cached p2 data can cause issues when using STS 3.7.0 or Eclipse Mars. The error message looks like STS/Eclipse fails to read information from the main Eclipse Mars p2 repository.
In case you encounter this error, please stop Eclipse/STS, go to your home directory, delete "~/.eclipse/org.eclipse.oomph.p2", and restart Eclipse/STS. The related Eclipse bug is: Bug 470912.
Spring Boot 1.2.1 configuration processor does not work correctly when executed from Eclipse's incremental build. This issue is fixed in Spring Boot 1.2.2. This only affects 'live' metadata generated from your own source code, not the metadata that is packaged inside spring-boot jars themselves. So you can still use older versions of Boot, but the 'live metadata' updates will not be accurate. See Spring Boot issue GH-2313 for details.
When running STS on top of a JDK7, the new dashboard looks a bit blurry when using a HiRes (Retina) display, for example on a Retina MacBook Pro. This is due to the underlying browser technology that is used to display the dashboard content and that is coming from JavaFX. The JavaFX version that ships with JDK7 doesn't support retina displays. The solution for this is to run STS on top of a JDK8 build. The JavaFX version that comes with JDK8 supports retina displays.
The JavaFX-based main STS dashboard doesn't work when running STS on top of an early-access version of JDK9. As a workaround run STS on a JDK8 or switch the dashboard back to the old (non-JavaFX-based) version via the preferences.
STS requires a JDK to run on top of. Nevertheless the native launcher component might pick up a JRE automatically if you don't specify which JDK to run STS on top of. To avoid this, you can specify the JDK in the sts.ini file that comes with your STS installation. Add a line at the beginning "-vm" and an additional line below that which points to the "javaw" executable of the JDK on your machine.
Eclipse 4.5, upon which STS and GGTS are based, is the first Eclipse release where GTK3 is the default for the SWT widget library. There are some issues with this still:
You may also experience other UI rendering glitches. If you exprience any of these problems you can avoid them by forcing SWT to switch back to using GTK2. Just set the environment variable "SWT_GTK3=0" before launching STS or GGTS.