Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cme-dev] need lock on CME repository 1 Nov 2005 from 2-5 pm Eastern US time

Hi All,

I need to make some localized changes in the CME Eclipse repository relating to the user interface.  I expect that this will involve mainly:

a)  Replacing the org.eclipse.cme.ui project with a new version with a somewhat different architecture and new extension point for loaders

b)  Moving the original org.eclipse.cme.ui project (in the "tools" folder) to somewhere where it will still be available but out of the way (possibly a new "old" or "deprecated" folder)

c) Adding a couple of new projects under the "contributions" folder (relating to loaders)

We're tentatively planning on making these changes tomorrow afternoon, Tuesday, 1 Nov,  between 2-5 pm Eastern US time.  We would appreciate it if everyone could avoid accessing the repository during this period.  I  hope that the changes will actually take only a relatively small fraction of that time, and I'll post a notice when we're complete.

If this is a problem for anyone, please let me know and we'll reschedule our update to the repository.

The effect on the user interface is described in the attached documents:

       

Regards,

Stan


Stan Sutton, Ph. D.
IBM T. J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone:  1-914-784-7316, FAX:  1-914-784-7455, T/L 863
e-mail:  suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS
Title: Concern Manipulation Environment--Configuring ConMan Loaders
 

Configuring ConMan Loaders

ConMan is the component in the CME that manages the concern model.  (The concern model, of course, is the central structure in the CME, the focus of visualization, querying, analysis, composition, and so on.)  ConMan loaders are tools that load a concern model into ConMan.  A concern model may represent various things:  the Eclipse workspace and projects, artifacts of various types (such as Java classes or Ant files), a concern-modeling schema, specific concerns of interest, and so on.
The loading capabilities in the initial CME release were partly fixed and partly extensible.  A more recent release makes the loading capabilities more extensible.  These differences are reflected mainly in the architecture and operation of the user interface.  This document describes generally how loading works and how it may be configured in the two versions of the user interface.  It begins with some background information.

Background:  Loaders, the Concern Space, and Loading

Technically, a loader is a Java class that implements the Loader interface (org.eclipse.cme.conman.Loader).  The Loader interface is very simple, including just two methods.  The main method is load(...), which takes an element description and a concern-model element and is interpreted as a request to load a representation of the described element into the given element.  The element descriptions are strings and are otherwise unrestricted in form or content.  Internally the behavior of a loader may be more or less complex.  For instance, a loader may search the workspace to find a described element, parse the element in detail, create an elaborate representation for it in the concern model, and invoke further loaders to load related elements; or the loader may just create a simple unit in the concern model and be done; or it may do anything inbetween (or beyond).

Loaders can be invoked directly by clients of the CME.  However, this is not the default mode of loader invocation in the CME.  Rather, loaders are added to the concern space (the root of the concern model), and clients make load requests of the concern space.  The concern space (org.eclipse.cme.conman.ConcernSpace) provides an interface analogous to that of Loader, and load requests of a concern space are delegated to its contained loaders.

It is also possible to build (or update) a concern model without using a loader, by directly accessing the concern space and the various types of concern model elements it contains (these types are defined in org.eclipse.cme.conman).  This is how loaders build up a concen model.

In the CME UI, the concern model is built when the "Refresh View" button in the Concern Explorer view is pressed.  Just how the concern model is built when this button is pressed depends on the particular version of the UI.

Loading in the Original User Interface

In the original user interface (UI), the UI directly loads the parts of the concern model that represent the workspace and its projects (but not their contents).  Depending on the particular version of the UI, it may also load some distinguished predefined concerns.  The original UI also creates project-specific instances of a predefined type of Java loader and adds these to the concern space.  (These loaders load Java packages, classes, and members.)  The original UI makes use of one extension point, artifactloaders, that allows for the addition of loaders for particular types of artifacts that may be found in the workspace.  The UI traverses the  directory structure under each project and attempts to load the various artifacts (files) that it finds there.  All of these behaviors are hardcoded into the UI.

The original UI operates according to the following major phases:
  • The top levels of the concern model are constructed (including representations of the workspace, projects, and any predefined concerns)
  • Loaders that extend the artifactloaders extension point are retrieved and added to the concern space
  • Java loaders of a particular type are instantiated for each project and added to the concern space
  • The directory structure of each project is traversed and a request is made of the concern space to load each artifact found (those artifacts for which the concern space has loaders should actually be loaded)
  • User concerns (that is, concerns created by users through the UI in a previous session) are restored from their serialized form
  • Relationships among Java elements and associated concerns are inferred
  • Intensional concerns (that is, those concerns defined by a query) are reevaluated
In this way the original UI addresses several fundamental considerations for concern modeling in the CME:  the original UI provides a basic representation of the workspace, it provides for the loading of an important artifact type (Java classes) and the computation of relationships significant for these artifacts; it allows for the addition of loaders for other types of artifacts; it handles the restoration (and serialization) of user-defined concerns; and it addresses the recomputation of intensional (query-defined) concerns.

