[MAGNOLIA-6044] ImportUUIDBehavior in ModuleBootstrapTask Created: 13/Jan/15 Updated: 19/May/22 Resolved: 19/May/22 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | modulemechanism |
| Affects Version/s: | 5.3.6 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Lea Hänsenberger | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| 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: | |
| Visible to: |
ben gruber, Lea Hänsenberger, Pascal Kuster
|
| Description |
|
When using the ModuleBootstrapTask I don't have the possiblity to tell it, what should happen if there's a conflict with the UUIDs. So far I always created my own Task that is basically the same as the ModuleBootstrapTask, but it takes an int as parameter in the constructor which is then passed on to BootstrapResourcesTask as ImportUUIDBehavior: package ch.screenconcept.nobel.setup; import info.magnolia.module.InstallContext; import info.magnolia.module.delta.BootstrapResourcesTask; public class CustomBootstrapTask extends BootstrapResourcesTask { public CustomBootstrapTask(int importBehavior) { super("Bootstrap", "Bootstraps the necessary module repository content.", importBehavior); } /** * Accepts any resource under "/mgnl-bootstrap/moduleName" including any * subfolders. */ @Override protected boolean acceptResource(InstallContext ctx, String resourceName) { final String moduleName = ctx.getCurrentModuleDefinition().getName(); return resourceName.startsWith("/mgnl-bootstrap/" + moduleName + "/") && resourceName.endsWith(".xml"); } } I was wondering if it wouldn't make sense to add a constructor to ModuleBootstrapTask, allowing devs to specify the behavior on UUID conflicts. Because as it is installation or update of the module just fails and it's quite annoying to fix the xml in order for the update to work. Unfortunately, if multiple people work on a project, those conflicts happen from time to time. |
| Comments |
| Comment by Roman Kovařík [ 19/May/22 ] |
|
Hello, This ticket is now marked as closed due to one of the following reasons:
If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you. Thank you, |