The new OSGi code.
Code dealing with bootstrapping the system, the extension registry and concurrency models, as well as utility classes.
org.eclipse.core.bootproject 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.
org.eclipse.core.runtimeproject contains the runtime APIs. This includes the job manager, util classes (IPath, IProgressMonitor, CoreException, etc), the new extension registry.
org.eclipse.core.runtime.compatibilityproject exists for backwards compatibility purposes only. It contains deprecated APIs. (mostly dealing with the old plug-in registry)
Main.javaclass in the
org.eclipse.platformproject 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.
platform-launcherproject 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.xercesplug-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.
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:
- bundles multiple OS calls into one function call
- implements #setReadOnly (java.io.File#setReadOnly is a no-op)
- improves timestamp granularity on some VMs
Used to generate the build.xml Ant files for the builder.
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.
org.eclipse.core.tests.harnessproject contains helper classes for the Core test suites. All Core test classes sub-class
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
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:
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.
For maintenance builds we use an indicator for the build, along with the date.
r21x_v20031124 for a maintenance build for Eclipse 2.1.1,
2.1.2, etc on November 24, 2003)
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
-> 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.
The build schedule found on the Release Engineering team page on Eclipse.org.
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.
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
PDE Build Bug reports against the