[MGNLRES-181] STK theme resources appear twice after migration to 5.4 Created: 16/Jul/15  Updated: 29/Mar/22  Resolved: 14/Jan/16

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.3

Type: Bug Priority: Blocker
Reporter: Roland Polzer Assignee: Mikaël Geljić
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: 0d
Time Spent: 10d 7h
Original Estimate: 3d

Attachments: JPEG File snap1.jpg    
Issue Links:
Relates
dependency
is depended upon by MGNLSTK-1405 Change default behavior of ThemeVersi... Closed
is depended upon by MGNLSTK-1519 Do not strip resources extension in I... Closed
is depended upon by MGNLGA-19 Update install tasks for ga resources 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: Saigon 26
Story Points: 8
Team: Nucleus

 Description   

After migration to 5.4 my theme resources appear twice under STK - Resources. Once with file extension and once without. The same happens for CSS, fonts, Images, Javascript (some, not all).

Please see snapshot



 Comments   
Comment by Mikaël Geljić [ 11/Aug/15 ]

Hi Roland,
It's more of a side effect than expected behavior, but on the other hand it's not much dramatic.

  • The JCR ones (extension-less) will keep matching the repository mapping at /resources, but won't be anywhere in the new loading cascade.
  • Installing resources used to be the de-facto standard, sometimes simply to bypass them and serve them from the classpath
  • With 5.4 you no longer have to do that, so my advice—for non-processed resources—is to simply delete them from the workspace and adjust the resource handles in template scripts or wherever applicable to /.resources
  • It's hard for us to decide/enforce that through a migration task, especially since you may still chose to stick to the URI2Repo way of accessing resources in some cases.

On a side note, if re-installing the theme is an option, you may adjust your task in version-handler. Those install tasks typically take a stripExtension parameter (on by default), which you may now turn off.

At least to me, it's unclear whether we can do something meaningful there. Rather take this as a helper/indication that there is inconsistency against the new resource loading cascade, and try to address those.
Maybe a groovy script renaming nodes when they match on the classpath could be of assistance.

Cheers,
Mika

Comment by Jan Haderka [ 09/Sep/15 ]

OTOH in original resources you have extension stored as a property of the resource in repo so when migrating/upgrading to new version we should be able to bring it back into the name. Or am I wrong?

Comment by Sang Ngo Huu [ 26/Oct/15 ]

I tried with approach using groovy script to rename name node with extension, Seem it works well.
OTOH, when editing an resource, it will be updated to JCR too.

Comment by Sang Ngo Huu [ 23/Dec/15 ]

Update 23.12.2015
We do not fail and log anymore, but warn to install context instead.

  • For this task, nothing is ever broken anyway; user can easily act upon detected discrepancies.
  • We try to aggregate problems as one single warning (categorized with lists of affected files and reasons), if formatting allows.

We also compare content in the case of resource already present in JCR with extension.

  • If content is the same, we simply delete the old resource, and keep track to also update references.
Comment by Sang Ngo Huu [ 05/Jan/16 ]

Update 05.01.2016
mgeljic and I agreed some points:

  • we validated minor change of flow re: extension check + not warning if dots in file-name
  • we also validated that modules should clean up their installed resources, i.e. we will use the cleanup task in STK VH, not in resources VH.
  • It's still unclear how "client" VHs will pass their installed resources to rename (e.g. root directory, set of files or by other means)
Comment by Mikaël Geljić [ 14/Jan/16 ]
  • InstallReferenceResourceTask cannot install reference resources with extension (hard-coded stripping atm)—resource references would currently be broken.
  • Looks like we'd rather clean up resource properties as well—those formerly created by AbstractInstallResourceTask and predecessor InstallResourceTask (e.g. modelClass, rights, source, version)
    • Binary resources shouldn't have any modelClass, they should have their fileName property updated with extension too, and their size property should be updated with type Long.
Generated at Mon Feb 12 06:48:11 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.