Jump to: navigation, search

Plug-in refactoring

This document describes the proposed refactoring of JSF tooling plugins for JSF 1.0 (Europa, WTP 2.0 release alignment).

Policy Objectives

The JSF plugin components are organized with the following main goals:

  1. UI functionality should be separated into its own plugin(s) as much as possible. This allows adopters (and us) to use pieces of the framework without depending a particular user interface dependency.
  2. User-visible features that cannot be disabled by adopters (i.e. an SSE extension that contributes content assist proposals) should be centralized in such a way that they can be easily unbundled.
  3. Library specific meta-data should be kept separate to allow it to be unbundled in favour of adopter preferences.
  4. In the interest of promoting possible future reuse, functionality that could be used outside of JSF tooling should be kept separate from functionality that is JSF-specific.

Policy Guidelines

  1. Plugins with "ui" in there names are used to encapsulate

Plugin Catalog


Purpose: Contains all "JSF neutral" shared framework code. This is code that is currently only used by JSF tooling, but which may benefit a wider Eclipse audience becase it is not JSF specific. Examples include Unified EL tooling, tag library meta-data and context resolver frameworks.

Can contain: API or non-API code. Should not contain UI code or extension points that create new UI (i.e. editors, views). Also should not contain extension points that create JSF-specific extensions.

Can depend: *Must not* have any plugin dependencies on JSF tooling. Plugin must be usable by external adopters without including any other JSF code.

Refactored from: org.eclipse.jst.jsf.context.* (some possible exclusions on symbols), org.eclipse.jst.jsf.contentmodel.annotations, org.eclipse.jst.jsf.core (meta-data support, some type support), org.eclipse.jst.jsf.validation.el (only the generic operators), possibly some of org.eclipse.jst.pagedesigner.jsp.core.


Purpose: Contains main "core JSF" framework code. This is where most of the non-UI JSF tooling framework should go. Exceptions are for large stand-along non-UI plugins such as the faces-config model.

Can contain: API or non-API code. Should not contain UI code or extension points that create new UI.

Can depend: Must *only* depend on jsf.common and non-JSF dependencies.

Refactored from: org.eclipse.jst.jsf.core, org.eclipse.jst.jsf.contentassist.el (those parts that support content assist but that don't do direct UI contributions), org.eclipse.jst.jsf.validation.el (those parts that support JSF validation, but that do not create direct UI contributions), org.eclipse.jst.jsf.metadataprocessors, org.eclipse.jst.jsf.taglibprocessing (excluding specific tag meta-data), org.eclipse.jst.jsf.designtime (excluding specific tag meta-data), org.eclipse.jst.jsf.facesconfig an org.eclipse.jst.jsf.facesconfig.edit.


Purpose: Contains shared UI dependencies.

Can contain: API or non-API. Should not contain stand-alone UI; purpose is sharable JSF UI. Should not create new UI extensions but may create new extension points.

Can depend on: org.eclipse.jst.jsf.common, org.eclipse.jst.jsf.core, org.eclipse.jst.jsf.facesconfig, non-JSF dependencies only.

Refactored from: org.eclipse.jst.jsf.facesconfig.common, org.eclipse.jst.pagedesigner.common, org.eclipse.jst.jsf.ui (possibly that UI that is JSF facet dependent like the wizard pages).


Purpose: Stand-alone and exemplary UI for JSF tooling.

Can contain: API or non-API. Should not be shared be other plugins.

Can depend on: any plugins *but* no other plugins should have dependency on it (system should work if it is dropped).

Refactored from: org.eclipse.jst.jsf.ui, org.eclipse.jst.jsf.contentassist.el (those logic and extensions that support UI creation/interaction), org.eclipse.jst.jsf.validation.el (those logic and extensions that support UI creation/interaction).


Purpose: Stand-alone Faces config editor and associated non-shared UI.

Can contain: non-shared UI for editing application configuration files.

Can depend on: any plugins except jst.jsf.ui and all page designer plugins.

Refactored from: org.eclipse.jst.jsf.facesconfig.ui.


Purpose: Contains the stand-alone page designer editor and associated non-shared UI.

Can contain: non-shared UI for editing JSF-JSP pages.

Can depend on: any plugins except jst.jsf.ui.


Purpose: Isolates exemplary implementation and meta-data for specific tag libraries. This support ships for "out of the box" experience for all users, but should be easily replaced at will be adopters.

Can contain: All default tag support for JSF components that is considered "exemplary" rather than "core framework".

Can depend on: anything *but* should not be referenced by *any* other JSF plugin. All framework plugins should continue to function (though with reduced functionality) if this plugin is removed.

Refactored from: Tag specific parts of org.eclipse.jst.jsf.metadataprocessors, org.eclipse.jst.jsf.taglibprocessing, org.eclipse.jst.jsf.designtime.


The fate of code in the page designer contributions for jsp.core and jsf.ui must be decided. Some jsp.core code may belong in jsf.common. org.eclipse.jst.pagedesigner.jsf.ui probably needs to stand-alone.