Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Refactoring Specification (Buckminster)"
(→From direct dependencies to a configuration component) |
|||
| Line 2: | Line 2: | ||
===From direct dependencies to a configuration component=== | ===From direct dependencies to a configuration component=== | ||
| − | + | A given component's dependencies may evolve such that its dependencies become useful for other components, i.e. when creating component B, it has the same (or a large overlapping) set of dependencies with component A previously created. A user could just copy CSPEC from component A to component B and then edit A's specifics. A better approach may be to aid the user in creating a configuration component that both A and B can depend on. | |
This refactoring would aid the user with: | This refactoring would aid the user with: | ||
Latest revision as of 15:50, 5 December 2006
Right now, this specification only contains some ideas regarding Refactoring that Buckminster could support:
From direct dependencies to a configuration component
A given component's dependencies may evolve such that its dependencies become useful for other components, i.e. when creating component B, it has the same (or a large overlapping) set of dependencies with component A previously created. A user could just copy CSPEC from component A to component B and then edit A's specifics. A better approach may be to aid the user in creating a configuration component that both A and B can depend on.
This refactoring would aid the user with:
- creating a configuration component (C)
- copying and transforming the CSPEC in A to a CSPEC in C with all A specifics pruned
- modifying A's CSPEC to prune all the dependencies now in C, and adding the dependency to C
This could be a implemented as a Wizard.