Preparing Module Update

When new versions of modules are ready and their previous versions are used in production, you need to handle their running model instances:

If modules are not restartable, you need to perform model update on all running model instances. Mind that the process can be complex and is generally discouraged.
If modules introduce changes to data models with shared records, you need to update the database tables that hold the data first (you can generate database schema update scripts for the new model versions from the Management perspective of Designer, and modify them as necessary).

The artifacts to distribute when updating modules are

modules exported into deployable zip files

Deployable zip files of the modules in the <YOUR_APP>-model projects are created as part of the maven build in the <YOUR_APP>-model-exporter project. You can create them also manually.
model update definition files
database-schema update scripts

Update of the Custom LSPS Application

If you have changed only the code of the LSPS Application, it is enough to build the new EAR and deploy it.

If you need to update modules as well, make sure

to update modules, running model instances, and underlying database tables;
the application does not introduce any backward-incompatible changes; For example, if you have removed a custom function from your application and the function is being used by a running model instance, the update of the model instance will fail.

The artifacts necessary for update of LSPS Application with backward-compatible changes are

LSPS Application EAR If providing updated of modules as well:
optionally:
- new modules and models exported with GO-BPMN export
- model update definition files
- database-schema update scripts

Preparing Upgrade of the Patch Version

Important: This upgrade procedure does not add any new features of the newer version to your application. To upgrade fully and get all the new features, follow the procedure for upgrades to minor and major versions.

If you want to upgrade to a new patch version of LSPS, To upgrade the entire LSPS stack to a new patch version (x.y.Z), you need to do the following:

Install the new Designer and LSPS Repository.
In the root pom.xml, update the LSPS version:
1. Update the parent version
```
<parent>
  <groupId>com.whitestein.lsps</groupId>
  <artifactId>lsps</artifactId>
  <version><NEW_VERSION></version>
</parent>
```
2. Update the lsps version
```
<properties>
  <lsps.version><NEW_VERSION></lsps.version>
</properties>
```
3. In the <YOUR_APP>-embedded project, remove the h2 directory (this
4. If present, remove the createConverterForRenderer() method in <-vaadin/src/main/java/sk/eko/formstestapp/connectors/LspsFormComponentFactory.java>. is a testing database and will be recreated on the launch of the embedded server).
In Window > Preferences, check the value of the M2_REPO classpath variable under Java > Build Path > Classpath Variables: make sure it points to the correct repository.
Build the application.
Deploy the EAR to your application server.

The artifacts to distribute:

LSPS Application EAR

Preparing Upgrade of the Minor or Major Version

To upgrade the entire LSPS stack to a new minor (x.y) of major version (x) of LSPS, do the following:

Install and run the new Designer with the LSPS Maven repository.
Generate a new LSPS Application.
Commit the initial state of the application to separates your changes from the initial state of the application.
Apply the commits with customizations from your application: when under git, create a patch from the commits that customized the LSPS Application since it was generated and apply it on the newly generated LSPS Application. You can check the release notes for any backward-incompatible changes. Also check the summary of LSPS Application changes. in the new LSPS Application. You can check the release notes for any backward-incompatible changes.
Build the application.
Prepare upgraded modules:
1. Import the modules into the workspace.
2. For non-restartable models, prepare model update definitions;
3. If the modules change the data model of persisted data (shared records and their relationships), prepare also the database-schema update scripts.
4. Export the updated models with GO-BPMN Export.

The artifacts to distribute when upgrading LSPS are

LSPS Application EAR
modules and models exported with GO-BPMN export
model update definition files
database schema script for business data when applicable

Important Points of Considerations when Migrating LSPS Application 3.2 to 3.3

The LSPS Application 3.3 has been refactored:

Classes that generally do not require modifications have been removed and are now provided as a library.
Classes that are intended to be modified have been removed and exposed via their App<CLASSNAME> versions:
- If you have previously modified the AppLayout class, you will now modify the AppAppLayout class;
- If you have previously modified the LspsUi class, you will now modify the AppLspsUi class;
The application uses Vaadin 8. To use the previous component implementation in Vaadin 7, do the following:
- In LspsUIComponentFactory change the extended class from UIComponentFactoryImpl to UIComponentFactoryV7Impl
- In your components, change the imported vaadin packages to its v7 version, for example, change com.vaadin.ui.utils to com.vaadin.v7.ui.
Consider migrating your forms to the UI over Vaadin 8.

Unless you move the content from the original classes to the new classes, your custom LSPS Application will work as expected but will not benefit from the new features of the application.