| <!-- ----------------------------------------------------------------------------- --> |
| <!-- |
| Project: Eclipse Test and Performance Tools Platform Project |
| --> |
| <!-- ----------------------------------------------------------------------------- --> |
| |
| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <title>Eclipse Themes and Priorities</title> |
| <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
| <link rel="stylesheet" type="text/css" href="eclipse_style.css" > |
| <style type="text/css"> |
| <!-- |
| .style1 {font-size: 12px} |
| --> |
| </style> |
| </head> |
| <body> |
| |
| <div id="page_header"><FONT class=indextop>Eclipse Requirements Council: |
| Themes and Priorities 1.0 (OLD) </FONT> <BR> |
| </div> |
| <div id="page_sub_header">the eclipse development process</div> |
| |
| <br> |
| <div id="section_header">IMPORTANT NOTE</div> |
| <div class="content"> |
| <p><br> |
| THIS DOCUMENT IS SUPERCEDED BY <a href="roadmap_v2_0/index.php">ROADMAP v2.0</a> |
| </div> |
| |
| <div id="section_header">Introduction</div> |
| <div class="content"> |
| <p><br> |
| This document captures the inputs to the Eclipse Requirements |
| <img border="0" src="PC/external.gif" width="20" height="16"><a href="../council.html">Council</a> as of this date. The |
| inputs are from three major sources:</p> |
| <ol> |
| <li> Strategic Members of the Eclipse Foundation,</li> |
| <li> the Project Management Committees (PMCs), and</li> |
| <li> the general membership through the input collected at Eclipse members meeting held |
| in Fort Worth, Texas.</li> |
| </ol> |
| <p><br> |
| The themes were generated by collecting requirements from the above sources and then |
| synthesizing themes from the various inputs.<br> |
| <br> |
| </p> |
| </div> |
| <br> |
| <div id="section_header">Fundamental Principles</div> |
| <br> |
| <div class="content"> |
| <p><br> |
| These are our fundamental principles, which span all of the themes outlined below.</p> |
| <ul> |
| <li>Eclipse projects provide exemplary (show by example) implementations and |
| extensible frameworks. Examples target open source implementations such as CVS, |
| Ant, JBoss, JOnAS, Mono, and Tomcat.<br> |
| </li> |
| <li> We will aim for release-to-release binary compatibility for API |
| clean plug-ins for at least the last major release.<br> |
| </li> |
| <li> The platforms supported by each project are determined by the specific project. Each |
| project must keep its support for all supported platforms current and publicly announce otherwise.</li> |
| <li> The Eclipse community will relentlessly re-factor code to improve components and |
| make them available for public consumption.<br> |
| </li> |
| </ul> |
| </div> |
| <br> |
| <div id="section_header">Themes and Priorities</div> |
| </br> |
| <div class="content"> |
| <p><br> |
| These themes are not in priority order.</p> |
| <h4>Scaling Up</h4> |
| <p>This refers to the need for Eclipse to deal with development and deployment on a larger and |
| more complex scale. Increasing complexities arise from large development teams distributed |
| in different locations, large source code bases and fragile build environments that have been |
| developed incrementally over time, the dynamic nature of new source code bases and their |
| interaction with configuration management, and build environments involving many different |
| tools and build rules. For example, static analysis in development environment should be |
| incremental instead of computing the dependencies from scratch every time.</p> |
| <p> This requires:</p> |
| <ul> |
| <li>Performance improvements in memory footprint, user perceived |
| response times, and start-up times as the complexity and number of |
| projects, files, users, and plug-ins grow (10X-100X over the next two |
| years).<br> |
| </li> |
| <li>Being able to deal with extremely large projects and large workspaces. This may |
| include a more efficient way to simultaneously manage multiple workspaces.<br> |
| </li> |
| <li> A performance profiling and instrumentation infrastructure to help plug-in developers |
| assess, root-cause, and fix performance issues. TPTP can be leveraged for this. </li> |
| </ul> |
| <h4>Enterprise Ready</h4> |
| <p>Changes to Eclipse to ease adoption by large development |
| organizations. As the size of a development organization grows, the manner in which an |
| organization as a whole uses Eclipse changes. For example,</p> |
| <ul> |
| <li> Which features/capabilities get installed and are visible.</li> |
| <li> Provide an ability for installed features/capabilities to be locked by an enterprise for its users</li> |
| <li> Allow users to share their preferences and make sure that all user configuration |
| settings are stored in a preference file</li> |
| <li> Make it easier to configure workspaces (e.g. in order to be distributed to team |
| members)</li> |
| <li> Improve development time integration across development roles |
| <ul> |
| <li>Provide support for development time work flow. (e.g. an extensible process |
| flow that could enforce a series of activities for a code branch commit – code |
| review, statistics, unit test).</li> |
| </ul> |
| </li> |
| <li> This would include support for more roles and tools (e.g. extend our current Java only |
| development model to cover defects, test cases, requirements)</li> |
| <ul> |
| <li> Make this integration more seamless</li> |
| </ul> |
| <li>Improve configurability (e.g. of capabilities) to allow for the definition of unique roles</li> |
| <li>Improve integration between Eclipse’s build system and external build systems and |
| deployment tools</li> |
| <li>Provide a mechanism that makes it easier for Eclipse tools that do not require a full “headless” Eclipse to execute. This includes the notion of a command line interface<br> |
| for Eclipse</li> |
| </ul> |
| <p><em>Deployment: </em>We need changes to Eclipse to enable deployment of Eclipse based |
| applications across the enterprise. This includes monitoring capabilities, developing models of |
| the components and interactions in the application delivery chain, enhancing support of |
| logging, tracing, and statistical models to enable prompt troubleshooting in a distributed |
| environment, increasing interoperability with enterprise security infrastructure, and report |
| generation. Develop a robust mechanism to ensure that products from different companies |
| that work well separately on an Eclipse package work well together.</p> |
| <p><em>Manageability: </em>JMX is rapidly becoming a standard for Java developers who want to |
| incorporate manageability into their applications during development time. The new J2SE 1.5 |
| JDK includes JMX support. Support for JMX design patterns which enable developers to |
| model manageability and drive transformation to JMX MBeans and other management |
| technologies. Additionally, Eclipse support for JMX creation, via wizards, code assist or other |
| tooling, and monitoring would help in automating the management instrumentation process. </p> |
| <h4>Design for Extensibility: Be a Better Platform</h4> |
| <p> Within the Eclipse community, many development projects are defining new development |
| platforms on top of the Eclipse Platform project. Concrete examples include the Web Tools |
| Platform Project and the Test and Performance Platform Tools Project. It is recognized, |
| however, that some function is not strictly required by the base but is important to exist at the |
| base platform level in order to enable other platforms to succeed. Examples include common |
| undo stack functionality, an extensible navigator, improved command framework, etc. </p> |
| <p>Opening the internal JDT (UI) interfaces would enable tools to seamlessly facilitate and |
| interact with the JDT core and UI layers. Examples are: the parsing and AST functionality for |
| static code analysis within and outside of Eclipse, extensions of the syntax (SQLJ), having |
| control over and re-using the Java editor (SQLJ, protected code blocks, Java editor as one |
| page of a multi-page editor, ...). </p> |
| <p>Loosening the strong file orientation by providing an abstraction layer of logical objects would |
| allow to extend the proven Eclipse features to tools working on a higher abstraction level. One |
| example would be the 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).</p> |
| <h4>Embedded Development</h4> |
| <p> Instead of plug-in providers each developing their own plumbing to launch, profile, debug, and |
| manage remote agents running on target, the requirement is for Eclipse platform to provide a |
| consistent, uniform plumbing to address this infrastructure need. These capabilities can be |
| leveraged for:</p> |
| <ul> |
| <li> Target OS independent debugging.</li> |
| <li> Target OS independent profiling.</li> |
| <li>Loading and launching on remote targets</li> |
| </ul> |
| <p>We need a generic control centre - API to configure, setup, connect and monitor any type of |
| target, node or network.</p> |
| <h4>Rich Client Platform</h4> |
| <p>The Eclipse RCP is a Java-based application framework for the desktop. Building on the |
| Eclipse runtime and the modular plug-in story, it is possible to build applications ranging from |
| command line tools to feature-rich applications that take full advantage of SWT's native |
| platform integration and the many other reusable components. This theme includes work:</p> |
| <ul> |
| <li> To provide PDE support for developing and deploying RCP-based applications in |
| enterprise environments</li> |
| <li> To improve our ability to construct rich user interfaces through improvements to SWT |
| and JFace</li> |
| <li> To evolve RCP for embedded devices</li> |
| <li> To improve authentication and security (user authentication and credentials, role |
| based security, and role-based plug-in loading)</li> |
| <li> To improve the capabilities of the UpdateManager to manage deployed rich |
| application desktops.</li> |
| </ul> |
| <h4>Simple to Use |
| </h4> |
| <p>The Eclipse components need to not only provide the features that advanced users demand, |
| but also be something that most users find simple to use. This theme includes ease-of-use |
| reviews of existing features, and work that helps make Eclipse-based products simple to use |
| for users with widely-varying backgrounds and skill sets. |
| Focus on ease of use through enhanced user documentation, tutorials, white papers, |
| demonstrations, and a wide range of enhancements to the user interface to streamline basic |
| processes and clarify concepts and terminology. For example, BIRT has a goal of making a |
| user productive in 15 minutes.</p> |
| <h4>Enable Consistent Multi-language Support</h4> |
| <p> The original vision of Eclipse was to accelerate the creation of IDEs. Experience with |
| the CDT and COBOL projects have shown that there is still a lot of work to do to make it |
| simpler to create language-specific IDEs. Our vision is to create an environment where a |
| limited number of well-defined extension points for compilers, parsers, debuggers, building, |
| launching, etc. will allow language IDE developers to simplify the process of creating Eclipse-based |
| offerings.</p> |
| <p> Plug-in providers have a strong need for an abstract development toolkit where a variety of |
| plug-ins (e.g., editor, managed build system, debugger) can be plugged in for all development |
| environments including Java. This is more efficient than integrating each plug-in with each |
| separate development environment. Focus on an abstract development toolkit improves |
| componentization and consistency across development environments, makes each |
| component within the development environment more robust, and adds flexibility to increase |
| the reach of Eclipse to a variety of development environments (e.g., Fortran, COBOL). This |
| opens up 1:1 relationship between add-in component and development environment into a |
| richer m:n relationship. </p> |
| <p>This support includes the following features:</p> |
| <ul> |
| <li>Make it easier to create language specific tools in a consistent way. Consistent |
| generic components / APIs to add languages.</li> |
| <li> Generic APIs – not Java-specific</li> |
| <li> Ability to create tools for other languages</li> |
| <li> Prescribe model for language toolkit which should provide public APIs sufficient for |
| tools builders.</li> |
| </ul> |
| <h4>Appealing to the Broader Community</h4> |
| <p> This theme includes work that grows deeper roots into the various OS-specific communities, |
| spreads Eclipse to additional operating environments, virtual machines, application |
| development and deployment lifecycles, vertical market-specific frameworks and builds |
| bridges to other open source communities. This can be accomplished through additional |
| documentation and more usable documentation, engineering engagements, marketing and an |
| extensive outreach program incorporating trade shows, user groups, and press and analyst |
| relations opportunities.</p> |
| <ul> |
| <li><strong>Improve SWT consistency across operating systems </strong></li> |
| </ul> |
| <blockquote> |
| <p>The plug-in providers noted differences in the behaviour of Eclipse |
| on Windows and Linux. Window systems sometimes differ in things like the |
| exact sequence of events reported for a given action. This kind of |
| inconsistency can result in platform specific code and increased testing |
| requirements. More consistent behavior would ease the burden on plug-in |
| providers. Over 80% of Eclipse downloads are for Windows, followed by |
| ~20% for Linux, and a very small fraction are for operating systems such |
| as the Macintosh, AIX, Solaris, and HP-UX. </p> |
| </blockquote> |
| <ul> |
| <li><strong>Swing – SWT Interoperability</strong></li> |
| </ul> |
| <blockquote> |
| <p> Allow existing Swing/AWT applications to work seamlessly inside the SWT (Eclipse) |
| environment. While the ability to make Swing components function within SWT UI’s |
| was made available in Eclipse 3.0, the ability to integrate complete applications |
| requires additional efforts. |
| For true interoperability between Eclipse and other Swing-based development |
| environments, Eclipse also needs to enable an SWT application to run within a Swing |
| environment.</p> |
| </blockquote> |
| <ul> |
| <li><strong> J2SE 5 support with JDT</strong></li> |
| </ul> |
| <ul> |
| <li><strong> Provide basic web services tools</strong></li> |
| </ul> |
| <blockquote> |
| <p> Eclipse should provide basic tools and frameworks for supporting the construction, |
| deployment and management of web service applications. Example tools include: |
| UDDI browser, XSL/T editor, and WSDL tools.<br> |
| </p> |
| </blockquote> |
| </div> |
| <div id="section_header">Appendix</div> |
| <div class="content"> |
| <p><br> |
| This section contains valuable inputs which were received by the Requirements Council but |
| which are out of scope for this document. Our intent with this document is to focus on |
| common themes for development across the Eclipse projects. These comments, although |
| very helpful, are primarily requirements of the Eclipse projects laid upon their own build |
| infrastructure and also upon the IT infrastructure provided by the Eclipse Foundation. </p> |
| <h4>Eclipse Development Process Improvements </h4> |
| <h5>Robust distributed build processes: </h5> |
| <p>Improve build processes to enable multiple organizations to build and test for a variety of |
| hardware platforms, operating systems, JVMs, and other virtual machines. Work out a better |
| process for independent contributors to synchronize contributions with the PMCs and core |
| development teams. Today the process for synching with project teams is somewhat ad hoc |
| and does not account for contributions that come in outside of the core build cycles. It’s also |
| difficult for contributors who are working independently of the core development team to get |
| their code contributions built and tested prior to public availability on the eclipse.org web site.</p> |
| <h5>Release Engineering: </h5> |
| <ul> |
| <li>Improve the automated test suites. This includes more complete coverage for the |
| Platform as well as ensuring all other subprojects have a set of automated test cases. |
| TPTP currently uses its own infrastructure to define the tests and publish results to a |
| CVS repository on a regular weekly basis. Perhaps, this infrastructure can be |
| leveraged across Eclipse.</li> |
| <li>Ensure all subprojects are available from the Eclipse update manager site.</li> |
| <li>Provide a utility to help assess whether or not a plug-in is “API clean”</li> |
| </ul> |
| <h5> Increase roadmap visibility: </h5> |
| <p>Make Eclipse project roadmaps visible, up-to-date and longer. The Eclipse community needs |
| clearer visibility on what features are coming over a 12 month time horizon. This will allow |
| Eclipse developers to better plan contributions, Eclipse Add-in providers to better determine |
| where to innovate, and Eclipse users to better determine whether their requirements will be |
| satisfied by Eclipse. Today many available roadmaps are out-of-date and provide no more |
| than 3 months of visibility. </p> |
| <h5>Project Start-up Guidelines: </h5> |
| <p>When new projects are started in the Eclipse community, guidelines and "cheat sheets" are |
| needed to help those projects during the startup process with regards to required Eclipse |
| Foundation infrastructure and Eclipse community infrastructure. The overall goal of these |
| guidelines is to enable new projects to come online faster and easier, and to reduce the |
| overhead on existing project members to help in this process. The guidelines should include |
| specific actions and how these should be accomplished (for example, who to contact and |
| what information is needed in order to get the required CVS repository up and running). |
| Topics would include:</p> |
| <ul> |
| <li>Process for establishing committers and completing all required legal steps</li> |
| <li>Code management recommendations and steps</li> |
| <li>Creating a CVS project repository for the project</li> |
| <li>Project web site pages recommendations, structure conventions, and update process</li> |
| <li>Build process recommendations and steps</li> |
| <li>Community infrastructure recommendations and steps (e.g. newsgroups)</li> |
| </ul> |
| <p> </p> |
| </div> |
| |
| <div id="section_header">Contributors</div> |
| <div class="content"> |
| <p> </p> |
| <table align="center" width="400" border="1"> |
| <tr> |
| <th scope="col"><div align="left">Name</div></th> |
| <th scope="col"><div align="left">Member</div></th> |
| </tr> |
| <tr> |
| <td><div align="left" class="style1">Paul Clenahan</div></td> |
| <td><div align="left" class="style1">Actuate</div></td> |
| </tr> |
| <tr> |
| <td><span class="style1">John Kellerman</span></td> |
| <td><span class="style1">IBM Corporation</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Anurag Gupta</span></td> |
| <td><span class="style1">Intel</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Derrick Keefe</span></td> |
| <td><span class="style1">QNX Software</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Par Emanuelsson</span></td> |
| <td><span class="style1">Ericsson AB</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Philip Ma</span></td> |
| <td><span class="style1">Hewlett-Packard Company</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Michael Bechauf</span></td> |
| <td><span class="style1">SAP</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">Rich Main and<br> |
| Todd Williams</span></td> |
| <td><span class="style1">Add-In Provider Board Representatives</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">John Wiegand</span></td> |
| <td><span class="style1">Platform PMC</span></td> |
| </tr> |
| <tr> |
| <td><span class="style1">David Williams</span></td> |
| <td><span class="style1">Web Tools PMC</span></td> |
| </tr> |
| <tr> |
| <td><div align="left" class="style1">Mike Norman</div></td> |
| <td><div align="left" class="style1">Test&Performance PMC</div></td> |
| </tr> |
| </table> |
| <p> </p> |
| </div> |
| |
| <div id="section_header">Acknowledgements</div> |
| <div class="content"> |
| <p> <br> |
| Anurag Gupta (Intel) wrote the first draft of the themes. |
| <p> Mike Milinkovich (EF) and John Kellerman (IBM) reviewed the draft and provided feedback – |
| their input has been incorporated into a second draft. |
| <p> The second draft was reviewed by Paul Clenahan (Actuate), John Kellerman (IBM), Anurag |
| Gupta (Intel), Derrick Keefe (QNX), Par Emanuelsson (Ericsson AB), and Philip Ma (HP) and |
| incorporated into a third draft. |
| <p> The third draft was reviewed at the Eclipse Requirements Council F2F meeting on Nov 30 |
| and that feedback has been incorporated by Anurag Gupta into the fourth draft . |
| </p> |
| <p> </p> |
| |
| </div> |
| <div id="copyright"></div> |
| </body> |
| </html> |
