Eclipse.org网站中关于Eclipse 3.0 中引入的RCP的介绍
Rich Client Tutorial Part 2
Rich Client Tutorial Part 3
另外，还有IBM采用RCP构建其产品的新闻【转载自：www.eclipsenews.com】
Staunch Eclipse supporter IBM didn't waste any time in adopting the Rich Client Platform features in the new Eclipse 3.0. Big Blue's Lotus Software brand is expected to release this month a new Workplace Client Technology and supporting collaborative applications on top of the Eclipse Rich Client Platform.
"Eclipse is an extensible integration platform," said Rick Wilson, Lotus's architect of the Workplace Client Technology. "It's a powerful model."
IBM's new Workplace Client Technology comprises three server-managed client options that administrators can assign to workers, depending on their computing needs. A Web browser provides a light client for accessing applications, a rich client provides a traditional portal environment for accessing applications, and a microenvironment provides a wireless client for accessing business applications through mobile devices.
Applications that Lotus built for its Workplace platform and also based on Eclipse, including Lotus Workplace Messaging 2.0 and Lotus Workplace Document Management 2.0, can be accessed through the Lotus client model. Those applications also should be available this month.
The model is built using the new Eclipse 3.0 runtime environment features for developing rich client platforms. "Eclipse provided the underpinnings," Wilson said, for the construction of desktop applications.
The Eclipse Foundation made changes to the 3.0 release that make it possible for developers to build applications on top of Eclipse. "We refactored the basic framework within the Eclipse platform," said Mike Milinkovich, executive director of the Eclipse Foundation. New rich client platform capability includes Eclipse's window-based workbench GUI, the dynamic plug-in functional extension mechanism, help subsystem, and update manager.
The Rich Client Platform is a new area for Eclipse, but community interest and user feedback provided the motivation for building the capability into the Eclipse integrated development environment.
Lotus employed Eclipse components like the Standard Widget Toolkit (SWT), JFace, and the workbench to compose user interfaces and create things like rich client platform views and editors in its Workplace Client Technology.
Lotus developers also leveraged the thin client frameworks that traditionally serve browser content in its rich client technology. "The idea is that Lotus Workplace rich client technology can drive the views that show up on the client page through the same model that drives the content for browsers and use a portlet to define the page," Wilson said. "Portlets can be combined with portal access control and user policy to retrieve components needed by the client to realize that page." The platform brings middleware in J2EE to the client side.
This server management component of the Workplace clients and applications also is based on the Eclipse rich client platform, and is a big key of how Lotus products add value to the Eclipse platform as a plug-in. Where the Eclipse Rich Client Platform is unmanaged, Lotus added features for a managed environment. The result is a rich client that doesn't have to roundtrip for data.
"The [Lotus] rich client platform is a browser on steroids," Wilson continued. "We have a truly unique approach doing this."
Lotus also contributed to the Eclipse Foundation's efforts by helping deliver the rich client capability within Eclipse. They helped change the runtime of Eclipse components to make the framework more rich client friendly, Wilson said.
-- Rita-Lyn Sanders, Eclipse News Senior News Editor
IBM的 alphaWorks 发布了Interoperability Tool for Eclipse and .NET WinForms
其功能介绍如下：
What is Interoperability Tool for Eclipse and .NET WinForms?
Interoperability Tool for Eclipse and .NET WinForms is a JavaTM tool that allows hosting of third-party WinForm controls in Eclipse, handling of .NET events, accessing of .NET properties, invoking of .NET methods, and instantiating of .NET objects. This tool can aid in moving to the Eclipse platform while making use of investments in .NET WinForms controls.
This tool allows the following:
- hosting of WinForms controls in Eclipse
- accessing of properties (getting and setting values) of WinForms controls and other common language runtime (CLR) objects from the Java side including properties of complex CLR types
- addition and removal of event listeners
- handling of WinForms controls events from the Java side, including standard events that even require handlers of EventHandler type and events that use specialized (that is, defined by the control developer) type for event arguments
- full access to event arguments on the Java side
- invocation of methods of WinForms controls and other CLR objects from the Java side, including methods that have many arguments and arguments of complex CLR types
- invocation of static CLR methods from the Java side, including methods that have many arguments and arguments of complex types
- construction of instances of CLR types from the Java side, including construction of objects that have many constructors, constructors with many arguments, and constructors with arguments of complex CLR types
- accessing of CLR enumerations from the Java side -- both as values and as enumeration objects.
How does it work?
To host a WinForm control in Eclipse, use a Java helper class and simply specify the assembly that contains the definition of the WinForm control class (either using a strong assembly name or the path to the assembly) and the full control class name. No changes in the WinForm control are required in order to allow hosting in Eclipse.
When the control is hosted in Eclipse, Java helper classes and interfaces can be used in order to access properties of the hosted control and other .NET objects, to handle .NET events, to invoke .NET methods, to instantiate .NET objects, and so on -- all from the Java code running in Eclipse.
In this version, the .NET properties, methods, and events are accessed via string names, so it may be desirable to create wrappers for frequently accessed .NET objects in order to have strongly typed access.
Further information is available in the user manual (also included in the zip file).
【转载】Inside Eclipse 3.0
Inside Eclipse 3.0
by Paul Conte Eclipse is an open-source application platform that has gained considerable industry and Java developer support over the past two years. The impending 3.0 release of Eclipse promises to deepen and broaden that support. Java developers will find extensive new IDE functionality, improved performance in several areas, and some controversial user interface changes.
The biggest news with release 3.0, however, is the restructuring of Eclipse to support many more types of applications than just IDEs and other software development tools. The redesign also includes new plug-in capabilities and better scalability that both tool and other application suppliers can exploit. In this article, I provide a quick look inside release 3.0. (Note that this information is current as of the M8 milestone, which was available in March.)
A Quick Recap
Before exploring release 3.0, it will help to recap the previous Eclipse structure. Figure 1 depicts a simplified view of major Eclipse elements in release 2.x. The Eclipse runtime starts and runs the basic platform, including loading and managing plug-ins. Standard Widget Toolkit (SWT) and JFace provide widgets and other classes to support a graphical user interface. The Workbench provides the familiar window-structured user interface with menus, toolbars, and other associated capabilities. Standard Components includes reusable editors and views that Java Development Tools (JDT) and other plug-ins can use. The Workspace manages resources, most importantly, access to the underlying file system. The variety of other platform components (e.g., Help, Search) provide capabilities that JDT and other tools can exploit. All the items just mentioned are known collectively as the Eclipse Platform.
On top of the platform are a variety of tools. JDT, of course, provides a Java IDE. Plug-in Development Environment (PDE) provides a specialized IDE for creating Eclipse plug-ins. Other tools include plug-ins for C/C++ development (CDT), UML modeling (UML2), and many other tasks. (For a more detailed look at the Eclipse architecture, see "Inside Eclipse and the WebSphere Studio Family" listed in "Where to Learn More," below.)
More Tools for Java Developers
Eclipse first gained popularity as a free and very cool Java IDE. As an open-source project, it's still free, of course; and release 3.0 adds more than just chrome. There are far too many enhancements to cover here, so I'll list just a few. Keep in mind that several changes to the user interface and other non-IDE-specific aspects of Eclipse, which I cover in later sections, also apply to the Java IDE.
- Preliminary support for JDK 1.5 (only some items are supported in 3.0)
- Enhanced Java refactorings, including handling references in Javadoc, context-sensitive Refactor submenu, generalizing the type in a declaration, and creating a factory from a constructor
- Additional options for code generation and style checking, including flagging Javadoc problems
- Additional template support, including new Java templates and support for Ant
- A new code formatter with more than 140 formatting options and that also formats Javadoc
- Expanded key bindings, including cut/copy/paste/select all in dialog fields
- Expanded Quick Assists, including adding an "if" block, assigning a parameter to a new field, and commenting a block of code
- Expanded Quick Fixes, including for build path problems and mismatched parameters
- Improved search that allows regular expressions and finds Java references in Javadoc and JSPs; searches can be run in background, and search results can be grouped by project, package, file, or type
- New ability to define libraries as lists of JAR files and then use a library name(s) in build path
- Selection from list of installed JREs when running a Java program
- Editing files outside the workspace
- More Ant support, including code assist and error display in Problem view
- Selection from list of workspaces during startup
- Workspace auto-refresh when files are modified by external tools
- Most CVS operations run in background
- Expanded extensibility, which allows plug-ins to contribute Quick Fixes and Assists and to participate in or contribute refactorings
Eclipse's Java support was strong from the beginning and just gets better in 3.0. See "Where to Learn More" for a link to complete release information for Eclipse 3.0.
More Than Just a Java IDE
Although Eclipse is written in Java, and JDT is one of the most popular and actively supported subprojects, Eclipse has always officially been "language neutral." Despite this design philosophy, however, release 1.0 clearly had first-class Java support as a primary goal, and no other language received near the attention.
In release 2.0, the Eclipse platform and JDT were refactored to move much of the basic IDE support from JDT to the platform, letting toolsmiths for other languages exploit a wealth of prebuilt features. That helped foster a thriving C/C++ Development Tools (CDT) subproject and a Cobol IDE subproject as well. Contributors have also produced plug-ins for Perl, C#, Python, and a number of other languages.
Since many, if not most, developers in the open-source community use C++ and other non-Java languages, the restructuring of Eclipse 2.0 generated substantial interest in Eclipse as a tools platform for that community. Eclipse's breadth of language support is one of its important competitive advantages against Sun's Java-centric NetBeans tools platform and Microsoft's Visual Studio products, which are limited to C++ and Microsoft's proprietary programming languages C#, J#, and VB.NET.
Rich Client Platform
With release 3.0, Eclipse has been restructured again, but this time in an even more dramatic way. The goal is to broaden Eclipse from a tools platform to an application platform. Among the changes, IDE-oriented and other nonessential user interface features are now grouped in their own optional plug-ins, leaving the Workbench as a "generic" user interface that can support a wide variety of application types.
Non-IDE applications can use a simpler, more compact version of Eclipse, known as the Rich Client Platform (RCP) that includes the generic Workbench, but not features the application doesn't need. Note that even the minimal RCP configuration supports the full Eclipse plug-in architecture. RCP-based applications can still benefit from Eclipse's wealth of capabilities and can optionally choose to include Eclipse plug-ins that support the Workspace (resource management), Text, Help, Search, and other features. In fact, as Figure 2 shows, Eclipse's IDE support is built on RCP just like non-IDE applications.
Figure 3 shows AlterPoint's Integrated Network Environment, an Eclipse-based, non-IDE application that's used for managing network device configuration. As this example illustrates, an RCP-based application can use views, editors, pop-up menus, and any other Eclipse capability. The important thing is that an RCP application isn't required to look like an IDE or install unnecessary platform plug-ins.
Numerous application vendors have expressed interest in RCP. RCP enthusiasts are hopeful that RCP will at last make "desktop Java" a practical alternative. Among the enthusiasts, IBM is making a major commitment by building its Lotus Workplace Client on top of RCP.
Platform Improvements
In addition to the restructuring just described, several other changes are part of RCP. Starting at the lowest level, the Eclipse runtime is now based on the Open Services Gateway initiative (OSGi) standard component framework. Among other things, OSGi specifies how components (e.g., Eclipse plug-ins) should be registered with an application (e.g., Eclipse) for dynamic loading and unloading.
Dynamic plug-ins let Eclipse 3.0 applications add or remove features on the fly, without restarting the Eclipse runtime. This avoids the need to have all possible plug-ins for an application initialized and exposed at startup, an important option for IDEs and other applications that may have lots of available, but infrequently used, plug-ins. (Previous releases of Eclipse didn't actually load executable code for a plug-in until it was first referenced, but Eclipse startup processing still processed all configured plug-in's manifests.) Dynamic plug-ins also facilitate plug-in subscription services that provide automated updates.
Previous versions of Eclipse have supported the concept of application plug-ins that control runtime execution. Release 3.0 expands this concept by allowing an application plug-in to include a WorkbenchAdvisor class that implements methods called by the Eclipse Workbench. This enhancement is mainly to let non-IDE applications have more control over the Workbench user interface, including whether the user interface (i.e., Workbench window) has title, menu, tool, and shortcut bar(s), what menu and toolbar items (if any) are displayed, and so on.
With the rapidly growing number of plug-ins available for Eclipse, the menus, toolbars, Help indexes, and other interface elements can get cluttered with scores of items that are never used. Release 3.0 introduces the concept of activities. Plug-ins can define named activities that users can enable or disable (Figure 4). Only those menu and toolbar items for enabled activities are displayed, as Figures 5A and 5B show.
Another Eclipse 3.0 improvement is increased concurrency of operations. For example, searches can now execute in the background while the user performs other operations. These changes make the Java IDE and (potentially) other applications appear more responsive. To enable wider use of background processing, the 3.0 runtime includes a new job manager and APIs that other plug-ins can call. Plug-ins can queue and monitor job progress as the job manager controls multiple jobs running in a thread pool.
New User Interface
Prerelease milestones for the Eclipse 3.0 Workbench displayed a substantial number of changes to the user interface, including new visual designs (e.g., rounded tabs), repositioned elements (e.g., perspective shortcuts), new ways to navigate (e.g., multiple tab drop-down), and others. There was significant negative reaction when the new user interface was introduced primarily because its look and feel was too different from native user interfaces. Vendors working on RCP-based (non-IDE) applications were especially adamant about the need for a native-looking user interface. In later milestones, many of the user interface changes were either backed out of the Workbench or made optional.
Another important addition to Eclipse 3.0 is a Swing-to-SWT bridge that allows contributors, including vendors who want to deliver RCP-based products, to use plug-ins with Swing components. This is of particular value to vendors who already have a large investment in products that use Swing. The Eclipse platform project team says the Windows version of Swing support will be "production" level in release 3.0, with the Linux version being somewhat less robust initially.
Assessing RCP
RCP has the potential for widespread adoption as the standard platform for Java client or standalone desktop applications. As an application platform, it's important to understand that RCP falls somewhere between the Java Runtime Environment (JRE) and an operating system such as Windows. The initial value of RCP is that it provides a tremendous amount of functionality (e.g., a rich, native-looking GUI framework, text support, integrated help, internationalization and localization) that doesn't come with JRE and for which there is no other widely adopted, multiplatform product or open-source solution. Furthermore, RCP has an exceptional design to support extensibility.
But it's not yet clear whether the Eclipse plug-in framework and application programming conventions will ultimately lead to extensive interoperability among a variety of non-IDE applications running on a user's desktop. Listening to different Eclipse board members and vendors interested in RCP, you hear divergent opinions on whether RCP should remain relatively simple, small, and therefore be replicated in every RCP-based application, or whether RCP should be thought of more the way software development tool vendors think about Eclipse as a whole - a single instance on which many tools or applications run cooperatively.
To fulfill its promise, RCP will also need to incorporate support for a flexible security model, as well as enhancements to support dynamic, centralized configuration and management.
At this point, the level of excitement that RCP has already generated bodes well for future efforts. The outcome depends largely on the continuing willingness of competing vendors to agree to work together on Eclipse as a common, shared application platform.
Migration from Release 2.x
From an Eclipse user standpoint (e.g., a Java developer), there is little to be concerned with in moving to release 3.0, other than the stability of plug-ins. Projects created with Eclipse 2.x can be opened with Eclipse 3.0 and subsequently saved in the 3.0 workspace format.
The situation isn't so simple for plug-in contributors, who should review the Eclipse 3.0 Porting Guide to learn which changes are recommended or required for 2.x plug-ins to work with Eclipse 3.0. In most cases, Eclipse 3.0 provides binary compatibility with release 2.x by leaving API implementations unchanged, by adding "compatibility" layers to route old API calls to new APIs, or by other mechanisms such as special handling of outdated extension point IDs in plug-in manifests. PDE 3.0 also includes a wizard to convert 2.x plug-in manifests to conform to 3.0 specifications. Upgrading plug-ins to 3.0 can be aided by a new launcher for JUnit tests that supports debug tracing and other capabilities.
Eclipse has survived its infant stage and appears to be entering its youth with vigor. Java programmers, and increasingly programmers in other languages, have a lot to savor with the latest release. My crystal ball says Eclipse has a bright future as a tools platform, and it's Sun who should be worrying about whether its NetBeans Java development platform will wither.
The picture isn't so clear when Eclipse is considered as an application platform. RCP is a very good and necessary start, but many hurdles remain. A lot rides on Eclipse because nothing else on the horizon appears to offer any reasonable alternative as a Java (or for that matter any non-Windows) desktop/client application platform. That alone provides a lot of motivation for vendors and open-source participants to help Eclipse thrive.
Paul Conte is a senior technical editor for e-ProMag.com, iSeries NEWS, and eclipse news. He is president of PCES, an educational and consulting practice in Eugene, Oregon. You can e-mail Paul at pconte@e-promag.com.
| Where to Learn More |
- For a thorough introduction to the initial Eclipse architecture and tools platform strategy, see "Inside Eclipse and the WebSphere Studio Family," March 2002 and article ID 1708 at e-ProMag.com.
- The Eclipse Foundation home page is at eclipse.org.
Eclipse 3.0 Help files are contained in the free download for the latest Eclipse Project release. The Help files contain the following: - Workbench User Guide
- Java Development User Guide
- Platform Plug-In Developer Guide (contains the Eclipse 3.0 Porting Guide)
- JDT Plug-In Developer Guide
It's somewhat difficult to ferret out up-to-date information about release 3.0 on this site. To find what's in the latest Eclipse 3.x release or milestone, look on the home page under "What's New" for topics that begin "New and noteworthy features in Eclipse Project." For example, for Release 3.0 M8 (the latest build as of this article's writing), see download2.eclipse.org/downloads/drops/S-3.0M8-200403261517/eclipse-news-M8.html. Note that the "What's new" documents for release 3.0 builds are not cumulative. As of this writing, the most recent comprehensive list of committed and proposed items for release 3.0 was dated January 30, 2004, and can be found here: eclipse.org/eclipse/development/eclipse_project_plan_3_0.html#Deliverables. A list of Eclipse 3.0 documents, including Bugzilla-maintained discussions, for release 3.0 proposals can be found here: eclipse.org/eclipse/development/eclipse_proposals_3_0.html. A list of Rich Client Platform documents can be found here: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home /rcp-proposal/rich_client_platform_facilities.html. You can get a feel for the concerns raised when the new user interface was introduced, and subsequent responses, by looking at Bugzilla report number 52875 here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=52875. |
【转载】Eclipse readies 'rich client' software
Eclipse readies 'rich client' software
By
Martin LaMonica Staff Writer, CNET News.com
http://news.com.com/2100-7344-5242038.html Story last modified June 21, 2004, 9:00 AM PDT
The Eclipse open-source software foundation next week plans to release software that will offer developers an alternative to Windows for delivering desktop applications. Eclipse 3.0, which is freely available software aimed at Java programmers, includes tools for building and running so-called rich-client applications, which have more sophisticated graphics capabilities than standard Web browser-based applications.
The Eclipse software, which was originally developed by IBM, also provides a single "framework" that different development tools can plug into.
Using Eclipse, a programmer can combine several tools--such as those for testing, managing source code and modeling--all within a single application.
IBM spun off Eclipse in February. The group, now an independent open-source foundation, named an executive director, Mike Milinkovich, in May. The popularity of the Eclipse software has grown rapidly, catching on with independent software providers who write Eclipse plug-ins and with independent Java programmers.
The Eclipse 3.0 update includes enhancements to improve developer productivity and changes to accommodate two different methods for building user interfaces with Java. Tools written to conform with the user interface "widget" toolkit, called Swing, can plug into the Eclipse software, which uses the SWT (standards widget toolkit), Milinkovich said.
The new features are aimed squarely at programmers, but the implications of the rich-client capabilities in the Eclipse software have broader implications, according to analysts. Eclipse is designed to let businesses build or acquire graphics-rich applications that run on different operating systems.
Having more desktop application choices could ultimately pose a threat to Microsoft's dominance in desktop applications, said Stephen O'Grady, an analyst at RedMonk.
"Eclipse is a central point of control, presentation and (application) delivery that abstracts out some of the operating-system intricacies...and makes the longer-term question of the operating system less important," O'Grady said.
IBM recently announced a Workplace initiative that uses the Eclipse client software to run different desktop productivity applications, such as a spreadsheet and messaging, on multiple operating systems, such as Linux, Windows and Macintosh. If other independent software vendors start to use the Eclipse client "platform," corporate customers will have greater flexibility in choosing their desktop operating system, O'Grady said.
So far, few application providers have written their software to work with the Eclipse client, though.
Typically, big companies that want to deploy an application to run on multiple desktop operating systems will use Web portal software, which delivers back-end information through a Web browser. Those Web front ends have their limitations, though.
"The Web is archaic--it's 10 years old. The needs of people are not being met by mere HTML applications," said Java programmer Rick Ross, founder of Javalobby, a Java developer community. "(Eclipse) is saying that the software is bigger than just an IDE (integrated development environment)."
The Eclipse foundation houses a number of development-related open-source initiatives not related to Java, including projects built around the C and C++ programming languages. Another Eclipse initiative for managing the different phases of the application-development process called Hyades will release an update in tandem with Eclipse 3.0.