[udig-devel] Some definitions

[David Zwiers <dzwiers@xxxxxxxxxxxxxxx>]

Features

The platform is designed to accept updates and additions to the initial
installation. The platform  Update Manager handles this task by
connecting to sites where updates are posted. (See the Workbench User
Guide and Platform Installation and Update for more information about
features and the Update Manager.)

You need to package your work in a form that will be accepted by the
Update Manager.  When you deliver an update to the platform, you are
contributing a feature.

Features have a manifest that provides basic information about the
feature and its content.  Content may include plug-ins, fragments and
any other files that are important for the feature. The delivery format
for a feature is a JAR. 

In PDE, your typical development process looks like this:

     1. Projects for plug-ins and fragments are created.
     2. Code for plug-ins and fragments is created, tested and debugged.
     3. When you want to make your code available to others, you create 
        a new feature project.
     4. Individual build properties for each plug-in and fragment are
        tailored to control what files are included and excluded from
        the packaging.
     5. Versions are synchronized with previous versions of the feature,
        so that the Update Manager will know that a feature is a newer
        version of an already installed feature.
     6. The feature JAR is built.
     7. The feature is published on the update server and made available
        for download.

Plug-ins and fragments

Features are described in terms of the plug-ins that comprise them. 
This means that plug-ins are the fundamental unit for packaging
function.  

While features are organized for the purposes of distributing and
updating products, plug-ins are organized to facilitate the development
of the product function among the product team.  The development team
determines when to carve up program function into a separate plug-in.  

Plug-ins are packaged in a plug-inarchive file and described using a
plug-inmanifest file, plugin.xml.  

Plug-in fragments are separately packaged files whose contents are
treated as if they were in the original plug-in archive file.  They are
useful for adding plug-in functionality, such as additional national
language translations, to an existing plug-in after it has been
installed.  Fragments are ideal for shipping function that may trail the
initial product release, since they can be used to add function without
repackaging or reinstalling the original plug-in.  When a fragment is
detected by the platform, its contents are merged with the function in
the original plug-in.  In other words, if you query the platform plug-in
registry, you would see the extensions and other function provided in
the fragment as if it was in the original plug-in.

Fragments are described using a fragment manifest file, fragment.xml. 
It is similar to the plug-in manifest file.  Since a fragment shares
many properties with its plug-in, some attributes in the plug-in
manifest are not valid, such as the plug-in class and plug-in imports.

Plug-inarchive files can contain plug-ins or fragments.  

Fragments

A plug-in  fragment is used to provide additional plug-in functionality
to an existing plug-in after it has been installed. Fragments are ideal
for shipping features like language or maintenance packs that typically
trail the initial products for a few months. Another frequent use of
fragments is to deliver OS or windowing system-specific features. 

When a fragment is detected by the platform and its parent plug-in is
found, the fragment's libraries, extensions and extension points are
"merged" with those of the parent plug-in.  

While this merging mechanism is good from a runtime point of view,
developers need to view fragments as separate entities while working on
them. Fragment development is often done by different teams, on a
different schedule, sometimes even on different operating systems from
the original plug-in.

PDE provides full support for fragment development. Fragments can be
viewed as "limited plug-ins".  They have all of the capability of
regular plug-ins but have no concept of life-cycle. Fragments have no
top-level class with "startup" and "shutdown" methods.