Method packages represent a set of selectable method content elements that provide the user with flexibility in choosing what portions of the method he wants to publish. Method elements in one package can reference elements in another package.

Method packages should be used to represent logical units for useful configurations – sets of elements that should either be included together in a configuration or excluded from a configuration. The user can choose which packages to include in the published site by making selections in the configuration.

Consider packaging very carefully to provide flexibility in what is published. For example, you could put all of the tool mentors for a specific tool into a single content package.  This makes it very easy for someone to deselect the tool mentors from publication.

Packages should be defined so that selecting all packages does not result in overlapping or conflicting content. If alternatives are needed, separate plug-ins should be defined, not just separate packages.

Method packages can also be used to collect obvious categories of content to make it easy to find things, as opposed to just seeing a long list of elements. 

The following sections provide guidelines on the use of the two types of packages: method content packages and process packages.

For recommendations on naming content packages, see Guideline: Method Element Naming Conventions.

Method content packages

There are several organizational strategies that can be applied to refine the method content packaging structure. 

Option 1: Organizing the content packages along the major areas of concern of the plug-in.

When organizing the method content packages of the plug-in along the plug-in’s major areas of concern, group all method content that supports a specific area of concern together in the same (or sub-) content packages.

The pros of organizing the content packages along the plug-in’s major areas of concern are as follows:

• It is easy for users configuring the method to select only those areas of concern that they are interested in.
• The method package structure truly reflects the architecture of the plug-in itself, where each content package is cohesive, but loosely coupled with other packages.
• A plug-in’s content package structure should not be dependent on the base library package structure, which may change at any time.

The cons of organizing the content packages along the plug-in’s major areas of concern are as follows:

• When the plug-in’s package structure is not aligned the base library’s package structure, it is harder to see what plug-in content packages should be selected when specific base content packages are selected. When the packages are aligned, it is easy to see where the plug-in content fits into the base content.

Option 2: Echo the packaging used in the base plug-in.

In this approach, align the content package with the base plug-ins content packages. Define a content package structure that looks just like the base plug-in’s and place the method content elements in the most appropriate package.

If content is contributed to only one or two packages of the base plug-in, rather than to most packages, echo only that portion of the base plug-in structure that is needed. For instance, if the base package \Design\Visual Modeling is the only package modified, echo only the base plug-in packaging structure of \Visual Modeling and its eventual sub-packages.

The pros of aligning the plug-in package structure with the base content’s are as follows:

• When the packages are aligned, it is easy to see where the plug-in contents fit into the base plug-in.
• It also preserves the package selection choices provided by the base plug-in for publication.

The cons of aligning the plug-in package structure with the base plug-in’s are as follows:

• The plug-in structure does not reflect its architecture, but instead reflects the base plug-in’s architecture, which can change at any time.

Method elements that support specific aspects of the plug-in are not packaged together, so it is not easy to select relevant subsets of content to be included in a configuration.

  

Process packages

Process packages organize processes so they can be managed and located easily. The Configuration View is often used when defining new processes because drag and drop is enabled from this view into the process editors. In this view, plug-in divisions are not shown, so it can sometimes be helpful to define process packages in plug-ins as the process packaging hierarchy for each plug-in is preserved. For example, you may want to put all processes in a plug-in in a process package that is named to represent the plug-in.  If a plug-in has many processes, you may want to define subpackages. 

In most cases, process packages are used for capability patterns only (the number of delivery processes is usually so small, packages are not  needed). 

For recommendations on naming process packages, see see Guideline: Method Element Naming Conventions.