[MAGNOLIA-1926] New bootstrap mechanism: bootstrap modules files automatically if optional dependency is installed Created: 06/Dec/07  Updated: 03/Apr/08  Resolved: 03/Apr/08

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.5 RC2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Vivian Steller Assignee: Vivian Steller
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-1927 ModuleBootstrapTask should not bootst... Closed
relation
is related to MAGNOLIA-1795 Review bootstrap install tasks Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-1936 Implementation for bootstrapping the ... Sub-task Closed Vivian Steller  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

In 3.5-rc2 we already have a mechanism for bootstrapping sample files of a module. This is realized by SamplesBootstrapTask and IsInstallSamplesTask, which in turn checks for a property in magnolia.properties that decides if the samples are installed or not.

It would be very helpful to generalize this bootstrap feature so that whenever a module has

  • a /mgnl-bootstrap-DEPENDENCY folder containing bootstrap files
  • an appropriate DEPENDENCY optional module dependency
  • and the optional DEPENCENCY is installed
    these dependency specific bootstrap files will be installed.

E.g. the workflow module version handler bootstraps an activation command depending on the existence of the DMS module. Since all bootstrapped files are located in the same folder under /mgnl-bootstrap and only one of them needs to be bootstrapped conditionally it is very annoying to overwrite default bootstrap behavior of DefaultModuleVersionHandler to solve this properly.



 Comments   
Comment by Vivian Steller [ 06/Dec/07 ]

okay, discussed with philipp that we won't do it exactly as with the mgnl-bootstrap-samples mechanism but as follows:

  • ModuleBootstrapTask now does not bootstrap recursively any more (see MAGNOLIA-1927)
  • /mgnl-bootstrap/someName folders will be used (in the first place) to differentiate bootstrap files for different modules/dependencies
  • in the first implementation (3.5-RC3) one have to bootstrap the dependencies manually with the ModuleDependencyBootstrapTask("someName")
Comment by Vivian Steller [ 06/Dec/07 ]

will fix this for 3.5 already.

Comment by Vivian Steller [ 06/Dec/07 ]

fixed for RC3 with r13407. Although not automatically done, yet. Will schedule that for "green".

Comment by Vivian Steller [ 06/Dec/07 ]

reopened to be finally fixed with "green".

Comment by Magnolia International [ 03/Apr/08 ]

these kind of things should be done using install/update tasks; would otherwise make things too complicated.

Generated at Mon Feb 12 03:31:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.