Using the Eclipse IDE for Java programming – Tutorial

1. Overview of the Eclipse open source project

1.1. The Eclipse IDE, other projects and a short history

In November 2001, a consortium was formed by IBM to support the development of the Eclipse IDE as an open source software. In 2004 it became the Eclipse Foundation, which is a vendor neutral foundation where no single company has control of the direction.

The Eclipse Foundation is a non-profit, member supported corporation.

It helps to cultivate both its open source community and its ecosystem of complementary products and services.

The mission of the Eclipse Foundation is enable the development by providing the infrastructure (version control systems, code review systems, build servers, the download sites, etc.) and a structured process. The Eclipse Foundation does not work on the Eclipse code base, i.e., it does not have employee developers working on Eclipse projects. Eclipse projects follow a very well defined development process description.

In 2018 the Eclipse foundation staff consists of approximately 30 employees.

These days, the Eclipse open source community consists of more than 150 projects covering different aspects of software development. For example, Eclipse projects hosts the Jakarta EE project (formly known as Java EE), tooling for JavaScript development and the Jetty webserver.

1.2. Eclipse IDE releases

The Eclipse IDE open source project provides regular releases. It used to be one large release per year but in 2018 this was changed to one release every three months.

ReleaseRename nameRelease year
4.122019-062019
4.112019-032019
4.102018-122019
4.92018-092018
4.8Photon2018
4.7Oxygen2017
4.6Neon2016
4.5Mars2015
4.4Luna2014
4.3Kepler2013
4.2Juno2012

1.3. The Eclipse Public License

The Eclipse Public License (EPL) is an open source software license. The EPL is designed to be business-friendly. EPL licensed programs can be used, modified, copied and distributed free of charge. The consumer of EPL-licensed software can choose to use this software in closed source programs.

Only modifications in the original EPL code must be released as EPL code. This can for example be done by filling a bug report at the public Eclipse bug tracker and by uploading a Gerrit change.

The Eclipse Foundation validates that source code contributed to Eclipse projects is free of intellectual property (IP) issues. This process is known as IP cleansing. Contributions with more than 1000 lines of code require the creation of a Contribution Questionnaire, and a review and approval by the IP team.

The permissive EPL and the IP cleansing effort of the Eclipse Foundation makes reusing the source code of Eclipse projects attractive to companies.

2. Different Eclipse IDE distributions

2.1. The Eclipse IDE for Java development

Most people know Eclipse as an integrated development environment (IDE) for Java. In 2014 the Eclipse IDE is the leading development environment for Java with a market share of approximately 65%.

The Eclipse IDE can be extended with additional software components. Eclipse calls these software components plug-ins. Plug-in can be grouped into features.

Several projects and companies have extended the Eclipse IDE or created stand-alone applications (Eclipse Rich Client Platform) on top of the Eclipse framework.

2.2. The Eclipse IDE distributions from the Eclipse Packaging Project (EPP)

The Eclipse IDE is also available as an IDE for other languages, ranging from C, C++ to Lua, Python, Perl and PHP. Several pre-packaged Eclipse distributions are available for download. These pre-packaged solutions are provided by an Eclipse project called the Eclipse Packaging Project (EPP).

2.3. Developer and milestone downloads

The Eclipse project has a simultaneous release every year at the end of June. In June 2016 the Eclipse 4.6 (Neon) version was released.

The top-level Eclipse project creates regular builds of the next releases including JDT, PDT and the Eclipse platform projects. This is called the Eclipse SDK.

You find Stable Builds which are tested by the community. These milestone (ending with M and a number) and release candidate (RC) builds are created based on a predefined time schedule. Integration (I) and Nightly (N) builds are test builds which are automatically created. They are not manually tested.

In general, milestone and RC builds are relative stable compared to integration builds, but may not contain the latest features and patches.

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注