blob: 216c4edee6dd0a2bbc442de50c30291618d3fd39 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"><HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css">
<title>Fragments</title>
</head>
<BODY BGCOLOR="#ffffff">
<h1>Self-hosting</h1>
<p CLASS="BodyText">Self-hosting is an activity in which a computer program is
used to create new versions of the same program. Self-hosting is very frequent
in compiler development, where new versions of the compiler are written in the
target language of the compiler and compiled by itself as part of the testing.
In Eclipse, self-hosting refers to using Eclipse for developing Eclipse
plug-ins. If it sounds like the mission statement of PDE, it should. By the
virtue of using PDE, you are already self-hosting.</p>
<p CLASS="BodyText">PDE supports two distinct styles of self-hosting. They both
have their advantages and disadvantages and are designed for different usage
scenarios. They differ in the way plug-in dependencies are managed.</p>
<ol>
<li>
<p CLASS="BodyText"><b>Simple (standalone) self-hosting</b> uses external
plug-ins for resolving plug-in references. It is simple, easy to manage and
understand, and is completely adequate for standalone developers (those who
do not use remote repositories to share their code with others).</li>
<li>
<p CLASS="BodyText"><b>Binary project self-hosting</b> introduces a step
whereby external plug-ins are imported into the workspace as binary
projects. They are still not meant to be modified and are usually hidden
using a binary project filter in Package Explorer.</li>
</ol>
<p CLASS="BodyText">As a new feature in 2.1 release, PDE offers an
additional style that is more of a mix between simple and binary project
self-hosting. In this mode, a classpath container provided by JDT are used
to represent entries for dependent plug-ins. These entries are computed
dynamically depending on the current situation in the platform. If a
referenced plug-in is found outside (external), the reference will be
resolved as external JARs. If the plug-ins is found in the workspace, it
will resolve into the project reference. Changes in the workspace
automatically affect the classpath in the container. Finally, since entries
are computed when needed (not hard-coded and stored), changes in the target
platform do not result in stale and/or fragile classpaths.
<p>&nbsp;<br>
<a href="../hglegal2003.htm">
<img src = "../images/ngibmcpy2003.gif" alt="Copyright IBM Corporation and others 2000, 2003" border="0" width="324" height="14"></a>
</p>
<p> </p>
<p>&nbsp;</p>
<p align="left">&nbsp;</p>
<p align="left">&nbsp;</p>
</body>
</html>