[MAGNOLIA-6723] Improve Module installation behavior: When bootstraps are already there allow skipping bootstrapping Created: 18/Jul/16  Updated: 01/Dec/22  Resolved: 01/Dec/22

Status: Closed
Project: Magnolia
Component/s: modulemechanism
Affects Version/s: 5.4.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: support, to-specify, to-verify
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File TypialProjectSituation.png    
Issue Links:
relation
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:
Story Points: 13
Team: Nucleus

 Description   

I was helping 3 weeks in Support and have seen this problem there a couple of time only in these three weeks.
And also In know it from development and training, that this is very often a problem.

The problem:
When a module is already installed and registered in config:modules, but the modules wants to re-install. That happens when either:

  • the module registry breaks, was moved or anything alike
  • the version property was deleted
    Then the module tries to re-install and is denied, because it can't bootstrap the bootstrap files (UUID conflict).

Also in development/training:
I've seen it many times, people break the config:modules/modueRegistry and restart.
Module can't be re-installed.
Or even more often: they want to explicit re-install the module to test something, remove it from config:modules and restart, but forgot some node with a uuid also in bootstrap files (but in a different place).

Effect:
One can just not startup Magnolia anymore!

  • In support I had to create to the customers a patched jar, removed all the bootstrap files.
    Just that they can startup again and fix the config:modules problem.
  • In development one needs to remove the deps from the webapp's pom and hope no other module has a deps to it. And start up.

Both are situations, where all what is needed is that the system starts up again.
Often just to see what happened and fox it, or even more likely get unsaved work out of the repo for a complete proper re-deployment.

Solution:
The solution would be easy, I see two possibilities:

  • a magnolia.properies value that can be switched, that will just not bootstrap anything form any module. Very handy for development (and auto install option combination).
  • when not using the auto install option: On the installation screen, where it states that the module can not be installed a button with "Ignore and proceed". Advantage, it would ignore it just for the one module needed.

I thin both are achievable with not much effort.

Cheers
Christan



 Comments   
Comment by Christian Ringele [ 19/Jul/16 ]

A typical Project situation: TypialProjectSituation.png

Old project checked out, deployed fist time, uuid conflict.
Who the heck would still know why?

Would be much easier to solve being able to start the system and drop jcr queries for searching the node with this uuid. Instead of searching trough all the bootstrap files in the modules.

-> update:
And then the search trough all XML files doesn't find a uuid
-> searching in the started magnolia via JCR query would already give a hint.

Comment by Jan Haderka [ 04/Aug/16 ]

Actually the analysis above is incorrect.
The issue occurs when content with same UUID exists at different path then the one under which it is being attempted to bootstrap. How is Magnolia to know which path is correct. Original one (ignore new bootstrap) or the new one (delete original subpath). Perhaps we could allow user to manually resolve each of those situations and choose the behavior, but there is no single automated solution that would be correct in all scenarios.
If we go ahead with the improvement of allowing to resolve conflicts manually, it would be major rework and as such would probably not be possible before after 5.5 release.

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