Skip to main content

skip to main content

developerWorks  >  Open source  >

Introducing Eclipse

Climbing the productivity curve

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Angus McIntyre (mcintyre@ca.ibm.com), Eclipse project member, IBM

01 Nov 2001

The Eclipse platform is intended to give developers the open source foundation and building blocks they need to produce new development evironments. Eclipse project member Angus McIntyre gives you a brief overview of the code that IBM will be open sourcing at eclipse.org in the near future.

As new productivity tools are introduced to the industry the developer must climb the learning curve to assess the tool for potential productivity gains, and then weigh this effort against the task of integrating this new productivity tool into an existing toolkit. What may initially look like the proverbial silver bullet can become a nightmare when tools manufactured by different vendors simply do not work well together. Tool integration -- when it happens on the developer's desktop -- is frustrating, time consuming, and expensive, and it prohibits new advances in productivity, especially when the developer is trying to control his or her existing development process.

Tool vendors also have a hill to climb when introducing new tools to the market. Should they continue to re-invent the wheel and accept ever-increasing amounts of integration effort for the tools they build, acquire, or partner with? One approach they may take is to create open APIs for an existing IDE, with the hope that the entire development community will make one concerted effort at integration into the IDE. By publishing APIs, tool vendors can easily integrate with the development environment. This has been attempted repeatedly in the industry, with mixed results.

A new open platform for tool integration

In response to these issues, the Eclipse team set up out to build the Eclipse Platform as working code that can be modified and adapted to create new development environments. More than a set of open-sourced APIs and another IDE, the Eclipse Platform is a foundation of common services that tool builders can extend upon, rather than recreating services each time they introduce or integrate a new tool.

Central to the common services of the Eclipse Platform is the concept of a "plugin". Tools that "plug in" to the Eclipse Platform are provided with a set of common services that make tool-to-tool integration possible. The first common service is a project model. The project model is a graphical view of all the resources (U/I, UML, business logic, HTML, Java, C, COBOL) that make up a project. As developers find, create, and modify resources using different tools, the resource management service shares the resource status (creation, deletion, and modification) with other tools. Workplace synchronization keeps the views inside each of the tools consistent to the latest modification of the resource. And because developers can work within teams, a Team programming model, exposed as an interface to the open standards-based CVS version control system, provides version control management. A remote debug interface is provided so that tools can be built to test the application as it runs live on the target machine (server, device, rules engine). An Extensibility framework rounds out these services, providing extension points to build new services.

As tool builders create "plugins" the tools inherit the services provided by the Eclipse Platform. This saves an immense amount of time for tool builders, allowing each to extend from the foundation to provide their own value to the developer.

The Eclipse team tested this architecture when building the Java IDE, the ANT build environment, and the scripting capabilities within the Eclipse Platform. This assured the team that the building blocks within Eclipse, exposed as the common services, could be used by developers to integrate tools at an industry level.



Back to top


Open source creates a level playing field for all tool builders

The open source nature of Eclipse also means that all tool builders have a level playing field on which to build value. Enterprises and enterprising individuals each have the same information available to them to make tool integration decisions. Why rebuild something when it exists in a working format already? Reuse is the highest form of compliment, and by reusing the open Eclipse Platform, tool builders can focus on domain-specific expertise and functions (their core skills), delegating to the common services of the Eclipse Platform as they see fit.

But the adoption of a new platform takes trust, and trust for any new architecture or platform is slowly earned. For instance, it is hard to earn the trust of developers for tooling that contains proprietary interfaces that limit an application to a single operating system (for example, Windows). It is also hard to earn the trust of tool builders when different levels of APIs are shipped with different levels of tool offerings (for example, when Community APIs differ from Enterprise APIs). The Eclipse Platform intends to build confidence and trust by providing all of the APIs, without internal, proprietary, or hidden interfaces.

Open source can also produce a higher quality of code. When code review is collaborative, people often put extra effort into it. The source code they contribute becomes a reflection of the work they do, establishing both individual and corporate reputations.

