[MAGNOLIA-1354] Module bootstrapping could accidentally bootstrap another module's files Created: 07/Feb/07  Updated: 23/Jan/13  Resolved: 07/Feb/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.0.1
Fix Version/s: 3.0.2, 3.1 M1

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
supersession
is superseded by MAGNOLIA-1927 ModuleBootstrapTask should not bootst... Closed
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When a module needs to be bootstrapped, the current mechanism filters files using the following rule:
name.startsWith("/mgnl-bootstrap/" + moduleName) && name.endsWith(".xml")

As a consequence, if the currently bootstrapped module (name) is "foo", the bootstrap files from a module called "foo-bar" would be bootstrapped too, which is not desired and time consuming. (Since foo-bar will also boostrapped, if it needed to be bootstrapped too)



 Comments   
Comment by Magnolia International [ 07/Feb/07 ]

fix commited in 3.0branch and trunk

Comment by Vivian Steller [ 06/Dec/07 ]

note that bootstrap files of module are not bootstrapped recursively since MAGNOLIA-1927.

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