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 "RequirementsCouncil06TP"

(Platform Support)
(Embedded Device Software)
Line 48: Line 48:
 
=== Embedded Device Software ===
 
=== Embedded Device Software ===
 
This theme describes additions to Eclipse to provide standardization and extensibility to enable embedded tools providers, real-time operating system providers, semiconductor vendors, and hardware developers to create embedded-specific capabilities on top of standard Eclipse projects such as the Platform, JDT, eRCP, CDT, and TPTP. These capabilities should include the following.  
 
This theme describes additions to Eclipse to provide standardization and extensibility to enable embedded tools providers, real-time operating system providers, semiconductor vendors, and hardware developers to create embedded-specific capabilities on top of standard Eclipse projects such as the Platform, JDT, eRCP, CDT, and TPTP. These capabilities should include the following.  
* Provide an embedded debug model implementation of the new Eclipse 3.2 platform API’s.  This debug model will enable integration of debug engines from multiple vendors for debugging hardware and bringing up operating systems.  This model will also enable vendors to integrate target simulation and emulation environments with Eclipse.
+
* Provide an embedded debug model implementation of the new Eclipse 3.2 platform API’s.  This debug model will enable integration of debug engines from multiple vendors for debugging hardware and bringing up operating systems.  This implementation will also enable vendors to integrate target simulation and emulation environments with Eclipse.
 
* Build a remote target launching, exploring, and management framework with extensible real-time operating system visibility.  This framework will provide complex launching capabilities for deploying multiple target images to multiple devices.
 
* Build a remote target launching, exploring, and management framework with extensible real-time operating system visibility.  This framework will provide complex launching capabilities for deploying multiple target images to multiple devices.
* Enable C++ GUI application design, build, and deployment for mobile devices running any operating system.  Enable vendors to customize run-time libraries for their operating systems.
+
* Enable C++ GUI application design, build, and deployment for mobile devices running any operating system.  Also enable vendors to customize run-time libraries for their operating systems.
* Provide mobile Java application development support for J2ME mobile profiles, including device and emulator frameworks, application build and deployment, code obfuscation, code optimization, image signing, and localization.
+
* Provide mobile Java application development support for J2ME mobile profiles, including extensible frameworks for devices and emulators and capabilities for application build and deployment, code obfuscation, code optimization, image signing, and localization.
 
* Release the embedded Rich Client Platform.
 
* Release the embedded Rich Client Platform.
 
* Enable mobile Linux application development, including design, development, debug, and deployment of cross-compiled applications.
 
* Enable mobile Linux application development, including design, development, debug, and deployment of cross-compiled applications.

Revision as of 16:32, 27 June 2006

Timeline

This is the discussed at the March 2006 Requirements Council meeting at EclipseCon.

  • 2006 – Late April – Team email on “key themes/trends” that matter (Collaborate on the WIKI if technically possible to keep within the council)
  • 2006 – Early May – Conference call re: email brainstorm, first draft for council
  • 2006 – June – Council meeting
  • 2006 – July – Requirements council delivers “DRAFT: themes and priorities”, with preamble (or some cool name for this) i.e.,”mid course planning advice”, “areas of focus” or “trends and recommendations”. Plus – each theme streamlined and “why this theme is important”
  • 2006 – September – Members at meeting get interactively involved in themes v3
  • 2006 – October – Council meeting
  • 2006 – December – Council meeting, and Board approved Roadmap v3

Resources

http://www.eclipse.org/org/councils/roadmap_v2_0/themes_v2_0.php

Brainstorming

The following are major themes and priorities currently under discussion. Please add and edit at will. For each theme and priority, be sure to add details as to why this is a priority.

Active Themes

While Eclipse has been very successful with Java developers on Windows systems, we need to provide platform support for additional existing and upcoming platforms:

Platform Support

Vista

When VISTA is released there will be a number of efforts to port Windows applications. This presents an opportunity for organizations who will take the opportunity to migrate to the more ubiquitous and portable Eclipse platform. In order to leverage the opportunity as much as possible, it is essential that relevant Eclipse projects support and leverage VISTA. For example, Avalon APIs need to be implemented in SWT.

Vista will be important as both a platform used by developers, as well as one to which the resultant applications and/or products will be deployed.

Linux

Linux continues to grow in market share as a platform for projects at all levels. We need to offer strong support for Linux on two dimensions:

  • As a deployment platform for applications developed using Eclipse technology
  • As a platform used by developers as their primary working environment

