The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.

Packaging

In order to package the RCP I suggest to use feature-based products as described in a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.

Exporting the product

Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory.

Posted in eclipse, enterprise systems, rcp | 2 Comments »

Abstract

After providing the basic example of how the Eclipse Common Navigator Framework (CNF) can be used to display custom content, this article focuses on the main feature of the CNF – the contribution of content to the same navigator by several independent plug-ins. First of all, I will explain some minor changes introduced to the CNF in the Gallileo Edition, then I will focus on the content itself and finally provide an overview of how the action contributions can be provided. In the end of the post, some ideas on control of dynamic content are explained.

Gallileo Changes

There are two noticeable changes in the CNF that have been added with Eclipse Galileo. The return type of the method (more…)

Posted in eclipse, java, rcp | 8 Comments »

Abstract

The Eclipse Platform provides a very rich API for the development and configuration of plug-ins and RCPs. It does this in two ways: by providing the corresponding classes and interfaces or by using the extension point mechanism. During the development the question arises, how to develop own extension points and how those plug-in interfaces look like. This article summarizes some of my experiences with developing plug-ins extension points.

Introduction

The extensive use of extension points is the standard approach during the development of own plug-ins and Eclipse-based applications. Especially, in the 3.x branch, the Eclipse Developers introduced tons of new extension points, primarily for the user interface, moving towards the declarative definition of the UI. Even if the the topic of the definition of extension points is covered in several books and articles, it is a bit challenging to come up with a clean extension point design for a particular scenarios, especially for beginners. This has to do with the specific way, how the Eclipse platform handles extensions.

In order to have a concrete scenario, lets assume that a small RCP application consisting of two plug-ins is being developed. The application prints out the time every ten seconds. One plug-in is responsible for the functionality of the time generation (lets call it the Core plug-in) and another, for the presentation of the results of the first one (lets call it UI plug-in). The separation of code in UI and non-UI plug-ins is a common practice and the standard question is, how to to pass data between the two. In general we assume, that the UI plug-in depends on the Core plug-in.
(more…)

Posted in eclipse, java, rcp | 5 Comments »

Abstract

Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the  compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

• Domain-specific component framework
• Methods for master data management
• Infrastructure services: authentication, authorization, communication, security, printing, reporting
• Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.
(more…)

Posted in eclipse, enterprise systems, java, rcp | 5 Comments »

Abstract

This article describes some efforts to use the Common Navigator Framework (CNF). In doing so it incorporates the information already covered in different articles, but also focuses on the specific use case of providing a view of something completely unrelated to the platform resources. So the aim is not to add some content to the “Project Explorer” which is an example of resource-oriented CNF usage, but to provide a view on a completely own data model.

Introduction

A very common UI element to represent data is a tree view. In SWT this UI element is implemented using the Tree widget. Following the MVC design pattern in the TreeViewer, JFace simplifies the usage of the Tree widget by delegating the task of content adoption to the ContentProvider and the label production to the LabelProvider (and using Sorters and Filters for sorting and filtering). Still for a single representation one has to construct a viewer and configure it with a corresponding Label- and ContentProvider. Further code reduction can be achieved by the use of WorkbenchContentProvider and WorkbenchLabelProvider if the elements can be made adaptable (implement IAdaptable interface and making them first-class workbench citizens). This approach is helpful, if the elements has to be displayed in several different viewers (e.G. Table). Finally, the Common Navigator Framework (CNF) is a facility provided by the Eclipse Platform which allows the usage of multiple Label- and ContentProvider on the same view. The providers are activated and used dynamically and can be configured declarative or programmatically. The advantage of CNF approach is the ability to combine elements in one view which have different origins(e.G. contributed by different plugins). CNF is used in Eclipse IDE: e.G. “ProjectExplorer” and “CVS Synchrnoize” are both instances of the CNF.

The usage of the CNF in your own application for purposes of representation of resource-based (and usually file-based) content is discussed in articles of Micael Elder in detail. The main idea is to instantiate the view, declare the default content and UI interface and make some additions where needed. This post has a different aim: we start from scratch and represent completely resource unrelated content. Before diving in the implementation details, some overview is provided.

UI Overview

There are many things which can be configured by the usage of CNF and it is beyond the scope of this post to cover all of them. Still there are several things to understand before the actual code can be written. The user interacts with a View which shows the data elements. Which elements are shown is configured using the navigation content extensions. Shown elements can be filtered with Filters and sorted using Sorters on behalf of the user. There are some predefined actions and their positions in the UI and corresponding extension points to contribute to. . The actions for Working sets, Customize View, Link with editor belong to this category. The user can also right-click on particular element in the tree and sees a popup-menu. This menu is configured based on the content element and can be (is) contributed by several plugins. The action contribution is also covered in the article series from Michael Elder.

(more…)

Posted in eclipse, java, rcp | 13 Comments »

Eclipse RCP by default promotes the usage of a single application window with multiple views and editors inside. This default can be changed to multi-windowed application. The platform API offers several methods to operate with multiple application windows:

package org.eclipse.ui;
...
public interface IWorkbench ...
{
/**
* Retrieves the number of opened windows
*/
public int getWorkbenchWindowCount();
/**
* Retrieves the array of opened windows
*/
public IWorkbenchWindow[] getWorkbenchWindows();
/**
* Openes a new window with given perspective
*/
public IWorkbenchWindow openWorkbenchWindow(String perspectiveId,
IAdaptable input) throws WorkbenchException;
/**
* Performs a perspective switch in a given window
*/
public IWorkbenchPage showPerspective(String perspectiveId,
IWorkbenchWindow window, IAdaptable input)
throws WorkbenchException;
...

}

Using this API, opening of new windows seems simple. For example one could define a perspective, that is always opens in a new window.

Closing windows is generally performed by calling close method on the IWorkbenchWindow instance.

package org.eclipse.ui;
...
public interface IWorkbenchWindow ...
{
  /**
   * Closes the window
   */
  public boolean close();
}

Unfortunaly, there is no elegant way to find out which window are you in. A workaround which uses Eclipse internal API works fine for WorkbenchWindow, which is a standard platform implementation of the IWorkbenchWindow interface.

/**
 * Determines if the window is a root window
 * @param window a window to be checked
 * @return true, if the window is considered to be a root window
 */
public static int getWindowId(IWorkbenchWindow window)
{
// HACK: note this could change in future
  if (window != null && window instanceof WorkbenchWindow))
  {
    return ((WorkbenchWindow)window).getNumber();
  }
  return -1;
}

The initial application window gets the id 1. The lookup in the implementation reveals that the internal method finds the smalles unused positive number and assigns it to the newly opened window. If you do not want to rely on this algorithm, just hash the newly created windows by they ids.

Posted in eclipse, java, technology | No Comments »