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"

(RCP)
Line 26: Line 26:
  
 
=== RCP ===
 
=== 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.  First, enabling broader use of RCP on smart devices such as PDAs and enhancing the abilities of RCP to work in these environments.  Second, making RCP as easy as possible to use so that it's easier for application developers to adopt.
+
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.   
 +
# Enabling broader use of RCP on smart devices such as PDAs and enhancing the abilities of RCP to work in these environments.   
 +
# 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.
 +
# Additional PDE enhancements to facilitate developing and deploying RCP-based applications, and for OSGi bundle manifest tooling.
  
 
=== Embedded Device Software ===
 
=== Embedded Device Software ===

Revision as of 15:44, 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

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.

Particularly important for development tools.

Linux

Deployment.

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

Developing apps on a device

Developing the device itself

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:

  • Hardware and Target OS bring-up capabilities
  • Target OS independent debugging and profiling with extensible OS visibility
  • Remote target launching, exploring, and management
  • Configuring, building, deploying, and managing target images using multiple tool chains
  • Embedded GUI design
  • Target simulation and emulation capabilities
  • 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

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

64 bit CPU

Scaling Up

Performance.

Enterprise Ready

Software As Service

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.

  • Large Scale Installations
The Update manager is a fantastic tool for a person updating his/her own installation. However in big organisations, for various reasons, the organisation might want to make sure that large numbers of users have 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 developers to be up-to-date, on a different level some organsiations might want a policy of stricter 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 some kind of Eclipse internal policy management which I suspect might be very hard to do? Still, the convenience thing would already most likely be very helpful in containing maintenance costs for large installations?
  • Team support for Eclipse
In this context what I mean be "team support" are features to enable a developer to get started as part of a (new or exisiting) team. This could include many of the above central management aspects: making sure that the person has the correct software set-up, 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. 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.

Ease of Deployment

Ease of Managability

Servicability

Design for Extensibility

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 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).

I18N

  • Language Packs
  • I18N capable

Using an open and transparent process, create, maintain and deliver language packs translated into multiple languages in a timely manner. The 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