platform-core-home/documents/core_overview.html
Parent Directory
| 
Revision Log
Revision 1.1 -
(download)
(as text)
(annotate)
Wed Dec 10 18:14:00 2003 UTC (5 years, 11 months ago) by dj
Branch: MAIN
CVS Tags: v20040721, HEAD
Wed Dec 10 18:14:00 2003 UTC (5 years, 11 months ago) by dj
Branch: MAIN
CVS Tags: v20040721, HEAD
Added Core Overview doc.
<html><title>Eclipse Core Overview</title><body>
<h2 align="center">Eclipse Core Overview</h2>
<h2>Index</h2>
<ul>
<li><a href="#projects">Project Breakdown</a></li>
<li><a href="#builds">The Build</a></li>
<li><a href="#bugs">Bug Reports</a></li>
</ul>
<h2><a name="projects"></a>Project Breakdown</h2>
<h3>Runtime Framework</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>The new OSGi code.</p>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.eclipse.osgi</li>
<li>org.eclipse.osgi.services</li>
<li>org.eclipse.osgi.util</li>
</ul>
</blockquote>
<h3>Runtime</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>Code dealing with bootstrapping the system, the extension registry and
concurrency models, as well as utility classes.</p>
<p>The <code>org.eclipse.core.boot </code>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.</p>
<p>The <code>org.eclipse.core.runtime </code>project contains the runtime
APIs. This includes the job manager, util classes (IPath, IProgressMonitor,
CoreException, etc), the new extension registry.</p>
<p>The <code>org.eclipse.core.runtime.compatibility </code>project exists
for backwards compatibility purposes only. It contains deprecated APIs.
(mostly dealing with the old plug-in registry)</p>
<p>The <code>Main.java </code>class in the <code>org.eclipse.platform </code>project
contains the code for the <code>startup.jar</code>. 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.</p>
<p>The <code>platform-launcher </code>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. </p>
<p>Note that there are problems running Eclipse with an IBM 1.4 JRE and plug-ins
having a requirement on the <code>org.apache.xerces</code> 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.</p>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.apache.xerces</li>
<li>org.eclipse.core.boot</li>
<li>org.eclipse.core.runtime</li>
<li>org.eclipse.core.runtime.compatibility</li>
<li>org.eclipse.core.tests.runtime</li>
<li>org.eclipse.platform</li>
<li>platform-launcher</li>
</ul>
</blockquote>
<h3>Resources</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>The workspace APIs which includes everthing dealing with workspaces, resources,
markers, properties, and local history.</p>
<p>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:</p>
<ul>
<li>bundles multiple OS calls into one function call</li>
<li>implements #setReadOnly (java.io.File#setReadOnly is a no-op)</li>
<li>improves timestamp granularity on some VMs</li>
</ul>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.eclipse.core.resources</li>
<li>org.eclipse.core.resources.linux</li>
<li>org.eclipse.core.resources.win32</li>
<li>org.eclipse.core.resources.hpux</li>
<li>org.eclipse.core.resources.macosx</li>
<li>org.eclipse.core.resources.qnx</li>
<li>org.eclipse.core.tests.resources</li>
<li>org.eclipse.core.tests.resources.saveparticipant</li>
<li>org.eclipse.core.tests.resources.saveparticipant1</li>
<li>org.eclipse.core.tests.resources.saveparticipant2</li>
<li>org.eclipse.core.tests.resources.saveparticipant3</li>
</ul>
</blockquote>
<h3>PDE-Build</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>Used to generate the build.xml Ant files for the builder.</p>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.eclipse.pde.build</li>
</ul>
</blockquote>
<h3 align="left">WebDAV</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>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.</p>
<p>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.</p>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.eclipse.webdav</li>
</ul>
</blockquote>
<h3>Misc</h3>
<blockquote>
<h4>Description</h4>
<blockquote>
<p>The <code>org.eclipse.core.tests.harness</code> project contains helper
classes for the Core test suites. All Core test classes sub-class <code>EclipseWorkspaceTest</code>.</p>
</blockquote>
<h4>Projects</h4>
<ul>
<li>org.eclipse.core.tests.harness</li>
</ul>
</blockquote>
<h2><a name="builds"></a>The Build</h2>
<p>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 <code>map</code> file. Look in the <code>maps/</code>
folder of the <code>org.eclipse.releng</code> project to see the map files that
the builder uses to create the Eclipse integration builds. Here are some sample
lines from this file: </p>
<blockquote>
<p><code>plugin@org.eclipse.core.resources=v20031201,:pserver:anonymous@dev.eclipse.org:/home/eclipse<br>
fragment@org.eclipse.core.resources.win32=v20031111,:pserver:anonymous@dev.eclipse.org:/home/eclipse,</code></p>
</blockquote>
<h3>Project Tag Naming Conventions</h3>
<p>Customary naming convention is the date. (e.g. <code>v20031129</code> 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.
<code>v20031129a</code>)</p>
<p>For maintenance builds we use an indicator for the build, along with the date.
(e.g. <code>r21x_v20031124</code> for a maintenance build for Eclipse 2.1.1,
2.1.2, etc on November 24, 2003)</p>
<h3>Process</h3>
<ul>
<li>test and release code changes</li>
<li>version project in repository</li>
<li>change line in map file to match project version</li>
<li>release change to map file to HEAD</li>
<li>the builder will automatically version the map file before beginning the
integration build</li>
</ul>
<h3>Build Tool</h3>
<p>The Release Engineering team has a build tool available on <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">their
web page</a> and it will help you with the above process. The tool adds a <code>Team
-> Release</code> 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 <code>Sychronize</code> view for you.</p>
<h3>Build Schedule</h3>
<p>The build schedule found on the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/main.html">Release
Engineering</a> team page on <a href="http://eclipse.org">Eclipse.org</a>.</p>
<h2><a name="bugs"></a>Bug Reports</h2>
<h3>Bug Lifecycle</h3>
<blockquote>
<p>For illustrated purposes I will use Platform/Core as an example.</p>
<table width="87%" border="1">
<tr>
<td width="22%"><div align="center"><strong>Owner</strong></div></td>
<td width="23%"><div align="center"><strong>Status</strong></div></td>
<td width="55%"><div align="center"><strong>Note</strong></div></td>
</tr>
<tr>
<td>platform-core-inbox</td>
<td>NEW</td>
<td>Bug is entered by user.</td>
</tr>
<tr>
<td>platform-core-inbox</td>
<td>ASSIGNED</td>
<td>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.</td>
</tr>
<tr>
<td>team member</td>
<td>NEW/ASSIGNED</td>
<td>Bug is assigned to team member to address or the team member takes an
"Open" bug and assigns it to themselves.</td>
</tr>
<tr>
<td>team member</td>
<td>RESOLVED/FIXED</td>
<td>Bug is fixed. Target milestone is added to report if none already exists.</td>
</tr>
</table>
<p> </p>
</blockquote>
<h3>Component Breakdown</h3>
<blockquote>
<table width="86%" border="1">
<tr>
<td width="15%"><div align="center"><strong>Product</strong></div></td>
<td width="21%"><div align="center"><strong>Component</strong></div></td>
<td width="64%"><div align="center"><strong>Note</strong></div></td>
</tr>
<tr>
<td>Equinox</td>
<td>General</td>
<td>Bugs reports against the new runtime and the OSGi projects.</td>
</tr>
<tr>
<td>Platform</td>
<td>Core</td>
<td>Bugs against the old runtime APIs (JobManager, IPath, etc) and the Workspace
APIs.</td>
</tr>
<tr>
<td>Platform</td>
<td>WebDAV</td>
<td>Bug reports against the <code>org.eclipse.webdav </code>project.</td>
</tr>
<tr>
<td>PDE</td>
<td>Build</td>
<td>Bug reports against the <code>org.eclipse.pde.build </code>project.</td>
</tr>
</table>
</blockquote>
<p> </p></body></html>| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |