One of the problems caused by the old approach described in Automated project usages, was in refactoring composite used projects (used projects composed of sub-used projects). Whenever a composite used project was re-arranged by removing or re-importing sub-used projects, all of the projects or used projects using this used project more often than not became affected.

The following examples illustrate this problem. 

Example 1

Consider a used project ElectricComponents with 3 sub-used projects: Capacitors, Inductances, and Resistances. Consider another project RadioSet, which uses the used project ElectricComponents.

Now, use several model elements from each sub-used project in the project RadioSet.

Old problematic behavior

Previous versions of our modeling tool would create these three direct user-defined usages:

RadioSet → Capacitors,

RadioSet → Inductances, and

RadioSet → Resistances.

Effectively, those versions were “freezing” the contents of the used project ElectricComponents.

If you tried to refactor the used project ElectricComponents by removing its sub-used projects and re-importing their contents, the project RadioSet would be affected and start complaining about the missing used projects.

No earlier version of our modeling tool could rearrange the user-defined usages for fear of losing the user-specified used project composition data.

New behavior

As of version 17.0.3, a program creates automated used project usages instead of creating user-defined ones. So when the used project ElectricComponents is refactored, it keeps the same model elements but changes its structure. Furthermore, the automated usages in the project RadioSet are automatically rearranged.

Another types of problems

Now problems could occur only if the rearranged used project does not contain all the same elements it had before the rearrangement. Thus some automated usages may turn into unconfirmed ones. For more information about unconfirmed usages, see Controlling dependency creation between used projects. 

Example 2

Another problem was “freezing” the used project's version. For instance, the project RadioSet uses the 100th version of the used project ElectricComponents, which in turn uses the 150th version of the sub-used project Resistances.

Old problematic behavior

Whenever the project RadioSet referenced the sub-used project Resistances, the direct usage would be created to the 150th version of it. If you wanted to migrate the project RadioSet to use the 200th version of the used project ElectricComponents, which used the 300th version of the sub-used project Resistances, a version conflict would occur, since the direct usage would be still pinned to the 150th version.

New behavior

As of version 17.0.3, automated usages do not carry information about the version and do not preclude the version update through the user-defined usage paths.

Complex Composition

If you already have projects with complex composition (having used projects or sub-used projects) that are prepared in any earlier version, you may want to refactor your used project structure to reap the benefits of this feature. 

Related pages