From time to time you have thought a module will be used or you have added a peace of functionality which is deprecated. It's sometimes very complex to remove that peaces. I think there will be never a way to automaticly remove everything from a module, because it could be that there is something bootstrapped which is unpossible to undo.

What could be realy interessting is a module which shows the necessary steps which you need to do to remove a module including steps like removing workspace in the database or whatever is needed.

  • No labels

4 Comments

  1. Michael Mühlebach

    Would be very interesting if there was a good way how to actually automate this. For certain modules, like multisite, the manual work can be quite tedious.

    In the past we added for remove legacy modules, remove tasks in main. But this is more a workaround than anything else.

  2. Marvin Kerkhoff

    The complex issue is the removal of the JCR items with the value before you installed a module. I think introducing uninstall tasks could be interessting as well. Then you are flexible enough to add your own logic.

    1. Michael Mühlebach

      Yes uninstall tasks sound like a very good idea. Especially because we would use a toolset developers are already familiar. Unfortunately the way we currently "uninstall" modules, removing the jar or dependency from the war, will make sure those tasks will not be around as well. So the basic question where should those tasks be stored might be complex as well.

      One approach would be to rethink how we install and remove additional modules. For example by treating modules as plug-ins you have to install not just pack into war. But if install/uninstall tasks rely on that, the system could become more rigid. So maybe not the best approach.

      Maybe we could load those tasks and serialize them until they are needed (we would kinda install an uninstall task) ... although it might work, it will be a nightmare to debug if anything goes wrong. A middle-ground might be to allow certain tasks to be provided by file. Either as declarative tasks in YAML files of even groovy.

  3. Marvin Kerkhoff

    Hi Michael,

    I guess rethinking the current installation process could solve several issues. I also know that this could have a deep inpect on stability of the product itself. (But honestly every update or installation has a risk)

    Status Quo:

    1. An installation or update is always triggered immediately after a restart. There are several causes why i don't want to have an update immediately.
    2. If a installation failed - Classic: UUID already exist - the whole server is crashing and there is no way to skip the installation. (only by removing one or more JARs)
      1. To fix the issue i can remove the JAR, start, remove the existing UUID, copy the JAR again and restart.
      2. Skipping the installation and restart it afterwards
    3. There is no way to trigger a reinstallation of a module without a restart. 
    4. There is no way to trigger the bootstrap of sample data manual which would be cool to have more control.

    With a setup where you can manual/optional trigger installations you would solve the problem that the JAR doesn't exist for uninstall tasks.