Eclipse Core Overview

Index

Project Breakdown

Runtime Framework

Description

The new OSGi code.

Projects

Runtime

Description

Code dealing with bootstrapping the system, the extension registry and concurrency models, as well as utility classes.

The org.eclipse.core.boot project contains the bootstrap code needed to get the platform up and running. It calls the EclipseStarter in OSGi which starts the framework. It is currently being investigated as to whether or not this code can be merged into the Main.java class and this project be removed from the SDK.

The org.eclipse.core.runtime project contains the runtime APIs. This includes the job manager, util classes (IPath, IProgressMonitor, CoreException, etc), the new extension registry.

The org.eclipse.core.runtime.compatibility project exists for backwards compatibility purposes only. It contains deprecated APIs. (mostly dealing with the old plug-in registry)

The Main.java class in the org.eclipse.platform project contains the code for the startup.jar. This code finds the bootloader and allows Eclipse to start. This project also contains the files which are found in the root of the Eclipse install.

The platform-launcher project contains the C code for the Eclipse executable. It is owned by Platform/Core but was written and generously maintained by Platform/SWT since they have more experience in writing C code. The executable handles special return codes from the application indicating whether to restart, print out a message saying that there is info in the .log file, etc.

Note that there are problems running Eclipse with an IBM 1.4 JRE and plug-ins having a requirement on the org.apache.xerces plug-in. Therefore, there is currently a request into the Eclipse PMC to remove this plug-in from the Eclipse SDK distribution. As an alternative, plug-in developers are encouraged to code using the JAXP APIs available in the 1.4 JDK.

Projects

Resources

Description

The workspace APIs which includes everthing dealing with workspaces, resources, markers, properties, and local history.

Core Resources also contributes a library with filesystem calls. Although not necessary for Eclipse to run, running with the appropriate resources library will yield peformance enhancements as well as minor functionality benefits. Currently the library is available for 5 different OSes (windows, linux, hp-ux, macosx, and qnx) and it:

Projects

PDE-Build

Description

Used to generate the build.xml Ant files for the builder.

Projects

WebDAV

Description

Provides WebDAV support and is available as a separate download on the Eclipse/downloads web page. This used to be a part of the Eclipse SDK proper but was removed a while ago. (after release 1.0?) Note that the WebDAV plug-in has NO dependancy on the Eclipse Runtime.

Why does Core own this? For legacy reasons. In early releases of Eclipse the VCM code was integrated tightly with Core and was done by the same team. As Eclipse matured, the code was refactored and split apart.

Projects

Misc

Description

The org.eclipse.core.tests.harness project contains helper classes for the Core test suites. All Core test classes sub-class EclipseWorkspaceTest.

Projects

The Build

The builder needs a couple of pieces of information (version, repository, username, password) in order to include the correct versions of projects in a build. This information is put into what we call a map file. Look in the maps/ folder of the org.eclipse.releng project to see the map files that the builder uses to create the Eclipse integration builds. Here are some sample lines from this file:

plugin@org.eclipse.core.resources=v20031201,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
fragment@org.eclipse.core.resources.win32=v20031111,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,

Project Tag Naming Conventions

Customary naming convention is the date. (e.g. v20031129 for a build on November 29, 2003) If there is a second (or third, etc) build on the same day, then we just append a letter to the end of the previous tag. (e.g. v20031129a)

For maintenance builds we use an indicator for the build, along with the date. (e.g. r21x_v20031124 for a maintenance build for Eclipse 2.1.1, 2.1.2, etc on November 24, 2003)

Process

Build Tool

The Release Engineering team has a build tool available on their web page and it will help you with the above process. The tool adds a Team -> Release item to the context menu for projects. It tags the project and updates the line in the map file for you. Note that you still have to manually commit the changes to the map file to the repository yourself but the tool will bring up the Sychronize view for you.

Build Schedule

The build schedule found on the Release Engineering team page on Eclipse.org.

Bug Reports

Bug Lifecycle

For illustrated purposes I will use Platform/Core as an example.

Owner
Status
Note
platform-core-inbox NEW Bug is entered by user.
platform-core-inbox ASSIGNED More information is gathered (build id, steps to reproduce) and it is determined that the bug report is real. This state is referred to as "Open Bugs" and can best be described as bugs which are real but no one is currently working on.
team member NEW/ASSIGNED Bug is assigned to team member to address or the team member takes an "Open" bug and assigns it to themselves.
team member RESOLVED/FIXED Bug is fixed. Target milestone is added to report if none already exists.

 

Component Breakdown

Product
Component
Note
Equinox General Bugs reports against the new runtime and the OSGi projects.
Platform Core Bugs against the old runtime APIs (JobManager, IPath, etc) and the Workspace APIs.
Platform WebDAV Bug reports against the org.eclipse.webdav project.
PDE Build Bug reports against the org.eclipse.pde.build project.