[MAGNOLIA-1665] updatemech : module version stored in repo is not consistent Created: 07/Aug/07  Updated: 09/Nov/12  Resolved: 14/Oct/12

Status: Closed
Project: Magnolia
Component/s: updatemechanism
Affects Version/s: None
Fix Version/s: 4.5.7

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

Issue Links:
causality
is causing MAGNOLIA-3252 Version should not ignore SNAPSHOT cl... Closed
dependency
depends upon MAGNOLIA-1602 Update mechanism Closed
is depended upon by MAGNOLIA-1631 Warn user when installing snapshot ve... Closed
relation
is related to MAGNOLIA-1963 Modules: version number is not update... 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)
Date of First Response:

 Description   

It uses the descriptor's version number when installing or if the module is "legacy", and uses the ModuleVersionHandler when updating...



 Comments   
Comment by Magnolia International [ 10/Jul/08 ]

quickly checked - it seems fine now.
Need to double-check and pinpoint what made this work...

Comment by Magnolia International [ 14/Jul/08 ]

Almost there but still one case is failing:
testStoresTheModuleDescriptorVersionOnUpdateOfVersionThatHasSpecificDeltaButIsSnapshot

This was mostly solved by MAGNOLIA-1963

Comment by Boris Kraft [ 09/Dec/09 ]

I suggest we fix that for the next bug fix release as it seems we already invested time; we should finish what we start or not start at all.

Comment by Jan Haderka [ 14/Oct/12 ]

testStoresTheModuleDescriptorVersionOnUpdateOfVersionThatHasSpecificDeltaButIsSnapshot is still failing as of 4.5.6.
What happens:
AMVH.getUpdateDeltas() checks for version being already registered like:

        if (toVersion.isStrictlyAfter(from) && !allDeltas.containsKey(toVersion)) {
            deltas.add(getDefaultUpdate(installContext));
        }

and allDeltas uses VersionComparator to locate appropriate key. The compare() method calls isEquivalnet() method during comparison:

        } else if (v1.isEquivalent(v2)) {
            return 0;

isEquivalent ignores classifier (and its javadoc states so as well) so 2.0.0 and 2.0-SNAPSHOT are evaluated as same and update task is not added since its considered to exist already.

IMHO code does exactly what it's supposed to do, whether its the best ...

Possible fix could be in getUpdateDeltas():

  • always add at the end update task for latest version from install context or
  • replace update task in delta equivalent to version from install context with task using that version.

While the latter seems smarter choice on first look it means iterating over all tasks, checking if they are VersionUpdateTasks and to what version they update. Computing overhead will be higher for doing so then for executing extra update task in all expect simplest updates.

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