Move the date macro to a separate module #112

[ChiuchiuSorin]

Created a submodule for the date macro, separated the date configuration from the task manager application and created a new configuration class for the date macro.
Moved the date macro logic from the application-task-default to application-task-date-default. Created a submodule for the date macro ui and moved translations and skins.

[trrenty]

We have one more possible problem which we need to address. If an user has made changes to the Administration Section of the Task App before the upgrade, the storage format/display format will be lost/not taken into consideration anymore. This will cause the task macros to not work anymore unless the user changes the Admin section of the Date macro to match the other one.

To fix this, we could have, in the default module of the task app, a listener that on initialization will do the following:

• Look for the Administration.xml page of the Task App.
• Get the TaskManagerConfigurationClass object from that page
• If the storageDateFormat/displayDateFormat are not empty (after an upgrade, the Administration.xml file should still have the removed properties and the changed values)
  • Get the Configuration.xml file of the Date macro.
  • Get the ConfigurationClass of that page
  • Update the storageDateFormat/displayDateFormat if they are empty
    Let me know if you see a better solution.

This is an example of a listener that implements Initializable: https://github.com/xwikisas/application-confluence-migrator-pro/blob/main/application-confluence-migrator-pro-default/src/main/java/com/xwiki/confluencepro/internal/DocumentFilterOverrideListener.java

[trrenty]

I think it would be better to ignore it rather than throw an InitializationException. I believe the thrown exception will print the entire stack in the server logs which is quite the overkill. I believe the exception is thrown only when restarting the wiki, right? Or is it thrown even at upgrade time as well

[ChiuchiuSorin]

I'm not entirely sure what you're referring to. The initialize method is called at every startup and every upgrade, so an error may occur at every start and upgrade. I think it's ok to log the error, as it should not be a common occurrence.