bundles/org.eclipse.platform.doc.isv/guide/arch_struct.htm - platform/eclipse.platform.common - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//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>Platform SDK roadmap</TITLE>

 <link rel="stylesheet" type="text/css" HREF="../book.css">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
 <H2>
 Platform SDK roadmap</H2>

 <H3>Runtime core</H3>
 <P >
 The platform runtime core implements the runtime engine that starts the platform base and dynamically discovers plug-ins. A
 <b> plug-in</b> is a structured component that describes itself to the system using
 a manifest
 (<b>plugin.xml</b>) file. The platform maintains a registry of installed plug-ins and the function they provide.</P>
 <P >
 Function is added to the system using a common extension model. <b> Extension points</b> are well-defined function points
 in the system that can be extended by plug-ins. When a plug-in contributes an implementation for an extension point, we say that it adds an
 <b> extension</b> to the platform. Plug-ins can define their own extension points, so that other plug-ins can integrate tightly with them.</P>
 <P >
 The extension mechanisms are the only means of adding function to the platform and other plug-ins.
 All plug-ins use the same mechanisms.&nbsp; Plug-ins provided with the Eclipse
 SDK do not use any private mechanisms in their implementation.</P>
 <P >
 Extensions are typically written in Java using the platform APIs. However, some extension points accommodate extensions provided as platform executables, ActiveX components, or developed in scripting languages. In general, only a subset of the full platform function is available to non-Java extensions. </P>
 <P >
 A general goal of the runtime is that the end user should not pay a memory or performance penalty for plug-ins that are installed, but not used. A plug-in can be installed and added to the registry, but the plug-in will not be activated unless
 a function provided by the plug-in has been requested according to the user's activity.</P>
 <P >
 The best way to get a feel for the runtime system is to build a plug-in. See
 <a HREF="firstplugin.htm" CLASS="XRef"> Plug it in: Hello World meets the workbench</a> to get started
 building a plug-in.  Once you have mastered the basics of plug-in writing and you're ready
 to define your own extension points, see <a HREF="arch_extension_points.htm">Defining an extension point</a>.
 </P>


 <H3>
 Resource management</H3>
 <P >
 The resource management plug-in defines a common resource model for managing the
 artifacts of tool plug-ins. Plug-ins can create and modify
 <b>projects</b>, <b>folders</b>, and <b>files</b>, as well as define specialized types of resources.</P>
 <P >
 <a HREF="resInt.htm" CLASS="XRef">Resources overview</a> provides an overview of the resource management system.</P>


 <H3>
 Workbench UI</H3>
 <P >
 The workbench UI plug-in implements the workbench UI and defines a number of extension points that allow other plug-ins to contribute menu and toolbar actions, drag and drop operations, dialogs, wizards, and custom views and editors.</P>
 <P >
 <a HREF="workbench.htm" CLASS="XRef">Plugging into the workbench</a> introduces the workbench
 UI extension points and API.</P>


 <P >
 The workbench UI plug-in also provides frameworks that are useful for user
 interface development.&nbsp; These frameworks were used to develop the workbench
 itself.&nbsp; Using the frameworks not only eases the development of a plug-in's
 user interface, but ensures that plug-ins have a common look and feel and a consistent level of workbench integration.</P>


 <P >
 The Standard Widget Toolkit (SWT) is a low-level, operating system independent toolkit that supports platform integration and portable API.
 It is described in
 <a HREF="swt.htm" CLASS="XRef">Standard Widget Toolkit</a>.</P>
 <P >
 The JFace UI framework provides higher-level application constructs for supporting dialogs, wizards, actions, user preferences, and widget management.&nbsp;
 The functionality in JFace is described in
 <a HREF="dialogs.htm" CLASS="XRef"> Dialogs and wizards</a>, <a HREF="preferences.htm" CLASS="XRef">Preferences and properties</a>, and
 <a HREF="jface.htm" CLASS="XRef">JFace: UI framework for plug-ins</a>.</P>


 <H3>Team support</H3>


 <p>
 The Team plug-ins allow other plug-ins to define and register implementations
 for team programming, repository access, and versioning.&nbsp; The Eclipse SDK
 includes a CVS plug-in that uses the team support to provide CVS client support
 in the SDK.&nbsp;&nbsp;</p>


 <p>Team support is described in <a href="team.htm">Team support</a>.</p>


 <H3>Debug support</H3>


 <p>
 The Debug plug-ins allow other plug-ins to implement language specific program
 launchers and debuggers.&nbsp;</p>


 <p>Debug support is described in <a href="debug.htm">Program debug and launching
 support</a>.</p>


 <h3 >
 Help System</h3>


 <P >The Help plug-in implements a platform optimized help web server and
 document integration facility.&nbsp; It defines extension points that plug-ins
 can use to contribute help or other plug-in documentation as browsable
 books.&nbsp; The documentation web server includes special facilities to allow
 plug-ins to reference files by using logical, plug-in based URLs instead of file
 system URLs.</P>


 <P >Additional features are provided for integrating help topics in product
 level documentation configurations.</P>


 <P >The help facility is described in <a href="help.htm">Plugging in help</a>.</P>


 <H3>
 Java Development Tooling (JDT)</H3>
 <P >
 The Java development tooling (JDT) plug-ins extend the platform workbench by
 providing specialized features for editing, viewing, compiling, debugging, and
 running Java code.</P>
 <P >The JDT is installed as a set of plug-ins that are included in the SDK.&nbsp;
 The Java Development User Guide describes how to use the Java tools.&nbsp; The JDT Plug-in
 Developer Guide describes the structure and API of the JDT.</P>


 <H3>
 Plug-in Development Environment (PDE)</H3>
 <P >The Plug-in Development Environment (PDE) supplies tools that automate the
 creation, manipulation, debugging, and deploying of plug-ins.&nbsp; </P>


 <P >The PDE is installed as a set of plug-ins that are included in the
 SDK.&nbsp; The PDE Guide describes how to use the environment.</P>


 <p><img border="0" src="../ngibmcpy.gif" alt="Copyright IBM Corporation and others 2000, 2003." border="0" width="324" height="14"></p>


 </BODY>
 </HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//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>Platform SDK roadmap</TITLE>

	<link rel="stylesheet" type="text/css" HREF="../book.css">
	</HEAD>
	<BODY BGCOLOR="#ffffff">
	<H2>
	Platform SDK roadmap</H2>

	<H3>Runtime core</H3>
	<P >
	The platform runtime core implements the runtime engine that starts the platform base and dynamically discovers plug-ins. A
	<b> plug-in</b> is a structured component that describes itself to the system using
	a manifest
	(<b>plugin.xml</b>) file. The platform maintains a registry of installed plug-ins and the function they provide.</P>
	<P >
	Function is added to the system using a common extension model. <b> Extension points</b> are well-defined function points
	in the system that can be extended by plug-ins. When a plug-in contributes an implementation for an extension point, we say that it adds an
	<b> extension</b> to the platform. Plug-ins can define their own extension points, so that other plug-ins can integrate tightly with them.</P>
	<P >
	The extension mechanisms are the only means of adding function to the platform and other plug-ins.
	All plug-ins use the same mechanisms.  Plug-ins provided with the Eclipse
	SDK do not use any private mechanisms in their implementation.</P>
	<P >
	Extensions are typically written in Java using the platform APIs. However, some extension points accommodate extensions provided as platform executables, ActiveX components, or developed in scripting languages. In general, only a subset of the full platform function is available to non-Java extensions. </P>
	<P >
	A general goal of the runtime is that the end user should not pay a memory or performance penalty for plug-ins that are installed, but not used. A plug-in can be installed and added to the registry, but the plug-in will not be activated unless
	a function provided by the plug-in has been requested according to the user's activity.</P>
	<P >
	The best way to get a feel for the runtime system is to build a plug-in. See
	<a HREF="firstplugin.htm" CLASS="XRef"> Plug it in: Hello World meets the workbench</a> to get started
	building a plug-in. Once you have mastered the basics of plug-in writing and you're ready
	to define your own extension points, see <a HREF="arch_extension_points.htm">Defining an extension point</a>.
	</P>


	<H3>
	Resource management</H3>
	<P >
	The resource management plug-in defines a common resource model for managing the
	artifacts of tool plug-ins. Plug-ins can create and modify
	<b>projects</b>, <b>folders</b>, and <b>files</b>, as well as define specialized types of resources.</P>
	<P >
	<a HREF="resInt.htm" CLASS="XRef">Resources overview</a> provides an overview of the resource management system.</P>


	<H3>
	Workbench UI</H3>
	<P >
	The workbench UI plug-in implements the workbench UI and defines a number of extension points that allow other plug-ins to contribute menu and toolbar actions, drag and drop operations, dialogs, wizards, and custom views and editors.</P>
	<P >
	<a HREF="workbench.htm" CLASS="XRef">Plugging into the workbench</a> introduces the workbench
	UI extension points and API.</P>


	<P >
	The workbench UI plug-in also provides frameworks that are useful for user
	interface development.  These frameworks were used to develop the workbench
	itself.  Using the frameworks not only eases the development of a plug-in's
	user interface, but ensures that plug-ins have a common look and feel and a consistent level of workbench integration.</P>


	<P >
	The Standard Widget Toolkit (SWT) is a low-level, operating system independent toolkit that supports platform integration and portable API.
	It is described in
	<a HREF="swt.htm" CLASS="XRef">Standard Widget Toolkit</a>.</P>
	<P >
	The JFace UI framework provides higher-level application constructs for supporting dialogs, wizards, actions, user preferences, and widget management.
	The functionality in JFace is described in
	<a HREF="dialogs.htm" CLASS="XRef"> Dialogs and wizards</a>, <a HREF="preferences.htm" CLASS="XRef">Preferences and properties</a>, and
	<a HREF="jface.htm" CLASS="XRef">JFace: UI framework for plug-ins</a>.</P>



	<H3>Team support</H3>



	<p>
	The Team plug-ins allow other plug-ins to define and register implementations
	for team programming, repository access, and versioning.  The Eclipse SDK
	includes a CVS plug-in that uses the team support to provide CVS client support
	in the SDK.  </p>



	<p>Team support is described in <a href="team.htm">Team support</a>.</p>



	<H3>Debug support</H3>



	<p>
	The Debug plug-ins allow other plug-ins to implement language specific program
	launchers and debuggers. </p>



	<p>Debug support is described in <a href="debug.htm">Program debug and launching
	support</a>.</p>



	<h3 >
	Help System</h3>



	<P >The Help plug-in implements a platform optimized help web server and
	document integration facility.  It defines extension points that plug-ins
	can use to contribute help or other plug-in documentation as browsable
	books.  The documentation web server includes special facilities to allow
	plug-ins to reference files by using logical, plug-in based URLs instead of file
	system URLs.</P>



	<P >Additional features are provided for integrating help topics in product
	level documentation configurations.</P>



	<P >The help facility is described in <a href="help.htm">Plugging in help</a>.</P>



	<H3>
	Java Development Tooling (JDT)</H3>
	<P >
	The Java development tooling (JDT) plug-ins extend the platform workbench by
	providing specialized features for editing, viewing, compiling, debugging, and
	running Java code.</P>
	<P >The JDT is installed as a set of plug-ins that are included in the SDK.
	The Java Development User Guide describes how to use the Java tools.  The JDT Plug-in
	Developer Guide describes the structure and API of the JDT.</P>



	<H3>
	Plug-in Development Environment (PDE)</H3>
	<P >The Plug-in Development Environment (PDE) supplies tools that automate the
	creation, manipulation, debugging, and deploying of plug-ins.  </P>



	<P >The PDE is installed as a set of plug-ins that are included in the
	SDK.  The PDE Guide describes how to use the environment.</P>



	<p><img border="0" src="../ngibmcpy.gif" alt="Copyright IBM Corporation and others 2000, 2003." border="0" width="324" height="14"></p>



	</BODY>
	</HTML>