However, the configurability of the original UI is limited in several important respects:
  • The representation of the top-levels of the workspace is hardcoded, so there is no way to vary how the workspace is loaded or represented
  • There are no loaders for any specific substructure in the workspace; that must be handled through "artifact" loaders
  • Consequently, artifact loaders must be based on appropriate and compatible assumptions about what that substructure may be (for example, that the place in a concern model into which a loader expects to load an element actually exists)
  • There is no way to substitute an alternative loader for Java artifacts
  • There is no way to add further "top-level" loaders, that is, loaders that will load elements other than the workspace, such as a concern-modeling schema or a specific concern model
Any of these sorts of changes require some degree of reimplementation of the original UI.

Loading in the Redesigned User Interface

To overcome limitations on loader configurability in the original CME UI, the UI has been redesigned.  The principle changes are as follows:
  • The functionality that directly built parts of the concern model (for the workspace, projects, and special concerns) has been extracted.  To keep this specific functionality available, it has been encapsulated in a loader (one that is now optional)
  • A new extension point automaticallyinvokedloaders has been added to the CME for use by the UI.  This is intended to support the addition of loaders that are invoked whenever the concern model is built or rebuilt (that is, whenever a user presses the "Refresh View" button in the Concern Explorer)
  • A new type has been defined in the ConMan package, LoaderDriver (org.eclipse.cme.conman.LoaderDriver).  It is actually LoaderDrivers that extend the automaticallyinvokedloaders extension point and invoke loaders
LoaderDrivers facilitate the decoupling of loading functionality from the UI.  By definition of the Loader interface and semantics, loaders do not themselves encapsulate any knowledge about what to load and where in the concern model to load it.  In the original UI, this information was provided by the UI.  To decouple loading from the original UI, this information had to be removed from the UI, but it could not be added to the loaders.  The LoaderDrivers provide a place to encapsulate this information; they have a generically invokable interface but can invoke a selected loader with specific information about what and where to load.

The redesigned UI operates as follows:
  • Loaders that extend the artifactloaders extension point are retrieved and added to the concern space
  • LoaderDrivers that extend the automaticallyinvokedloaders extension are retrieved and invoked; in turn, each loader driver invokes the loader (or loaders) that it drives, providing each loader with the appropriate parameters to indicate what should be loaded and where in the concern model it should be loaded
  • User concerns (that is, concerns created by users through the UI in a previous session) are restored from their serialized form
  • Intensional concerns (that is, those concerns defined by a query) are reevaluated
This redesign greatly enhances the configurability of the CME UI with respect to loaders.  No loading behavior is built into the UI; any loading behavior can be added to it.  So, with the redesigned UI, it is possible, for instance, to use alternative workspace loaders, to load artifacts from outside of the workspace, to load a concern-modeling schema, and to load specific concern models.
In addition to extensibility there are other important differences between the redesigned UI and the original UI.  One is that the original UI traversed the workspace and attempted to load any artifacts found there, whereas the redesigned UI does not do this.  This means that loaders added to the concern space through the artifactloaders extension point will not necessarily be invoked.  Rather, they will be invoked only if some other loader (or other client of ConMan) requests the concern space to load an element to which the artifact loader applies.

Another difference between the redesigned UI and the original UI is that the redesigned UI does not have a distinct phase of loading relationships.  The loading of any relationships must be addressed within some other loader or through a separate loader that is driven in the same way as any other loader.

There is no predefined order in which loader drivers are invoked in the redesigned UI, and there is no way through the UI to control the order of loader-driver invocation.  Thus, there should be no order dependencies among the loaders that are invoked by different drivers.  If it is important that two loaders be invoked in a particular order, then they should be invoked in the desired order from a single loader driver.

Note that a particular loader may serve both as an artifact loader and as an automatically invoked loader (although there may be little point to exploiting this feature in a single configuration).
Last modified on 10 September 2005 (sms)
Title: Default Configuration of ConMan Loaders
 

Default Configuration of ConMan Loaders

Details about configuring ConMan loaders and about the underlying user-interface architecture that supports loader configuration are described in a separate document, "Configuring ConMan Loaders." 

Briefly, the new user-interface architecture contains a new extension point, automaticallyinvokedloaders, that is extensible with alternative loaders.  The Plugin.xml file for the new user-interface project (org.eclipse.cme.ui) comes with several extensions to this extension point "roughed in."  That is, the extensions are specified, except in most cases with the extension-point name modified to be invalid (e.g., point="org.eclipse.cme.automaticallyinvokedloadersXXX").  This is a "quick and dirty" way of configuring the loaders from among several that are available, pending further development of a more convenient mechanism through the user interface.  The Plugin.xml file does come with one well-formed extension of the automaticallyinvokedloaders extension point.  That extension plugs-in a loader called "DemoLoaderPlugin" that is an updated and refined version of the original CME loader.  Like the original loader it loads the Java projects in an Eclipse workspace along with some relationships among the Java classes in those projects.  However, it provides a more complete model of the workspace, including, for example, package roots and empty packages.  (There is an alternative plugin available, "OriginalLoaderPlugin", that is based on the original loader code and that loads a concern model with the same structure as in the original CME release.)

The various loaders referred to in the Plugin.xml file for this project are mostly provided through the new ConMan loader framework, which is described in the document "A Framework for ConMan Loaders"
Last modified on 26 October 2005 (sms)

Back to the top