J2SE 6 (Mustang)

Support for the next generation of the Java platform.

Mac OS X

Mac OS X is used in many development, open source and end user environments and is a very active community. Eclipse needs to provide some level of support for users of this platform.

RCP

RCP adoption has been strong by the ecosystem in 2006. The goal is for projects to support and use the Eclipse RCP as much as possible.

Aside from general use of RCP, there are two additional dimensions to this theme.

  1. Enabling broader use of RCP on smart devices such as PDAs and enhancing the abilities of RCP to work in these environments.
  2. Making RCP as easy as possible to use so that it's easier for application developers to adopt.

The Equinox project was created to provide additional focus on the OSGi component model within Eclipse.

  1. Additional PDE enhancements to facilitate developing and deploying RCP-based applications, and for OSGi bundle manifest tooling.

Embedded Device Software

This theme describes additions to Eclipse to provide standardization and extensibility to enable embedded tools providers, real-time operating system providers, semiconductor vendors, and hardware developers to create embedded-specific capabilities on top of standard Eclipse projects such as the Platform, JDT, eRCP, CDT, and TPTP. These capabilities should include the following.

  • Provide an embedded debug model implementation of the new Eclipse 3.2 platform API’s. This debug model will enable integration of debug engines from multiple vendors for debugging hardware and bringing up operating systems. This implementation will also enable vendors to integrate target simulation and emulation environments with Eclipse.
  • Build a remote target launching, exploring, and management framework with extensible real-time operating system visibility. This framework will provide complex launching capabilities for deploying multiple target images to multiple devices.
  • Enable C++ GUI application design, build, and deployment for mobile devices running any operating system. Also enable vendors to customize run-time libraries for their operating systems.
  • Provide mobile Java application development support for J2ME mobile profiles, including extensible frameworks for devices and emulators and capabilities for application build and deployment, code obfuscation, code optimization, image signing, and localization.
  • Release the embedded Rich Client Platform.
  • Enable mobile Linux application development, including design, development, debug, and deployment of cross-compiled applications.
  • Provide embedded testing capabilities - monitoring, profiling, and unit testing.

Ease Of Use

  • Provide a "Java IDE" download (~54MB) in addition to the SDK download (121MB).
    • Most Eclipse users don't require PDE or source
  • Provide a more instructive download page "What do you want to do?"
    • Java application development: Platform+JDT
    • Eclipse application development: Eclipse SDK
    • JEE application development: Platform+JDT+WTP
    • Create, edit, and run reports: Platform+BIRT
    • (other combinations involving tools)
  • Add icon to welcome page that opens the update manager (on Callisto site?)
  • More robust/tolerant Java editor
The Java editor is quite intolerant of broken code - its better than it used to be but could be better.


Technology Trends

Extending to be Life-cycle Platform

Web 2.0 and AJAX

  • Authoring

Multi-Core CPU

Due to power constraints, there is a trend towards multiple cores on a CPU instead of merely increasing the CPU frequency.

  • Enable tools to build products and applications that work well with multi-core CPU hardware.
  • Leverage multi-core CPU hardware in projects.

64 bit CPU

Diverse application software such as payroll, datawarehousing, and reporting now routinely manipulate large amounts of data that exceed 2GB. Using 64-bit CPUs enables these applications to manipulate large data in memory rather than having to write and read intermediate results to much slower disks.

Scaling Up

Performance.

Enterprise Ready

The Update Manager is a fantastic tool for a person updating his/her own installation. Preference Import & Export and Team Project Files further extend Eclipse in this regard. However in large organisations, for various reasons, the organisation might want to make sure that large numbers of users have and maintain similar Eclipse set-ups. This could involve various aspects of the system, eg. what Eclipse components are installed, what preferences and other values are set etc. On one level this could be a convenience thing so that this would enable central management to help developer workstations be up-to-date, on a different level some organsiations might want a policy of strict control where the maintenance of the environment is also about enforcing a development policy and toolset, this would need more work in that it would require Eclipse internal policy management.

Further Enhance Update Manager

The Eclipse Update Manager provides initial technical capabilities to enable delivering software as a service. This capability can be leveraged more to provide updated components across Eclipse projects to developer desktop in an asynchrous fashion without the developer having to do a manual dependency analysis.

  • Dependency (across Update Sites?)
  • Version-level Conflicts?
  • Easier to access rollback?

