Pre/post install/update scripts

[amitjoy]

This is a generic solution to address #65. I would like to propose an idea to integrate pre/post scripts. We can introduce the following JSON fields for this purpose:

1. preUpdateScript - Script to be executed before application update
2. postUpdateScript - Script to be executed after application update
3. preInstallScript - Script to be executed before application installation
4. postInstallScript - Script to be executed after application installation

• User can provide file(s) whose name(s) will be the input to these fields.

Now, to make the script work cross-platform, I believe, we can use Java shebang which has been introduced in Java 11.

For example, the following script can be executed directly on the command line:

#!/path/to/java --source version

public class MyScript {

    public static void main(String[] args) {
        System.out.println("Hello jDeploy");
    }

}

Note that, version must be replaced with the actual runtime version the application requires (must be >=11 since shebang was introduced in Java 11).

Since the user doesn't know about the location of the VM to be installed by jdeploy, the user can ignore writing this first line in the script. This can be added automatically before executing the script on the command line. If the application requires 17, this line can be automatically added to the script before executing it.

#!/path/to/java/installed/by/jdeploy --source 17

To execute the aforementioned script, we then need to simply call it using the same Java runtime required by the application:

$ java my_script.sh

Note that, the requirement is that the script file should not have .java extension. It can be anything like .sh or .jsh or .abc or .jdeploy etc.

According to Java shebang specification, if we provide arguments while executing it on the command line, the arguments will be passed to the String[] arguments in the main method similar to executing main method from Java class.

We can think of providing important informations to it, such as jDeploy version, application version to be installed or application version to be updated etc. so that consumers can make use of them if required in their scripts.

In the case of Java 8, we don't have to use the aforementioned JSON fields as Java 8 is not equipped with shebang.

[shannah]

Interesting idea. Can you give me a concrete example of something you would want to perform in each of these hooks?

[amitjoy]

Let me tell you the exact scenario why I need it:

• Things to know before jumping into the example scenario:

  • OSGi.fx is itself built on OSGi
  • In OSGi, lots of JARs are involved together like microservices in the VM
  • Every JAR is known as bundle and has its own storage assigned
  • That's why, to run OSGi framework, a folder needs to be created where the JARs are installed
  • JARs are versioned

• Scenario:

  • Let's say, the user installed 0.0.X version of the OSGi.fx application which contains several JARs having different versions
  • Now, the user is enjoying the application
  • If user wants, user can install external plugin which enhances the application's features - you can consider it as same as Eclipse IDE since Eclipse IDE can also be enhanced by different plugins (Note that, Eclipse IDE is also built on OSGi)
  • While installing OSGi.fx the application, the storage directory gets created in the home directory (works perfectly now - ✅)
  • Now, there is a new version released (0.1.Y) with lots of bundles are updated to different versions
  • User clicks on the OSGi.fx application icon
  • jdeploy now automatically downloads the latest version (0.1.Y), installs and starts it
  • This creates a problem
  • Now the new bundles which have been updated and packaged inside 0.1.Y will be unpacked into the storage area
  • But the older versions of the JARs will not be removed from the storage
  • For example, let's say, the version 0.0.X contained GSON in v1 and the version 0.1.Y contained GSON in v3
  • After jdeploy updates the application from 0.0.X to 0.1.Y, the storage will now contain two bundles of GSON - v1 and v3
  • This could have been avoided if jdeploy would have been OSGi aware and performs the application update in modular way as OSGi does
  • But this is completely out-of-scope to make jdeploy aware of OSGi specifics
  • What I would love is to make a generic solution so that I can avoid this problem too
  • I would like to remove the OSGi storage area completely when jdeploy finds that there exists a latest version and the existing application needs to be updated to the latest one
  • I can simply execute rm command but it will not be platform-independent
  • That's why, I proposed to use Java shebang which will make the solution completely platform-agnostic
  • I will simply introduce a file, called remove_osgi_storage.jsh and set it inside preUpdateScript
preUpdateScript: remove_osgi_storage.jsh
  • Now, jdeploy will execute this script after jdeploy finds that the application needs to be updated
  • So, the script will be executed just before the latest version is installed
  • preUpdateScript would suffice my requirement but to make it generic enough, I proposed the other ones as well
  • To reiterate:
    • preUpdateScript will be executed just before jdeploy installs the updated version
    • postUpdateScript will be executed just after jdeploy installs the updated version
    • preInstallScript will be executed just before jdeploy installs any version
    • postIntallScript will be executed just after jdeploy installs any version

I hope this will make it much clearer.

[amitjoy]

@shannah Is there any possibility to introduce this in near future?

[shannah]

There are some sharp corners in a feature like this, and I'm curious if this could be achieve in the app itself. Like in your app, on launch detect if the current version is "new". In which case perform your bootstrapping, which would include everything that you are requesting in the "postUpdate" script. Is that a possibility?

[amitjoy]

That's the first thing I thought before proposing the idea here if I could perform such operations during the starting phase of the application. And, it cannot be be possible due to the chicken and the egg problem. The OSGi.fx application is built on OSGi which allows collaboration of multiple JARs in the same VM. When OSGi framework starts, the framework uses a dedicated storage area to unpack the JARs and create respective classloaders for them to communicate with each other. I would like to delete the storage area before every update which I would like to do before the framework even starts. If I delete the storage area within the framework, it would not even start at all. That's why, I thought about it deeply and proposed to integrate JShell which is by default integrated now and we surely can make use of, as lots of consumers will then be able to write scripts in plain Java. I think such a feature would be beneficial for many users to hook into the different phases and perform custom operations as well.

[shannah]

So you don't have the ability to run code before this? Like at the beginning of the actual main method before the osgi framework is initialized?

[amitjoy]

Unfortunately not 😔, otherwise, I would have implemented it much earlier.

[shannah]

I've added support adding a jar named "jdeploy-prelaunch.jar" to the same directory as your app jar file. jDeploy will check for this jar's existence and run it before launching your main jar.

That should enable you to do everything that you need.

This change is not deployed yet, but will be available with the next release (4.0) upcoming within the next couple of weeks.

[amitjoy]

@shannah ?

[shannah]

There will be system properties with the app version. You can use this to determine if you need to perform any housekeeping.

[amitjoy]

@shannah Thanks a lot for your quick response. Could you kindly point me to any documentation for this? In addition, do you know when the next release will be built?

[amitjoy]

@shannah Could you kindly point me to any documentation for this?

[amitjoy]

@shannah ping