Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: 5.0.0
Forward-port the fix of
CMS-10753 as excerpted below:
Even if we're going to replace the auto-export feature by something better in v12, it might be safer to simply forward-port the fix until the whole auto-export submodule can be removed safely in the future.
AFAIK auto-export has hardcoded knowledge about how to split certain parts of the repository into files and folders (see the ENTRIES in https://code.onehippo.org/cms-community/hippo-cms/blob/master/automatic-export/repository/src/main/java/org/onehippo/cms7/autoexport/LocationMapper.java).
The hard-coded entries looks like something we can improve very easily even in v11. As William mentioned and Engineering is refactoring it totally with YAML, it must be not a good idea to spend too much time on improving it in v11.
But, it really looks like a low-hanging fruit improvement. For example, one hard-coded entry is:
If we change the static block to load those entries from classpath resource file (e.g, classpath:org/onehippo/cms7/autoexport/LocationMapper.xml) like the following example:
So, the idea is:
- We do NOT change or try to improve the current auto-export behaviors at all in v11 branch,
- But simply externalize the 'static hard-coded initialization of mapping entries to a classpath XML resource file.
- So, possibly developers can override the classpath XML resource file to control the entries.
- If we do have proper unit tests to ensure the backward compatibility even with this kind of simple improvement, I think it should be fine.
- This is in the same pattern (externalizing hard-coded parts to a classpath resource file) as https://issues.onehippo.com/browse/REPO-1630.
Wouldn't it be a low-hanging fruit in v11 branch, or would it be better to just wait for v12 and upgrades someday later?