Developer Tools Engineering, Spring Tool Suite Lead
Martin leads the Spring Tool Suite and the Spring IDE projects at Pivotal and works together with the tools team on providing the best developer tools out there for Spring and Cloud Foundry. In addition to that he works on next generation developer tooling and innovative new architectures for cloud-based developer tooling. Before joining the Spring family at Pivotal, Martin co-founded it-agile, a leading consulting and development company focused on agile software development.
Back in February 2017 we started to introduce new IDE-agnostic tooling support with our first beta version of the Cloud Foundry manifest editing support. As promised, we continue this journey with an improved version of the Cloud Foundry manifest editing support for Visual Studio Code and brand-new support for editing Concourse task and pipeline definitions - also as an extension to Visual Studio Code. This marks our second step towards implementing tooling in an IDE-agnostic way, adopting the language server protocol from Visual Studio Code.
As part of our activities to support developers around the globe building applications with Spring and deploying those apps to Cloud Foundry and PCF, we are proud to announce our first beta version of the Cloud Foundry Manifest editing support for Visual Studio Code (on macOS, Linux x64, and Windows).
Why Visual Studio Code?
Visual Studio Code is a lightweight and open-source code editor that runs on macOS, Linux x64, and Windows. It is based on an interesting architecture with regards to extensibility. Support for languages in Visual Studio Code gets implemented as so called “language servers”. Those language servers are independent of the editor that you use. The editor and the language server are connected using a protocol (called the language server protocol). Even though Visual Studio Code introduced this protocol, other editors and IDEs started to adopt this language server protocol - like the Eclipse IDE (from version 4.7 on) or Eclipse Che as a cloud IDE. Other lightweight editors like Sublime Text and Atom will likely offer support in the near future, too. As a result, we can focus on implementing the Cloud Foundry manifest editor support as an independent language server and you can add this support to the editor or IDE of your choice.
in this fifth part of the series we will take a closer look at the new support for multiple launch configurations that was added to the Spring Boot Dashboard in STS 3.7.3.
Multiple launch configs per project
The first version the boot dashboard allowed you to quickly start and stop a local Spring Boot app. Therefore the boot dashboard focused on one specific launch configuration for the project - and completely ignored other launch configs. But having multiple launch configurations per project can be extremely useful, for example to start the same app multiple times in slightly different configurations.
the latest release 3.7.3 of the Spring Tool Suite introduces a number of new features around the Spring Boot Dashboard. Therefore we continue the blog post series that started last year and introduced you to the new way of working with Spring Boot based microservice projects in your IDE (you can find links to the previous parts at the bottom).
Cloud Foundry manifest files
In this new part of the series we take a closer look at Cloud Foundry manifest files. They are a Cloud Foundry concept used as a shortcut to define configurations for applications on Cloud Foundry. Instead of passing every argument and configuration to the command line when doing a “cf push”, you can put all your configuration data into a YAML file and pass that to the push command instead. More detailed information about Cloud Foundry Manifest files can be found here.