Open source based on clear specifications can deliver code that is easier to understand. An Interface describes (in black box terms) the promise of component behavior. By directly inspecting the source, developers can examine, line by line, how the code works.

Open source can be also be easier to debug. Late at night, when encountering a bug, source code can speed identification of the root cause. It could be the developer's fault, or the fault of the platform and environment. With access to the source, guesswork is eliminated. With access to a collaborative discussion forum, it's even possible to compare notes with someone else who's familiar with the environment or problem. If the problem appears to be in shared open source, it's easy to patch it and attempt a workaround.

Flexibility is a fundamental virtue of Eclipse. With the open Eclipse Platform, an unsatisfactory component can be modified to suit your needs. For example, if a given editor is inadequate, create your own, or plug in a popular one created in the open component market established by the Eclipse Platform.



Back to top


Recognizing the needs of developers

Eclipse was built to recognize the needs of both the developer community at large, as well as the tool builder community. The recognition of these needs is core to the design principles of the Eclipse Platform:

  • Facilitate seamless integration of tools within and across different content types and tool providers.
    Integration at an industry level is possible, given that the right set of common services, and the right terms and conditions, are provided to all tool builders.

  • Support the construction of a variety of tools.
    It takes more than just another Java IDE. Eclipse takes development to the next step; to what the Gartner Group terms "Production Development Environments" (for flow-based systems, rules-based runtime environments) and beyond.

  • Support an unrestricted set of tool providers, including independent software vendors (ISVs).
    Tool builders need the freedom to explore new market opportunities. The Common Public License of Eclipse allows tool builders to modify the Eclipse source, create derivative works and world wide redistribution rights, providing the maximum flexibility for tool builders.

  • Support tools to manipulate arbitrary content types (such as HTML, Java, C, JSP, EJB, XML, and GIF).
    Development teams are made up of multiple individuals, all of whom play an important role in delivering applications. Each developer has his or her own tool set, which assists in creating the application, as it is architected, coded, built, tested, deployed, and maintained.

  • Support both GUI and non GUI-based application development environments.
    Developers need to integrate tools that may be based on a command line interface.

  • Run on a wide range of operating systems, including Windows and Linux.
    Rather than a "build on Windows, run on Linux" strategy, the Eclipse Platform runs on Linux as a reference platform. With access to the source, and the ability to redistribute and create derivative works, the Linux community can easily rise to the challenge of supporting Eclipse across multiple distributions. The Eclipse forum has open discussions on taking the platform to SuSE, Debian, and Mandrake.

  • Capitalize on the popularity of the Java programming Language for writing tools.
    Tens of millions of developers are available to take the Eclipse Platform forward and explore new technical and business opportunities.


Back to top


The tool integration challenge

As mentioned at the beginning of this article, tool integration, when it happens on the developer's desktop is frustrating, time consuming, and expensive. The Eclipse Platform also makes tool integration in vendor labs possible. The industry, as a whole, has to stop recreating the wheel and focus on developer productivity through tool integration. The Eclipse Platform provides the foundation for this to happen. Its architecture is controversial; opinions will be formed. Its community is open; debate will occur. But the platform and the community are designed to address three major assurances that tool builders need when selecting an architecture:

  • A level playing field and full disclosure with no hidden APIs and no hidden tool-to-tool interfaces. Eclipse delivers this by shipping open platform source.
  • The freedom to enhance the platform to address new opportunities. Eclipse delivers the ability to create derivative works, including redistribution of the platform.
  • Timely response to developers' requests for changes and enhancements in a controlled and organized way. Through www.eclipse.org, developers can make a difference by collaborating and contributing to the platform.

More important is that the Eclipse Platform provides the ultimate challenge: the freedom to use the platform to explore and address new market opportunities. The Eclipse team cannot possibly grow the platform to address all of the needs in the market. You can, and your journey begins today at www.eclipse.org.



Resources



About the author

You can reach Eclipse project member Angus McIntyre at mcintyre@ca.ibm.com.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful
Extremely
useful
 


Back to top