Update mechanism improvements
(MAGNOLIA-5529)
|
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | modulemechanism |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Major |
| Reporter: | Philipp Bärfuss | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Description |
|
In several place we define installation tasks which should only be executed if a certain module is installed. This is currently possible by using IsModuleInstalledOrRegistered. example: workflow module changes the dms configuration on installation The problem is, that if a module is marked as being optional (dms), it can be installed at a later moment long after the installation tasks of the module (workflow) where executed. The solution would be to register this kind of tasks explicitly as being dependent on an other module and execute them only after the installation of the module. Note: we also started to introduce so called bridge modules which only deliver the tasks executed in such a scenario. While it complicates bundling and other things it is still likely that one forgets to install the bridge module. |
| Comments |
| Comment by Magnolia International [ 13/Aug/13 ] |
|
The solution described here would require changes to how tasks are registered, and might make it quite hard (harder!) to maintain versions/compatibility. |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |