Meet the OSGi Enterprise Tools Eclipse Project
OSGi Enterprise Tools Interview
The latest project proposal at Eclipse.org looks to bridge the gap between PDE and WTP. In this interview, we speak to initial committer to the project Kaloyan Raev, to find out more.........
JAXenter: What is the OSGi Enterprise Tools project?
Kaloyan Raev: The OSGi Service Platform Specifications were originally created for the embedded systems. But over time it turned out that the OSGi component model is suitable also for development of larger modular systems and therefore embraced by the majority of the popular application servers today. Following this success, the OSGi Alliance extended the OSGi Service Platform with a set of Enterprise Specifications to address the use cases of the enterprise business scenarios.
The OSGi Enterprise Tools project has been recently proposed by SAP to the Eclipse community. The goal of the project is to address the need of tools for development of enterprise applications using the OSGi component model.
The project is currently in proposal phase according to the Eclipse Development Process. In this phase a project proposal is publicly discussed in the Eclipse community to get feedback for the purpose and scope of the project. We have extremely positive response by the community. The proposal document has already been updated several times to reflect the provided feedback. Three companies expressed interest in joining the project - Eteration, EclipseSource and SpringSource/VMWare. I expect that the discussions will be finalized in November and the project will be officially created as an Eclipse open source project.
JAXenter: What gap does the project aim to fill, that is not already addressed by either PDE or WTP?
Kaloyan Raev: Both the Eclipse Plug-in Development Environment (PDE) and the Eclipse Web Tools Platform (WTP) projects provide excellent tooling with regards to their project's scope. PDE was originally designed for development of Eclipse plug-ins. When the Eclipse Platform moved its component model to OSGi, this toolset naturally became suitable for development of OSGi bundles. In parallel, WTP enables application developers with first class Java EE tools.
But, the tooling of PDE and WTP were used independently - one either uses PDE for development of OSGi bundles, or WTP for development of Java EE applications. If one needs to develop Web Application Bundles, then PDE and WTP cannot be easily used together out of the box. The OSGi Enterprise Tools aims to fill exactly this gap - to "marry" PDE and WTP by adding the missing pieces for easier development of OSGi enterprise projects.
JAXenter: How will Virgo Tools components, be integrated into the OSGi Enterprise Tools project?
Kaloyan Raev: There have already been discussions with the Virgo team about their plans for contributing the Virgo Tools to Eclipse. The Virgo team at SpringSource decided to actively join the OSGi Enterprise Tools project.
However, because the Virgo Tools is quite a big contribution, they will first donate the code as a monolithic project under the Eclipse Runtime top-level project. After a successful IP review, they will start refactoring the code, so any generic parts, that are not specific to the Virgo runtime, will go either to the PDE project or to the new OSGi Enterprise Tools project. At the end, only the Virgo-specific tooling will remain under the Eclipse Runtime project with excellent integration with the other Eclipse tools for OSGi development.
JAXenter: What tools will the project initially aim to provide?
Kaloyan Raev: As I mentioned previously there are several companies that will take active part in the project. Each of them is already focused on a problem area of their greatest pain points.
SAP will initially contribute an OSGi Bundle facet that will integrate a major part of the PDE and WTP tolling to work together. Eteration will work towards easier deployment of the OSGi Enterprise applications on the variety of the OSGi frameworks available today - Apache Felix, Eclipse Equinox and Knoplerfish. EclipseSource will focus on improvements of the RAP deployment scenario by providing a feature for WAR deployment of Server Side Equinox applications.
The initial contribution is just the first milestone of the project. Then we will focus on integrating everything that we have from the different parties and align them with the other tools that we have in the Eclipse community. A major goal of the project is to not develop any replacement of existing tooling in the PDE and WTP projects. If the latter two have any limitations, we will do the best effort to address them directly in the relevant projects.
JAXenter: Currently, SAP is involved in various
Eclipse modeling and OSGi projects.
What is the reason for that?
Kaloyan Raev: The core business of SAP has always been on delivering of first class enterprise software products and solutions to our customers. Building blocks - like application servers, development tools and build infrastructure - have never been products by their own in the SAP portfolio. Over the years we realized that there is no sense in making huge investments to develop such base technologies as a proprietary software, since this does not contribute any key differentiators to our products.
With the start of the development of the Next Generation of SAP NetWeaver, we have the opportunity of replacing lots of our building blocks with alternatives from the open source community. We take the smarter approach of investing the efforts, that we would otherwise spend on proprietary development, to the best open source project that we can later consume for our own products. We are also reviewing some of our best technologies that are still needed for our future projects, but there are no suitable open source alternatives, and contribute them to the Eclipse community with the intention to continue their development as open source projects.
SAP is taking big steps increasing involvement with the Eclipse and Apache communities. This is a trend that is going to continue in the next years too. The OSGi Enterprise Tools project is yet another cornerstone in the SAP open source strategy.