[MAGNOLIA-7111] Light-Module descriptor not read when using sym links Created: 17/Aug/17  Updated: 06/Jun/18  Resolved: 16/Nov/17

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.5.5
Fix Version/s: 5.5.8, 5.6.1

Type: Bug Priority: Major
Reporter: Christoph Meier Assignee: Robert Šiška
Resolution: Fixed Votes: 1
Labels: to-estimate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CE, 5.6-SNAPSHOT, 5.5.6-SNAPSHOT; OS-X 10.11.6; Java 1.8.0_51


Issue Links:
Relates
relates to MAGNOLIA-7196 Support read module descriptors from ... 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:
Sprint: Kromeriz 122, Kromeriz 123
Story Points: 5

 Description   

Summary

If light-modules are added as symlinks to the magnolia.resources.dir, their module descriptors are not properly read. Defined dependencies are missing.

=> As a consequence, YAML !inherits fails when inheriting between light-modules.
(Because of this, i have created the ticket as a blocker)


To reproduce failure

(I)
Clone having-fun-with-yaml to /yours/dev/repo/having-fun-with-yaml

(II)
Set

magnolia.resources.dir=/yours/dev/lightmodules

(III)
In /yours/dev/lightmodules create these symlinks:

module-a -> ../repo/having-fun-with-yaml/light-modules/module-a/
module-b -> ../repo/having-fun-with-yaml/light-modules/module-b/

(IV)
Start magnolia; check the log after start or check the Definition app; both claim:

" (YAML dependency resolution) - Missing definition dependency
Problem details: Inherited definition at (module-a:components/a-component) either does not exist or is not loaded because of the missing module dependency in module (module-b), which currently depends only on () 2"

To verify that having-fun-with-yaml is ok:
(I)
see above:
(II) Set

magnolia.resources.dir=/yours/dev/repo/having-fun-with-yaml/light-modules

(III) Start the instance, this time it will work.



 Comments   
Comment by Christoph Meier [ 17/Aug/17 ]

Note that jfrantzius recently was reporting issues when using symlinks for light-modules (see comments on the docu page Creating a light module.

Not sure whether this issue here and Joergs observation are related. However, in both cases there is a problem when using symlinks for light-modules.

For me symlinks worked fine now for a long time without having issues. My "only" issue so far is the one which is described in this ticket, where Joerg seems to have "more" problems with symlinks.

Comment by Christopher Zimmermann [ 07/Nov/17 ]

Yeah - this is particularly important because decoration and new YAML !include feature depend on light module dependencies.

Comment by Viet Nguyen [ 13/Nov/17 ]

Would also great if we can read module descriptors from JCR as suggestion in the ticket Support#8104:

Currently, info.magnolia.module.model.reader.LightModuleDefinitionReader goes directly against the filesystem.
This means it does not "find" light modules which are stored in the JCR resources workspace. In contrast, the other areas of light development (template registry, dialogs, themes, etc...) have no problem finding the definitions regardless of storage location because they operate on the Resources abstraction.
Please fix LightModuleDefinitionReader to use the Resources Abstraction to locate modules rather than going directly to the file system.
This will enable JCR-stored Light Modules, and also enable "JCR patching" for the module descriptors, even when they are present on the filesystem.

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