incubator/archive/layering/index.html - gerrit/www.eclipse.org/equinox - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 	<title>The Equinox Project - Framework Layering</title>
 	<link rel="stylesheet" href="http://eclipse.org/default_style.css" type="text/css">
 </head>
 <body>
 <center>
 	<font class=indextop>equinox</font><br>
 	<font class=indexsub> eclipse runtime exploration</font><p></p>
 	<a href="../index.html">[home]</a>
 	<a href="../../documents">[documents]</a>
 	<a href="../../downloads.html">[downloads]</a>
 	<a href="../areas.html">[work areas]</a>
 	<a href="../resources.html">[resources]</a>
 	<a href="../../faq.php">[faq]</a>
 </center>
 <br>
 <table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
   <tr>
     <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF">
       Framework Layering</font></b></td>
   </tr>
 </table>
 <p>
 Eclipse 3.0 re-based its plugin support on an Eclipse implementation of the
 <a href="http://www.osgi.org">OSGi</a> framework and thereby improved its ability
 to make changes dynamically.
 The framework implements the framework specification in OSGi Release 3 with some
 non-standard extensions in the area of class loading.
 These extensions were proposed to the Core Platform Expert Group (CPEG) of the
 OSGi.
 Since then the CPEG has taken these extensions and investigated a more unified
 proposal that fits in better with the OSGi Release 3 specification.
 They are targetting the unified proposal for OSGi Release 4 which is likely
 to be published in 2005.
 </p>
 <p>
 The aim of the Equinox "layering" work is to prototype the unified proposal.
 Practical experience gained in Equinox is being fed into the CPEG specification
 work.
 Ultimately, it is hoped to merge this prototype into the Eclipse base so that
 the Eclipse OSGi framework implementation will be completely standard and
 therefore an excellent platform for developing and running standard OSGi
 applications.
 </p>
 <p>
 The background to the unified proposal is as follows.
 The only standard Java mechanism for
 constructing large scale modular software is the class loader.
 A class loader defines a namespace which maps class names to classes.
 A class loader controls the extent to which its namespace overlaps that
 of other class loaders by delegating class load requests to other class loaders.
 Unfortunately, class loaders are difficult to program and error prone.

 The proposal provides a simpler way of constructing modular software.
 Each module is defined by metadata which specifies:
 <ul>
 <li>a class path which determines the classes and packages provided by the
 module,</li>
 <li>the packages that the module exports, and</li>
 <li>packages that the module imports from other modules or modules from which
 all exported packages should be imported.</li>
 </ul>

 The framework automatically constructs a class loader for each module that
 needs to run.
 The framework also delegates class load requests between class loaders
 according to their import/export metadata.
 </p>
 <p>
 So far work has concentrated on extending the resolver interfaces, implementing
 a new resolver capable of supporting an extended import/export syntax, and
 making other changes to the rest of Eclipse to start to make it work with the
 new resolver. The latest code is in
 <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/phase2/?cvsroot=Technology_Project">
 cvs</a>.
 The OSGi framework and the new resolver are both in the
 <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/phase2/org.eclipse.osgi/?cvsroot=Technology_Project">
 org.eclipse.osgi</a> project. If you prefer to grab this code using anonymous
 cvs, see the Equinox <a href="http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/resources.html">Resources</a> page.
 </p>
 <p>The layering team is doing regular <a href = "../../downloads.html">builds</a> based off of the Eclipse 3.1 milestone builds.</p>
 <p>There is also a <a href="./standalone.html">standalone OSGi modularity framework</a> with a
 simple interface for overlaying existing code with OSGi bundles.</p>
 <p>Please direct comments or questions to
 <a href="mailto:equinox-dev@eclipse.org">equinox-dev@eclipse.org</a>.</p>
 <table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
   <tr>
     <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF">
       Contributors</font></b></td>
   </tr>
 </table>
 <ul>
 <li>Simon Burns</li>
 <li>Glyn Normington</li>
 <li>Steve Poole</li>
 <li>Thomas Watson</li>
 <li>Jennifer Fogell</li>
 </ul>

 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	<html>
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	<title>The Equinox Project - Framework Layering</title>
	<link rel="stylesheet" href="http://eclipse.org/default_style.css" type="text/css">
	</head>
	<body>
	<center>
	<font class=indextop>equinox</font><br>
	<font class=indexsub> eclipse runtime exploration</font><p></p>
	<a href="../index.html">[home]</a>
	<a href="../../documents">[documents]</a>
	<a href="../../downloads.html">[downloads]</a>
	<a href="../areas.html">[work areas]</a>
	<a href="../resources.html">[resources]</a>
	<a href="../../faq.php">[faq]</a>
	</center>
	<br>
	<table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF">
	Framework Layering</font></b></td>
	</tr>
	</table>
	<p>
	Eclipse 3.0 re-based its plugin support on an Eclipse implementation of the
	<a href="http://www.osgi.org">OSGi</a> framework and thereby improved its ability
	to make changes dynamically.
	The framework implements the framework specification in OSGi Release 3 with some
	non-standard extensions in the area of class loading.
	These extensions were proposed to the Core Platform Expert Group (CPEG) of the
	OSGi.
	Since then the CPEG has taken these extensions and investigated a more unified
	proposal that fits in better with the OSGi Release 3 specification.
	They are targetting the unified proposal for OSGi Release 4 which is likely
	to be published in 2005.
	</p>
	<p>
	The aim of the Equinox "layering" work is to prototype the unified proposal.
	Practical experience gained in Equinox is being fed into the CPEG specification
	work.
	Ultimately, it is hoped to merge this prototype into the Eclipse base so that
	the Eclipse OSGi framework implementation will be completely standard and
	therefore an excellent platform for developing and running standard OSGi
	applications.
	</p>
	<p>
	The background to the unified proposal is as follows.
	The only standard Java mechanism for
	constructing large scale modular software is the class loader.
	A class loader defines a namespace which maps class names to classes.
	A class loader controls the extent to which its namespace overlaps that
	of other class loaders by delegating class load requests to other class loaders.
	Unfortunately, class loaders are difficult to program and error prone.

	The proposal provides a simpler way of constructing modular software.
	Each module is defined by metadata which specifies:
	<ul>
	<li>a class path which determines the classes and packages provided by the
	module,</li>
	<li>the packages that the module exports, and</li>
	<li>packages that the module imports from other modules or modules from which
	all exported packages should be imported.</li>
	</ul>

	The framework automatically constructs a class loader for each module that
	needs to run.
	The framework also delegates class load requests between class loaders
	according to their import/export metadata.
	</p>
	<p>
	So far work has concentrated on extending the resolver interfaces, implementing
	a new resolver capable of supporting an extended import/export syntax, and
	making other changes to the rest of Eclipse to start to make it work with the
	new resolver. The latest code is in
	<a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/phase2/?cvsroot=Technology_Project">
	cvs</a>.
	The OSGi framework and the new resolver are both in the
	<a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/phase2/org.eclipse.osgi/?cvsroot=Technology_Project">
	org.eclipse.osgi</a> project. If you prefer to grab this code using anonymous
	cvs, see the Equinox <a href="http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox-home/resources.html">Resources</a> page.
	</p>
	<p>The layering team is doing regular <a href = "../../downloads.html">builds</a> based off of the Eclipse 3.1 milestone builds.</p>
	<p>There is also a <a href="./standalone.html">standalone OSGi modularity framework</a> with a
	simple interface for overlaying existing code with OSGi bundles.</p>
	<p>Please direct comments or questions to
	<a href="mailto:equinox-dev@eclipse.org">equinox-dev@eclipse.org</a>.</p>
	<table BORDER=0 CELLSPACING=0 CELLPADDING=2 WIDTH="100%" >
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF">
	Contributors</font></b></td>
	</tr>
	</table>
	<ul>
	<li>Simon Burns</li>
	<li>Glyn Normington</li>
	<li>Steve Poole</li>
	<li>Thomas Watson</li>
	<li>Jennifer Fogell</li>
	</ul>

	</body>
	</html>