Spring Tool Suite 3.9.9: New and Noteworthy
Updates and New/Enhanced Features
Eclipse 2019-06 (4.12)
The default STS distribution is now based on the recently released Eclipse 2019-06 (4.12) release, including built-in support for Java12. Details about the Eclipse release can be found here: Eclipse 2019-06.
Project-related XSD namespace lookup prefers https now
The internal mechanism to lookup XSD files for Spring namespaces from the project classpath can now deal correctly with https-defined XSD locations in your Spring config files. It mimics the same behavior than the one implemented in the core Spring Framework itself and is therefore compatible with spring.schemas files that use http as well as https for the schema location.
Added user preference to prefer https for Spring namespaces
In order to avoid security risks when using http URLs for namespace location defintions, you can now set the default to https when adding namespaces to your Spring config files using the preferences. So when having that option enabled, the tooling with automatically insert https locations for your namespaces instead of http, independent of the way those are defined in the spring.schemas file.
Important Changes and Fixes
- improvement: startup performance of CF manifest language server improved significantly
- improvement: CF manifest editor now supports anchors and references
- improvement: remote devtools integration for boot dashboard now uses process healthcheck instead of none
- improvement: restarting an app on CF in the boot dashboard checks for dirty manifest editor
- fixed: empty property values in custom properties not set when launching boot apps
- fixed: pushing app to CF with health-check-type set to http throws exception
- fixed: focus in Spring Initializr wiazrd is lost when switching wizard pages forth and back
- fixed: CF manifest editor supports manifest files with number of instances set to zero
- fixed: preference to configure remote boot apps for Spring Boot language server (part of STS4) moved to STS4
- fixed: content-assist in CF manifest editor showed error when it should not
- fixed: strange exceptions being logged when deleting apps on CF that had SSH tunnels active
- fixed: various painting issues with icons on retina displays when using Eclipse 4.12 as base platform
- fixed: quickly restarting apps in boot dashboard multiple times could cause failures
- fixed: Tags in yaml files with dollar signs throw IllegalGroupReference
- fixed: Double click on any Live Beans Graph node yields to NullPointerException
- housekeeping: support for Buildship 1.x removed
- housekeeping: separate feature for project-related XML namespace lookup extracted
Issues now tracked on GitHub Issues
Issues around the Spring Tool Suite and the Spring IDE are tracked on GitHub from now on: https://github.com/spring-projects/spring-ide/issues.
Thanks for using the automatic error reporting - retiring it now
We would also like to thank our users for using the automated error reporting that we included since the 3.8.2 release and for sending us all those error reports. We used them to fix issues and improve reliability in this release.
From now on, the can't continue to use the automatic error reporting (due to its infrastructure not being around anymore by the end of March 2019). Therefore we updated the configuration to not send any error report data anymore to those servers.
For existing installations, we are doing two different things:
- We updated the client-side error reporting configuration to not report any errors anymore for our bundles and packages. We stored this updated client-side configuration on the existing server-side infrastructure, so that existing installs were able to update this client-side configuration automatically (on the fly) and stopped reported errors. If you enabled the error reporting in the past, you should have gotten this updated config already and not sending any error reports anymore. This will continue to roll-out to client until the end of March 2019 (as long as the server infrastructure is alive).
- In addition to that if you update to STS 3.9.9, we deleted the client-side error reporting extension altogether, so that nothing happens on the client-side anymore, independent of the configuration that you got from the server infrastructure. This will disable the Spring-tools-specific automated error reporting altogether. If you want to go further, feel free to manually uninstall the Spring IDE AER feature from your installation.
Manual Maven support going to be removed soon
We plan to remove the support for manual Maven projects from STS and Spring IDE in future versions of STS and Spring IDE. The manual maven support was used in the past when projects used Maven, but didn't opt-in to use the direct Maven support in Eclipse via the m2e project. While projects can still decide to not use m2e for their projects, the support for that via additional menu actions in STS will be gone.
Useful Links
Download STS: https://spring.io/tools3/sts/all
Spring Tools Issue tracker: https://github.com/spring-projects/spring-ide/issues
Known issues in this release
Deploying apps to Cloud Foundry via Boot Dashboard does not support new buildpacks attribute yet
The new buildpacks attribute in manifest.yml files is not yet supported when deploying apps via the Spring Boot dashboard within STS. A dialog will pop up and warn you about this limitation in case you run into this situation. As a workaround, you can push your apps via the CF CLI or continue to use the deprecated buildpack attribute.
Deleting Eureka service instances from Boot Dashboard
Deleting certain Eureka service instances, like p-service-registry in Pivotal Web Services, from boot dashboard Cloud Foundry targets may experience problems with timeouts. The same issue may be found when deleting them from Eclipse Tools for Cloud Foundry (CFT). A workaround is to use the cf CLI to delete these service instances.
Running on JDK9/JDK10/JDK11
STS 3.9.9 can run on top of a JDK out-of-the-box. However, please notice that the Maven support in Eclipse/STS runs within the JVM of the IDE and therefore also uses the JDK9/10 runtime. While that isn't necessarily a problem, having Maven modules in your build that aren't compatible with Java 9 might cause your project build to fail in Eclipse/STS.
This is the case, for example, if you use Spring Boot 1.5.x or earlier versions, which uses an older version of the Maven jar plugin, which fails when running on top of a Java 9/10/11 VM. In that case we recommend to configure Eclipse/STS to run on top of a Java 8 runtime (by modifying the eclipse.ini or sts.ini file accordingyly).
Spring Boot dashboard ngrok tunneling feature doesn't support Spring Cloud Services yet
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.
Boot App launched with Thin Jar Launcher hangs during start up
Workaround is open launch configuration for the Boot App. Navigate to Spring Boot tab and enter a boot property into "Override Properties" table. For example server.port and value 8080. Save the launch configuration and re-launch your Boot App.
Silent loss of Functionality on Java 7 or earlier
STS 3.9.9 requires a JDK8/9/10/11 to run on top of. If you are running it with an older JDK this may not be immediatlely apparant, but some of STS functionality will simply be 'absent' because the corresponding plugins are automatically disabled by OSGI because their requirements are not satisfied at runtime. See also below 'Setting the JDK'.
Setting the JDK
STS 3.9.9 requires a JDK8/9/10/11 to run on top of. Nevertheless the native Eclipse launcher component might pick up a JRE or an older JDK 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. Here is a detailed explanation how to configure the JVM in the ini file.