Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Cloud Foundry (CF) is an open platform as a service (PaaS) that provides a choice of clouds, runtime frameworks, and application services. It is an open source project with an active and growing community that contributes and supports it, and includes many corporations and organizations like Pivotal, IBM, HP, EMC, Cisco, and SAP.
The Cloud Foundry Tools project was started as a collaboration between Pivotal and IBM, and it is a framework for Eclipse that contains common, reusable application deployment, scaling and service features for Cloud Foundry, and allows third-party vendors to contribute their own Cloud Foundry-based definitions where users can deploy their applications from within their Eclipse IDE.
The scope of this project is to help users deploy and test their applications on Cloud Foundry without leaving their Eclipse integrated development environment. Instead of separately running builds and using the Cloud Foundry command line tool to deploy, scale, or configure applications on Cloud Foundry, developers are able to deploy application projects directly from within their Eclipse IDE, see the running applications on CF, bind or unbind services, scale them up or down, and debug them on CF.
Out of Scope:
This project does not deal with the development of Cloud Foundry as a platform itself and does not provide tooling to assist with that. Working on the CF open-source code itself is unrelated to this project, which focuses solely on users working with the Eclipse IDE and targeting a Cloud Foundry platform where they can deploy and test their applications.
Cloud Foundry Tools provide an extensible framework and common UI to deploy applications to different Cloud Foundry targets, and it is a framework that closely integrates with Web Tools Platform (WTP) and Eclipse. It allows application scaling and services management from the same Eclipse-based IDE where applications are developed. Applications can also be debugged on Cloud Foundry using the built-in Eclipse debugger. This makes it very convenient for developers to work on applications running on CF.
The Cloud Foundry Tools are not specialized to just work with a specific Cloud Foundry platform. It allows users to set various Cloud Foundry targets, may it be public Cloud Foundry-based platforms like Pivotal Web Services, IBM Bluemix, or others.
Cloud Foundry Tools are a framework that integrates with WTP and uses existing Eclipse UI for application deployment. Cloud Foundry Tools are accessible from existing Eclipse views like the Servers view, and allows application deployment to CF through common Eclipse wizards, like the New Server and Run On Server wizards. It also integrates with the Eclipse Console, streaming application logs from CF to the user, and presents a view of files in CF through the Remote Systems view.
In addition the tool has gained a degree of maturity with various release cycles as an open source project since 2012. It is being actively developed and maintained by two experienced Eclipse development teams, Spring Tool Suite on the Pivotal side, and WTP on IBM. The project also receives additional pull requests from development teams at other organizations.
Being an extensible, open source framework, where third parties can contribute their own CF target definitions through the Cloud Foundry Tools branding extension point, it is an ideal common CF deployment tool for Eclipse.
Its inclusion as an Eclipse project and eventual end-goal of adding it to the Eclipse release train will greatly enhance Eclipse as a primary application development environment for Cloud Foundry.
The initial contribution is been donated by the Cloud Foundry Foundation with Pivotal and IBM working on the project.
The initial contribution is a stable codebase and is already used in production.
This project will be distributed under both the Apache License 2.0 and the Eclipse Public License. The current version of the project (at the Cloud Foundry Foundation) is already using the Apache License 2.0 and has contributors and adopters that are using it via the Apache License. To avoid confusion and not force the existing community to change the license immediately, a dual license would be ideal for the project under Apache License 2.0 as well as the Eclipse Public License.
The project already shipped a number of releases in the past and uses an established release and development cycle of 6 weeks. This process will continue once the project is at Eclipse.
As well as becoming an Eclipse project, our intention is to get Cloud Foundry Tools onto the Eclipse release train, ideally in the Eclipse 4.5 (Mars) Service Refresh 1 (SR1) timeframe.
The following is a general roadmap for the next 12 months:
- Begin migration from Cloud Foundry to Eclipse Project after version 1.8.3 of Cloud Foundry Tools are released after mid-June 2015.
- The current code base contains vendor specific definitions for Pivotal Web Services. Scope refactoring work to define a core framework and move vendor specific definitions into extensions and determine how much of this is necessary.
- Cloud Foundry itself experiences frequent changes. In particular it may experience changes with the Cloud Controller API, so compatibility at the tools level, with possibly some enhancements already in place to better handle version incompatibilities.
- Adopt WTP changes that allows users to better discover vendor specific downloadables into the core framework from existing WTP user interfaces. This is future work that may be available before the next Eclipse GA in 2016.
The first step is to turn Cloud Foundry Tools into an Eclipse project, and the existing code base will be migrated “as is” with the Pivotal Web Services definition. The second step is to include it in the Eclipse release train in SR1, which is the end-goal of this migration to the Eclipse Foundation. Discussions are ongoing on whether to refactor the vendor definitions out of the tool and create a pure core framework, with possibly a vendor-neutral definition example, or do the refactoring after it is part of the release train. Past experiences with WTP indicate that including vendor definitions may be problematic for maintenance. An ideal scenario is to have a pure core framework and vendor specific definitions hosted externally, but discoverable through the framework UI. Current work is being done with WTP to allow this discovery and better support vendor defined Cloud Foundry targets outside of a pure Cloud Foundry Tools core framework.