[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:

  • A long period of inactivity
  • Uses an old or Beta version of an application, module, or framework that we no longer support
  • The issue is no longer reproducible or has been fixed in later versions

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,
The Magnolia Team

Generated at Mon Feb 12 04:10:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.