Plug-in development using WebSphere Studio in a team environment

By using the Eclipse Plug-in development environment (Eclipse Plug-in Development environment,pde), WebSphere Studio enables you to quickly develop powerful plug-ins. However, when you start a new plug-in development project, the features and choices you have in front of you will make it impossible for you to choose. This article provides a practical overview of these issues that you will face during plug-in development, whether you choose to use WebSphere Studio or vanilla Eclipse.

Introduction

The dependencies of Plug-ins and the way they relate to shared items within a team are more complex to understand. Perhaps the power and depth of Eclipse means that you will have a lot of difficulty learning. This article focuses on common problems that you will encounter when you develop a shared plug-in environment, and how to take advantage of the Eclipse plug-in development environment (PDE).

This article starts with an overview of the Eclipse plug-in framework and code sharing using the source code repository, and then provides examples of issues that can occur when you share plug-in code across teams, such as when building path control. The establishment of the environment and how to maximize the use of Ibm®websphere®studio application Developer V5.1.1 and V5.1.2 (hereinafter referred to as application Developer) will also be discussed. The content discussed here also applies to the Eclipse 2.1 environment on which application Developer is based. The difference between early and late versions of Eclipse will be mentioned-to check your product version, select Help =>about.

Eclipse Plug-in Architecture

Application Developer is based on the open source Eclipse project. Eclipse itself consists of multiple layers of functionality (a function is a set of Plug-ins). The power of Eclipse is much more than adding new functionality through Plug-ins. It expands the contributions of other people in ways that have never been thought of before. This requires a robust mechanism to declare and download Plug-ins. The following examples will be used to describe the details. The sample shop application is shown below. These four plug-ins (logs, data warehouses, business logic, and user interfaces) all contain an installable feature:

Figure 1. Plug-in association structure for sample applications

The arrows between the frames indicate dependencies between plug-ins (there is also a correlation between the core Eclipse components, such as Org.eclipse.ui). Each plug-in defines it in the manifest (plugin.xml) file with the library file (. JAR file) and the dependencies of other plug-ins. The key point here is that class loading is controlled by Eclipse, and each plug-in has its own class loader. A plug-in can only load those resources that are already defined by its own manifest.

Source code Repository

Application Developer provides a variety of ways to share code, such as Project interchange Files. However, in any team development project, SCM (Software Configuration Management) or a repository such as CVS is required so that all team members can stay in sync. Application Developer provides powerful features (such as Synchronize on the team context menu). See the Resources section for links to articles about this topic.

Share all

Sharing in a repository can be a huge benefit. Theoretically, for each plug-in, you will store:

source file (. java)

source data files (. classpath, Plugin.xml,. Project, and other similar files)

Unit test files (data and source code)

Referenced binary library

Build file (build.properties or Build.xml)