Browse Prior Art Database

An Eclipse Plug-In to Register Classes Across Plug-Ins, Enabling Improved Code Modularizations

IP.com Disclosure Number: IPCOM000146574D
Publication Date: 2007-Feb-16
Document File: 3 page(s) / 33K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for a mechanism to help facilitate modularization of a feature into a number of replaceable plug-ins. It can also be used from within a single plug-in. Benefits include a solution that is very extensible and promotes code re-use.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

An Eclipse Plug-In to Register Classes Across Plug-Ins, Enabling Improved Code Modularizations

Disclosed is a method for a mechanism to help facilitate modularization of a feature into a number of replaceable plug-ins. It can also be used from within a single plug-in. Benefits include a solution that is very extensible and promotes code re-use.

Background

Currently, plug-ins are only loaded when needed (i.e. when some code which belongs in that plug-in is executed). There is no provision for specifying that the loading of one plug-in should trigger the loading of another plug-in. In some cases, it is desirable that a group of plug-ins are loaded together.

Secondly, if plug-in A depends on plug-in B, then plug-in B cannot depend on plug-in A. This is known as a circular dependency. This is enforced by the Eclipse framework. A common way to avoid these is for one plug-in (in this case plug-in A) to define interfaces which specify the desired behavior of the implementing code. This plug-in also provides an API so that implementers can register with this plug-in. A second plug-in (in this case plug-in B) then implements these interfaces.

The issue is how to register the implementing classes in plug-in B with plug-in A. To avoid the circular dependency, plug-in A cannot explicitly create named classes and invoke registration code in plug-in B. The plug-in loading issue described above means that the registration task cannot be left to plug-in B, because this plug-in may never be loaded. The solution is to use the Eclipse extension point mechanism to allow plug-in A to execute registration code in plug-in B, without being aware of the exact code being executed.

The current state of the art edits an .ini file in plug-in A’s folder, with the name of the classes in plug-in B. Plug-in A then uses reflection to load the classes in plug-in B. While this solution works, it is undesirable because it removes the circular dependency from the code, satisfying the framework but creating a new implicit circular dependency using this .ini file.

General Description

The disclosed method uses the same two plug-ins as in the previous examples (i.e. plug-in A and plug-in B), with plug-in B depending on plug-in A. The disclosed method requires that plug-in A defines an extension point which plug-in B will extend. This extension point allows for the registering of listeners which will listen for events with a specified ID (see Fi...