Splitting org.eclipse.ui

Kai-Uwe Maetzel, Daniel Megert
23th September 2002


This documents describes how the plug-in org.eclipse.ui is split into a combination of plug-ins and fragments. There are three major reasons for splitting the plug-in:

State of Splitting

The new structure is not yet final. It is a starting point for the Platform UI team and the Platform Text team to evolve the system towards a stable and mature structure. It is expected that the number of plug-ins and fragments can be kept stable whereas package fragments and classes will probably be moved around. For now, the UI independent text infrastructure (org.eclipse.text) should be considered the only new plug-in that can be listed as prerequisite and that offers API. The other plug-ins and fragments are for now implementation details of org.eclipse.ui. This will change as the structure becomes more stable i.e. some of the new plug-ins will become API.


Splitting as been guided by the approach to consider plug-ins as packaging units and therefore to use plug-ins only when an according packaging can be anticipated. Thus, classes that are expected to be shipped  together should not be in different plug-ins. This approach keeps the class loading overhead caused by the splitting lower than putting every possible unit into its own plug-in. Classes of a plug-in and its fragments are loaded by the same class loader. Taking this approach we end up having six plug-ins and two fragments.

Required Changes

The following changes need to be made in order to get a JFace framework which only depends on SWT: Note: There remains a dependency to Xcerces due to org.eclipse.jface.dialogs.DialogSettings.

Open Issues


The consequences of this new structure are mostly visible in the build process and the workspace setup. It is necessary to update all plug-ins and fragments in the map files with the correct version numbers. The build process responsibility is distributed according to the ownership of the plug-ins and fragments.