0%

Managing Assets and Dependencies ID: PM-NV-MAD

TLDR

  • InstallOnly, Update, and Trashed assets indicate primary “ownership” of the asset.
  • Each asset can only be owned by one package. To include that asset in a second package the first package must be added as a dependency instead.
  • Ignored, MapRequired, and MapOptional assets indicate a looser “relationship” between a package version and an asset.
  • Dependencies must be installed at the same time or before the package version that defines it as a dependency.

Asset Types

There are 6 different types of asset:

  • InstallOnly: These assets will be added to the target site when the package is installed, but will not be updated when the package is updated.
  • Update: These assets will be added to the target site when the package is installed and will be updated when the package is updated.
  • Trashed: These assets have been trashed and/or removed from the source site, and will be trashed on the target site if they exist when the version is installed.
  • MapOptional: When the package is installed on a site, the user will be given the opportunity to select a different object on their site to map this asset to. If selected, any references to this asset will be updated to the selected asset during their installation. Not not selected, references to this asset in the package will simply be ignored - which could cause validation errors which the user will have to fix before completing the installation.
  • MapRequired: When the package is installed on a site, the user will be required to select a different object on their site to map this asset to. Any references to this asset will be updated to the selected asset during their installation.
  • Ignored: These assets are ignored when the package is installed on a site.

These 6 asset types break down into 2 categories:

"Owned" Assets include InstallOnly, Update, and Trashed assets. These assets may only be included in one package, and attempting to add one of these assets to a draft version while it belongs to another package will add the other package as a dependency instead. Ownership is determined by the latest version of each package and does NOT take into account old versions or draft versions.

"Related" Assets include MapOptional, MapRequired, and Ignored assets. These assets indicate a looser relationship between the asset and the package and may be included in as many packages as desired.

The only assets you should typically need to manage most of the time are InstallOnly and Update assets. When a new draft is created, and when a draft is pre-activated, Marketpath will automatically curate your Trashed, MapOptional, and MapRequired assets - although adding and updating the descriptions will be up to you.

Dependencies

Oftentimes, one part of a website is dependent on another. In this way you can build complex and flexible sites very quickly from a variety of reusable components. In Marketpath CMS Package Manager we define these components using dependent packages.

When installing a package with dependencies, the dependent packages must either already be installed on the site or may be installed at the same time.

However, it is common for packages to change over time so that new features or components are added and old ones removed. When you define a dependent package, you can select the minimum version for that package. The most common values are either to allow any version (no minimum version) or to require the latest version of a dependent package at the time that your package is released.

Because of the dramatically increased complexity, Marketpath CMS does not allow you to define a maximum version for a package - which means that future updates to dependent packages could potentially break your package. There are generally three ways to handle this challenge:

  1. Ignore it entirely. This may be an acceptable option for simple and stable dependencies or for packages that you only intend to use for a short time.
  2. Actively maintain your package. When new dependent versions are released, check to see if they break your package. If they do, fix it and release a new version. In your changelog, cite the new dependent package version as the reason for the change.
  3. Maintain both your package and all dependent packages. If you control all of the code, then it will be easier for you to prevent breaking changes in dependent packages. Of course, at the same time it may be more work for you to maintain all of the components yourself. If you attempt this, make sure you follow all applicable copyright and intellectual property guidelines.


Feedback?

Please fill out the form below with your feedback or any questions you may have after working through the "Managing Assets and Dependencies" lesson.

Your Name
Email 
Feedback / Questions