Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/Packaging/Proposal"

Line 15: Line 15:
 
To reiterate, the goal of this project is to enable multiple entry-level distributions of Eclipse that respectively provide turnkey environments for very specific developer communities found in the broader embedded systems marketplace.  As an initial objective, the project will focus upon a ''generic packaging methodology'' that can be adopted and tailored on a case-by-case basis to the needs of specific distributions serving particular market segments.
 
To reiterate, the goal of this project is to enable multiple entry-level distributions of Eclipse that respectively provide turnkey environments for very specific developer communities found in the broader embedded systems marketplace.  As an initial objective, the project will focus upon a ''generic packaging methodology'' that can be adopted and tailored on a case-by-case basis to the needs of specific distributions serving particular market segments.
  
From a technical perspective, the new [http://wiki.eclipse.org/Equinox/p2 Equinox p2] provisioning infrastructure affords an obvious starting point for any methodology formulated through this project's efforts.  The clean separation between installation metadata and the installable artifacts themselves, for example, seems particularly responsive to some of the challenges of bundling legacy tools/content outlined earlier; the metadata and artifacts, as a case in point, might respectively carry different licenses as well reside at different sites.   
+
From a technical perspective, the new [http://wiki.eclipse.org/Equinox/p2 Equinox p2] provisioning infrastructure affords an obvious starting point for any methodology formulated through this project's efforts.  The clean separation between installation metadata and the installable artifacts themselves, for example, seems particularly responsive to some of the challenges of bundling legacy tools/content outlined earlier; the metadata and artifacts, as a case in point, might respectively carry different licenses as well reside at different sites.  The ability to hierarchically compose installable units into larger (installable) entities also faciliates re-use of common sub-elements (say, a particular compiler) across multiple turnkey distributions ultimately served from different sites.
  
  

Revision as of 13:55, 9 March 2009

DSDP Packaging (D-Pack) is a proposed open-source sub-project under the Device Software Development Platform top-level project. The goal of this project is to enable multiple entry-level distributions of Eclipse that respectively provide turnkey environments for very specific developer communities found in the broader embedded systems marketplace.

This proposal is in the Pre-Proposal Phase as defined in the Eclipse Development Process document and follows the Eclipse Proposal Guidelines. It is written to declare the intent and scope of the project, as well as to solicit additional participation and input from the Eclipse and embedded developer community. You are invited to comment upon and/or join this project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.dsdp.dpack newsgroup.

Background

While usage of Eclipse continues to grow amongst embedded software developers, creation of turnkey (entry-level) downloads satisfying the needs of this community—not unlike what's currently provided through the EPP project—remains elusive for a number of reasons. For starters, the community of embedded software developers will always remain a very fragmented one due to the sheer diversity of the underlying hardware platforms targeted by this community—ranging from powerful multi-core SOCs capable of supporting Linux and Java, right down to resource-constrained 8/16-bit MCUs with little/no runtime support. Given this diversity, attempts to create a single distribution of Eclipse targeting embedded software developers would clearly become futile.

Making matters worse, any usage of Eclipse for embedded software development invariably requires integration of legacy host tooling (such as a compiler) along with legacy target content (such as an RTOS) specific to the hardware platform at hand. Not only do these elements maintain an existence outside of the Eclipse IDE per se, these tools and content often carry non-EPL licenses that would ultimately preclude their provisioning from any eclipse.org server.

Responding to this reality, turnkey Eclipse distributions (bundling the necessary tools/content) which serve specific segments of the embedded community do, in fact, exist outside of eclipse.org—whether provided by software vendors such as Wind River or by silicon vendors such as Texas Instruments. The Wascana project at SourceForge–providing a turnkey Eclipse/CDT distribution for Windows development–follows a similar pattern.

Scope

To reiterate, the goal of this project is to enable multiple entry-level distributions of Eclipse that respectively provide turnkey environments for very specific developer communities found in the broader embedded systems marketplace. As an initial objective, the project will focus upon a generic packaging methodology that can be adopted and tailored on a case-by-case basis to the needs of specific distributions serving particular market segments.

From a technical perspective, the new Equinox p2 provisioning infrastructure affords an obvious starting point for any methodology formulated through this project's efforts. The clean separation between installation metadata and the installable artifacts themselves, for example, seems particularly responsive to some of the challenges of bundling legacy tools/content outlined earlier; the metadata and artifacts, as a case in point, might respectively carry different licenses as well reside at different sites. The ability to hierarchically compose installable units into larger (installable) entities also faciliates re-use of common sub-elements (say, a particular compiler) across multiple turnkey distributions ultimately served from different sites.


Organization

References

Back to the top