|
Review of update tasks:
- Good job on making good task descriptions; task names should be more concise, though ("update availability class names", for example)
- If you use slf4j, have a static final logger instance. (change your class template in your ide?), e.g.
instead of
- Don't catch/log. Rethrow (if you have a RepositoryException you can't treat, you probably should stop the update altogether). And if you need to log something ("hey, we noticed your config is outdated, blablabla"), then do that via InstallContext#warn()/#error()/#info()
- In ChangeJcrDependentAvailabilityRuleClassesFqcnTask
- rethrow or treat.
- either way, make sure the message is accurate ("unable to process app node", is neither precise nor correct)
- Couldn't MigrateRuleClassToAvailabilityRuleDefinitionCollectionTask be merged with the above ? They run the same query - i.e operate on all 'availability' nodes.
- For tasks aren't meant to be re-used by other modules, mark them as such (i.e by not making them public)
- If MigrateWorkspaceAndPathToContentConnector is meant to be re-used, make it explicit (javadoc?)
- I'm on the fence regarding that one being reused or doing the job for other modules. Modules will have to update their bootstraps, so they might as well handle their updates. No strong feeling.
|
|
ContentAppModuleVersionHandler calls MigrateJcrPropertiesToContentConnectorTask --> that migrate nodeTypes...
Issue is that ContentAppModuleVersionHandler run before AdmincentralModuleVersionHandler!
There you have update task like (.addTask(new NewPropertyTask("Set main node type in configuration app as strict", "Sets main node type as strict, i.e. its substypes won't be included in list and search views.", RepositoryConstants.CONFIG, "/modules/ui-admincentral/apps/configuration/subApps/browser/workbench/nodeTypes/mainNodeType", "strict", true)))
that try to handle property into this area..
|