Ease of Deployment, Servicability & Managability of Large Scale Installations

  • Zero-conf discovery of Update Site & Pref/Config Repositories
  • Shared Hierarchical Configuration (First-class Preferences, Perspective Configurations, Team Share Preferences, Update Site Preferences, etc.)
  • Simplified Update of the Platform Bits
  • Plug-in Cross-Dependency Awareness / Version Incompatibility

Facilitated On-Boarding

Features to enable a developer to get started as part of a (new or exisiting) team. This could include

  1. making sure that the person has the correct software set-up,
  2. that the software settings are appropriate for the team and then finally (which falls outside perhaps of the above management) that the projects and the project content can be easily "bootstrapped" to the new workstation.

Example Story: Here the ultimate goal could be that once a "team manager" has been told the IP address of a new member's PC, he would have 10 minutes later a fully configured Eclipse workstation with all the project's Eclipse project and all related settings on his/her machine.

Design for Extensibility

  • Within the Eclipse community, many development projects are defining new development platforms on top of other Eclipse projects. Concrete examples include the Business Intelligence Reporting Tools, the Data Tools, and the Device Software Development Platform projects. It is recognized, however, that some function is not strictly required by the underlying projects but are important to enable other platforms to succeed. This theme also includes effort to assure platform integrity.
  • Solid Integration across multiple products supported from release-to-release
    • Assuring API compatibility release-to-release, including
      • Robust API documentation
      • API tools to detect use of internal interfaces
    • Assuring release-to-release migration (e.g., resources, workspaces)
    • Provide a better experience for the co-existence of offerings from multiple vendors in a single Eclipse installation
      • Permit offering identity to show through (e.g. On the splash screen)
      • Allow for license management of "products" (i.e. Aggregations of features)
      • Allow for updating and uninstalling of products
      • Integrated diagnostic capabilities - e.g. When a user encounters a problem, providing assistance on the where the problem originated, which product
      • Provide an RCP-based installation utility that can install Eclipse plus other non-Eclipse artifacts. This needs to be integrated with Update Manager
  • Expose meaningful building block APIs
  • Open the internal JDT (UI) interfaces to enable tools to seamlessly facilitate and interact with the JDT core and UI layers. For example the parsing and AST functionality.
  • Enhance the Debug API to enable seamless debugging across mixed (Java+native) languanges
  • Provide a more flexible mechanism that can be used to debug non-Java programs. This is both in the debug model and presentation
  • Provide for debugging a system comprised of multiple languages
  • Loosen the strong file orientation by providing an abstraction layer of logical objects to allow one to extend Eclipse functionality tools working at a higher abstraction level. For example,
    • Marker and Quick fix capabilities. In this connection a less restrictive structuring of projects would be desirable (some tools would like to structure and group projects in a more hierarchical way).
    • Contributing actions on models that do not have a one-to-one mapping to files on the user’s hard disk. This would, for example, allow a team provider’s repository operations to be made available on logical artifacts.
    • Existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on.
  • Enable task automation
    • Provide access to Eclipse APIs and resources from scripting languages
    • Provide the capability to record, edit, playback macros, representing a set of user interface actions.

Authoring, deploying and managing components/features/etc.

  • Bolster OSGi Adoption (via authoring assistance, etc.)
  • Headless Execution
  • Server-side Runtime Infrastructure
  • Core & UI Split

Persistent & Pervasive Themes

Accessibility Compliance

Every project should support and make a statement on their accessibility compliance. In the U.S., this means Section 508 compliance; in the European Union, this is the Web Accessibility Initiative of the World Wide Web Consortium (W3C).

Internationalization & Localization

Every project should support both internationalization and localization:

  • Internationalization (I18N)
    Each project should be able to work in an international environment, including support for operating in different locales and processing/displaying international data (dates, strings, etc.).
  • Localization
    Each project should provide an environment that supports the localization of the technology (i.e. translation). This includes, but is not limited to, ensuring that strings are externalized for easy translation.

Where possible, projects should use an open and transparent process to create, maintain and deliver language packs translated into multiple languages in a timely manner. The primary languages to consider are: English, Simplified Chinese, Traditional Chinese, Japanese, French, German, Spanish.

Deferred Themes

Consistent Multi Programming Language Support

The original vision of Eclipse was to accelerate the creation of IDEs. There is a lot of work to do to make it simpler to create language-specific IDEs. Our vision is to:

  • Make it easier to create language specific tools in a consistent way
  • Enabling source files written in multiple languages within the same project.

Themes To Be Extracted Into Other Themes

Appeal to a Broader Community

Back to the top