orbit/index.php - www.eclipse.org/proposals - Git at Google

 <?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'

 $pageTitle 		= "";
 $pageKeywords	= "";
 $pageAuthor		= "";

 ob_start();
 ?>
     <div id="maincontent">
 	<div id="midcolumn">

 <h1>The Eclipse Orbit Project</h1>

 <?php
 include_once($_SERVER['DOCUMENT_ROOT'] . "/projects/fragments/proposal-page-header.php");
 generate_header("The Eclipse Orbit Project");
 ?>

 <h2>Introduction</h2>
 <p>The Eclipse Orbit Project is a proposed open source project under the <a href="http://www.eclipse.org/tools/">Eclipse
     Tools Project</a>.</p>

 <p>This proposal is in the Project Proposal Phase (as defined in the <a href="http://www.eclipse.org/projects/dev_process/">Eclipse
     Development Process</a> document) and is written to declare its intent and
     scope. This proposal is written to solicit additional participation and input
     from the Eclipse community. You are invited to comment on and/or join the
     project. Please send all feedback to the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
     newsgroup</a>.</p>

   <h2>Background</h2>
 <p>The Eclipse community is increasingly embracing and using code from other
     open source projects. Traditionally each Eclipse project has submitted requests
     to use the libraries they need and, upon approval, the libraries have been
     integrated into the project's plug-ins and shipped. This situation presents
   a number of challenges.</p>

   <p><strong>Bundlings:</strong> There are often several ways of &quot;bundling&quot; a
     third party library. A JAR can be wrapped in a bundle or have bundle metadata
     injected
     into it. Bundle names and versions must be selected. Packages must be exported
     with the appropriate visibilities, directives and versions. Libraries that
     consist of multiple JARs may be packaged as one bundle or with a bundle
     for each JAR. In fact, libraries might be simply included directly in an
     existing bundle of the consuming project. Since each team performs this packaging
     independently, the chances are high that
     the approaches taken will diverge. This leads to confusion and challenges
     when composed systems contain incompatible bundlings of the same libaries.</p>
   <p><strong>Componentization:</strong> Often times a &quot;library&quot; is
     actually a composition of other libaries with some additional function. These
     internal libraries
     are often interesting in and of themselves. For example, in Eclipse 3.2 the
     Tomcat plug-in also includes various Apache Commons libraries (logging, collections,
     modeler, etc.), mx4j, Jakarta regexp, servlet API and Jasper. All of these
     JARs are interesting and useful, independent of Tomcat. Under the current
     approach, when a team requests the use of Tomcat, the function as a whole
     is analyzed and approved rather then looking at the individual components.
     In some cases components are not even needed for the required use of the
     requested function. For example, mx4j is not really needed for the Eclipse
     Help use of Tomcat. Further, since these common libraries appear in many
     configurations, they are repeatedly reviewed and analyzed as teams request
     approval for these different configurations.</p>
   <p><strong>Sharing:</strong> Even with a common vision as to how libraries
     should be converted to bundles, each team must duplicate the packaging effort
     and maintenance. Further,
     since the current approach is compartmentalized, it often happens that project
     teams are unaware of the libraries used by each other. This results in gratuitous
     duplication of content in the Eclipse downloads (e.g. Callisto contains
     several copies of Xerces and commons logging, etc.) and version misalignments.
     The lack of transparency also clogs the IP clearance process since teams
     do not know that others are already using the library they need or one which
     provides equivalent function.</p>
   <p><strong>Community:</strong> The Eclipse committer community is not unique
     in this need for bundled versions of existing libraries. Many systems built
     by others include
     the very same code. Again, these libraries are bundled by different people
     (duplicating effort and encouraging divergence) and managed and delivered
     separately (resulting in incompatibilities) and raising the bar for Eclipse
     adoption.</p>
   <h2>Scope</h2>

   <p>This project is intended to be</p>
   <ul>
     <li>a source of approved and bundled content for qualifying Eclipse projects
       and the community as a whole</li>
   </ul>
   <p>This project is <strong>not</strong> intended to</p>
   <ul>
     <li>support code development</li>
     <li>replace the IP process</li>
     <li>do all the packaging work for teams</li>
   </ul>
   <h2>Description</h2>

   <p>This project will provide a repository of bundled versions of
     third party libraries that are approved for use in one or more Eclipse projects.
     The repository will maintain old versions of such libraries to facilitate
     rebuilding historical output. It will also clearly indicate the status of
     the library (i.e. the approved scope of use). The repository will be structured
     such that the contained bundles are easily obtained and added to a developer's
     workspace or target platform.</p>
   <p>One of the key issues with the current situation
       is the inconsistency in naming, versioning and form of bundled third
     party libraries.
       This project
       will, as a mainline activity, provide a repository of approved and bundled
       third party libraries to authorized project teams. This eliminates duplicated
       work and bundle naming, structuring and versioning variations. </p>
   <p>Crucially, no development is carried out in this project. Teams proposing
     the use of a third party library for the first time are able to work with
     the community developed here and other potential users of the library to
     derive an appropriate selection and packaging of the function they need.
     For
     example,
     a team
     may start
     out
     with &quot;a need
     for Jetty.&quot; As we have seen, systems like Jetty often include several
     JARs and a wide variety of infrastructure pieces (e.g. Apache Commons Logging).
     In some cases this additional function is not needed, is already approved
     and available, or has
     special
     packaging needs. Through this project the teams needing function can arrive
     at a mutually agreeable form of the required function. </p>
   <p>It is important to
       note that this project will not be responsible for doing
       the packaging work. That responsibility remains with the teams seeking
     to use the requested library. This project is to act as a hub or focal point
     for people with needs related to third party libraries and those with related
     technical expertise.</p>
   <p>The bundled libraries are retained and made available within the project
     in various ways (e.g. download zip, update site, etc.) for use in the projects
     that
     have
     received
     the appropriate approvals. Note that teams seeking to use a library
       must
     still follow the IP process. For example, the current process calls for all
     third party code use to be cleared by the Foundation. So even if a
     library is approved by the Foundation for use by all projects, project teams
     must notify the Foundation
         of their intentions to use a library. This allows their use to be tracked
     and facilitates version
     synchronization
     (e.g.
     stepping
         up to new releases) as well as notification of issues found with approved
     and previously distributed libraries.</p>
   <h2>Existing standards and projects leveraged</h2>

   <p>This project will mainly use the existing developer infrastructure (e.g.
     CVS, Bugzilla, etc.) to manage library contribution requests and the libraries
     themselves.</p>

   <h2>Organization</h2>

   <p>This project will be organized into one top-level component:</p>

   <ul>
   <li>Bundles: bundlings of approved third party libraries in orbit around
     Eclipse.</li>

   </ul>

     <h3>Proposed initial committers and project lead</h3>

 <p>The initial committers will be drawn from the Eclipse developer community.
   Developers with experience with, interest in, and/or an ongoing need for
   shared code and bundling are potential committers
   on this project. The initial committers are:

 <ul>
   <li>Jeff McAffer (Project Lead)</li>
   <li>Pascal Rapicault </li>
   <li>David Williams</li>
   <li>Simon Kaegi</li>
   <li>Bjorn Freeman-Benson</li>
   <li>John Graham</li>
 </ul>


   <p>Potential commiters are kindly invited to express their interest
     on the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
     newsgroup</a> or via email.</p>
   <p>As projects propose the use of additional third party libraries and their
     use is approved, one of their team will add the bundled libraries to the
     Orbit project. If they
     do not already have a committer on Orbit, they will be able
     to petition for a committer to be added on the basis that they are making
     an initial code contribution to the project. They will also commit to ongoing
     maintenance of that contribution as well as interacting with other Eclipse
     projects which have an interest in the same code base.</p>
   <h3>Interested parties</h3>
   <p>Interest has been expressed by the following projects:</p>
  <ul>
  <li>BIRT</li>
  <li>DTP</li>
  <li>WTP</li>
  <li>Corona</li>
  <li>Dash</li>
  </ul>
  <p>To express support, concern, or constructive opinions regarding the formation
    of this proposed Tools project, you are encouraged to utilize the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
     newsgroup.</a>
    </p>


     <h3>Initial contribution</h3>

     <p>The team will initially look at the set of libraries currently approved
       for use in Eclipse (e.g. those included in Callisto) and attempt to rationalize
       their form. Below is an example list of the bundles to be added/maintained
       in Orbit:</p>
     <ul>
       <li>Various Apache Commons projects including Logging, HTTP Client, Codec</li>
       <li>Apache XMLRPC</li>
       <li>Log4J</li>
       <li>Servlet API 2.3 and 2.4</li>
       <li>MX4J</li>
       <li>Jasper</li>
 </ul>
     <h2>Roadmap</h2>

   <p>This project has no particular deliverables so a standard milestone-based
     roadmap does not make sense here. Having said that, we expect to have an
     initial set of library entries in the database and bundles in the repository
     within the first three months of this project being provisioned. As the goal
     of Orbit is to support the other Eclipse projects through common shared bundles,
     the Orbit Roadmap will be coordinated with significant releases of the major
     Eclipse projects.</p>
   <p>&nbsp;</p>


 </div>
 </div>
 <?php
 	# Paste your HTML content between the EOHTML markers!
 	$html = ob_get_contents();
 	ob_end_clean();

 	# Generate the web page
 	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
 ?>
 }
	<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop'

	$pageTitle = "";
	$pageKeywords = "";
	$pageAuthor = "";

	ob_start();
	?>
	<div id="maincontent">
	<div id="midcolumn">

	<h1>The Eclipse Orbit Project</h1>

	<?php
	include_once($_SERVER['DOCUMENT_ROOT'] . "/projects/fragments/proposal-page-header.php");
	generate_header("The Eclipse Orbit Project");
	?>

	<h2>Introduction</h2>
	<p>The Eclipse Orbit Project is a proposed open source project under the <a href="http://www.eclipse.org/tools/">Eclipse
	Tools Project</a>.</p>

	<p>This proposal is in the Project Proposal Phase (as defined in the <a href="http://www.eclipse.org/projects/dev_process/">Eclipse
	Development Process</a> document) and is written to declare its intent and
	scope. This proposal is written to solicit additional participation and input
	from the Eclipse community. You are invited to comment on and/or join the
	project. Please send all feedback to the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
	newsgroup</a>.</p>

	<h2>Background</h2>
	<p>The Eclipse community is increasingly embracing and using code from other
	open source projects. Traditionally each Eclipse project has submitted requests
	to use the libraries they need and, upon approval, the libraries have been
	integrated into the project's plug-ins and shipped. This situation presents
	a number of challenges.</p>

	<p><strong>Bundlings:</strong> There are often several ways of "bundling" a
	third party library. A JAR can be wrapped in a bundle or have bundle metadata
	injected
	into it. Bundle names and versions must be selected. Packages must be exported
	with the appropriate visibilities, directives and versions. Libraries that
	consist of multiple JARs may be packaged as one bundle or with a bundle
	for each JAR. In fact, libraries might be simply included directly in an
	existing bundle of the consuming project. Since each team performs this packaging
	independently, the chances are high that
	the approaches taken will diverge. This leads to confusion and challenges
	when composed systems contain incompatible bundlings of the same libaries.</p>
	<p><strong>Componentization:</strong> Often times a "library" is
	actually a composition of other libaries with some additional function. These
	internal libraries
	are often interesting in and of themselves. For example, in Eclipse 3.2 the
	Tomcat plug-in also includes various Apache Commons libraries (logging, collections,
	modeler, etc.), mx4j, Jakarta regexp, servlet API and Jasper. All of these
	JARs are interesting and useful, independent of Tomcat. Under the current
	approach, when a team requests the use of Tomcat, the function as a whole
	is analyzed and approved rather then looking at the individual components.
	In some cases components are not even needed for the required use of the
	requested function. For example, mx4j is not really needed for the Eclipse
	Help use of Tomcat. Further, since these common libraries appear in many
	configurations, they are repeatedly reviewed and analyzed as teams request
	approval for these different configurations.</p>
	<p><strong>Sharing:</strong> Even with a common vision as to how libraries
	should be converted to bundles, each team must duplicate the packaging effort
	and maintenance. Further,
	since the current approach is compartmentalized, it often happens that project
	teams are unaware of the libraries used by each other. This results in gratuitous
	duplication of content in the Eclipse downloads (e.g. Callisto contains
	several copies of Xerces and commons logging, etc.) and version misalignments.
	The lack of transparency also clogs the IP clearance process since teams
	do not know that others are already using the library they need or one which
	provides equivalent function.</p>
	<p><strong>Community:</strong> The Eclipse committer community is not unique
	in this need for bundled versions of existing libraries. Many systems built
	by others include
	the very same code. Again, these libraries are bundled by different people
	(duplicating effort and encouraging divergence) and managed and delivered
	separately (resulting in incompatibilities) and raising the bar for Eclipse
	adoption.</p>
	<h2>Scope</h2>

	<p>This project is intended to be</p>
	<ul>
	<li>a source of approved and bundled content for qualifying Eclipse projects
	and the community as a whole</li>
	</ul>
	<p>This project is <strong>not</strong> intended to</p>
	<ul>
	<li>support code development</li>
	<li>replace the IP process</li>
	<li>do all the packaging work for teams</li>
	</ul>
	<h2>Description</h2>

	<p>This project will provide a repository of bundled versions of
	third party libraries that are approved for use in one or more Eclipse projects.
	The repository will maintain old versions of such libraries to facilitate
	rebuilding historical output. It will also clearly indicate the status of
	the library (i.e. the approved scope of use). The repository will be structured
	such that the contained bundles are easily obtained and added to a developer's
	workspace or target platform.</p>
	<p>One of the key issues with the current situation
	is the inconsistency in naming, versioning and form of bundled third
	party libraries.
	This project
	will, as a mainline activity, provide a repository of approved and bundled
	third party libraries to authorized project teams. This eliminates duplicated
	work and bundle naming, structuring and versioning variations. </p>
	<p>Crucially, no development is carried out in this project. Teams proposing
	the use of a third party library for the first time are able to work with
	the community developed here and other potential users of the library to
	derive an appropriate selection and packaging of the function they need.
	For
	example,
	a team
	may start
	out
	with "a need
	for Jetty." As we have seen, systems like Jetty often include several
	JARs and a wide variety of infrastructure pieces (e.g. Apache Commons Logging).
	In some cases this additional function is not needed, is already approved
	and available, or has
	special
	packaging needs. Through this project the teams needing function can arrive
	at a mutually agreeable form of the required function. </p>
	<p>It is important to
	note that this project will not be responsible for doing
	the packaging work. That responsibility remains with the teams seeking
	to use the requested library. This project is to act as a hub or focal point
	for people with needs related to third party libraries and those with related
	technical expertise.</p>
	<p>The bundled libraries are retained and made available within the project
	in various ways (e.g. download zip, update site, etc.) for use in the projects
	that
	have
	received
	the appropriate approvals. Note that teams seeking to use a library
	must
	still follow the IP process. For example, the current process calls for all
	third party code use to be cleared by the Foundation. So even if a
	library is approved by the Foundation for use by all projects, project teams
	must notify the Foundation
	of their intentions to use a library. This allows their use to be tracked
	and facilitates version
	synchronization
	(e.g.
	stepping
	up to new releases) as well as notification of issues found with approved
	and previously distributed libraries.</p>
	<h2>Existing standards and projects leveraged</h2>

	<p>This project will mainly use the existing developer infrastructure (e.g.
	CVS, Bugzilla, etc.) to manage library contribution requests and the libraries
	themselves.</p>

	<h2>Organization</h2>

	<p>This project will be organized into one top-level component:</p>

	<ul>
	<li>Bundles: bundlings of approved third party libraries in orbit around
	Eclipse.</li>

	</ul>

	<h3>Proposed initial committers and project lead</h3>

	<p>The initial committers will be drawn from the Eclipse developer community.
	Developers with experience with, interest in, and/or an ongoing need for
	shared code and bundling are potential committers
	on this project. The initial committers are:

	<ul>
	<li>Jeff McAffer (Project Lead)</li>
	<li>Pascal Rapicault </li>
	<li>David Williams</li>
	<li>Simon Kaegi</li>
	<li>Bjorn Freeman-Benson</li>
	<li>John Graham</li>
	</ul>


	<p>Potential commiters are kindly invited to express their interest
	on the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
	newsgroup</a> or via email.</p>
	<p>As projects propose the use of additional third party libraries and their
	use is approved, one of their team will add the bundled libraries to the
	Orbit project. If they
	do not already have a committer on Orbit, they will be able
	to petition for a committer to be added on the basis that they are making
	an initial code contribution to the project. They will also commit to ongoing
	maintenance of that contribution as well as interacting with other Eclipse
	projects which have an interest in the same code base.</p>
	<h3>Interested parties</h3>
	<p>Interest has been expressed by the following projects:</p>
	<ul>
	<li>BIRT</li>
	<li>DTP</li>
	<li>WTP</li>
	<li>Corona</li>
	<li>Dash</li>
	</ul>
	<p>To express support, concern, or constructive opinions regarding the formation
	of this proposed Tools project, you are encouraged to utilize the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.tools.orbit">eclipse.tools.orbit
	newsgroup.</a>
	</p>


	<h3>Initial contribution</h3>

	<p>The team will initially look at the set of libraries currently approved
	for use in Eclipse (e.g. those included in Callisto) and attempt to rationalize
	their form. Below is an example list of the bundles to be added/maintained
	in Orbit:</p>
	<ul>
	<li>Various Apache Commons projects including Logging, HTTP Client, Codec</li>
	<li>Apache XMLRPC</li>
	<li>Log4J</li>
	<li>Servlet API 2.3 and 2.4</li>
	<li>MX4J</li>
	<li>Jasper</li>
	</ul>
	<h2>Roadmap</h2>

	<p>This project has no particular deliverables so a standard milestone-based
	roadmap does not make sense here. Having said that, we expect to have an
	initial set of library entries in the database and bundles in the repository
	within the first three months of this project being provisioned. As the goal
	of Orbit is to support the other Eclipse projects through common shared bundles,
	the Orbit Roadmap will be coordinated with significant releases of the major
	Eclipse projects.</p>
	<p> </p>


	</div>
	</div>
	<?php
	# Paste your HTML content between the EOHTML markers!
	$html = ob_get_contents();
	ob_end_clean();

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
	?>
	}