Servoy WAR Builder - BitBucket Pipelines

Servoy WAR Builder - BitBucket Pipelines

Servoy WAR Exporter

This Docker image for BitBucket Pipelines allows users to build Servoy WAR files, using options from Servoy's bundled WAR export. In order to use this Action, you will need an All Products Pack API key from Servoy Components.

See the LICENSE for more information on the dual licensing for commercial projects.

Examples

To view a full example project, including the workflow file, please see our examples repo.

Build the WAR

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.1.11
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
pipelines:
  default:
   - step: *war-build

WAR + Upload to BitBucket Downloads

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.1.11
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/bitbucket-upload-file:0.1.2
            variables:
              BITBUCKET_USERNAME: $BITBUCKET_USERNAME
              BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD
              FILENAME: "MySolution.war"
pipelines:
  default:
   - step: *war-build

WAR + S3 Upload

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.1.11
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/aws-s3-deploy:0.3.8
            variables:
              AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
              AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
              AWS_DEFAULT_REGION: 'us-east-1'
              S3_BUCKET: 'bbci-example-s3-deploy'
              LOCAL_PATH: 'MySolution.war'
              ACL: 'public-read'
pipelines:
  default:
   - step: *war-build

WAR + Azure Upload

You will need to follow the setup instructions for this integration.

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.1.11
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: microsoft/azure-cli-run:1.0.0
            variables:
              AZURE_APP_ID: $AZURE_APP_ID
              AZURE_PASSWORD: $AZURE_PASSWORD
              AZURE_TENANT_ID: $AZURE_TENANT_ID
              CLI_COMMAND: 'az storage blob upload --file MySolution.war --container-name $containerName --account-name $storageAccount --auth-mode login'
pipelines:
  default:
   - step: *war-build

WAR + SFTP Upload

image: atlassian/default-image:3

options:
  size: 2x

definitions:
  services:
    docker:
      memory: 7168
  steps:
    - step: &war-build
        name: WAR Build
        script:
          - pipe: docker://itechpros/servoy-war-builder:0.1.11
            variables:
              SERVOY_VERSION: 2023.03.2.3844
              API_KEY: ${SERVOY_COMPONENTS_API_KEY}
              SOLUTION_NAME: MySolution
              DEFAULT_ADMIN_USER: ${SERVOY_DEFAULT_ADMIN_USER}
              DEFAULT_ADMIN_PASSWORD: ${SERVOY_DEFAULT_ADMIN_PASSWORD}
              PROPERTIES_FILE: prop_files/servoy.build.properties
          - pipe: atlassian/sftp-deploy:0.8.0
            variables:
              USER: ${FTP_USER}
              PASSWORD: ${FTP_PASSWORD}
              SERVER: ${FTP_SERVER}
              REMOTE_PATH: '/my/remote/path'
              LOCAL_PATH: 'MySolution.war'
              EXTRA_ARGS: '-o VerifyHostKeyDNS=yes -o StrictHostKeyChecking=no'
pipelines:
  default:
   - step: *war-build

WAR + Auto Deploy

Coming soon!

Options

  • SERVOY_VERSION 🔴 required
    The full Servoy version to use for the build. To see a list of supported versions, please view the "Supported Servoy Versions" section of this document.
    NOTE: If you're using a version of Servoy that does not come with a bundled Java version, please be sure to use at least version 0.3.2 of the pipe.
  • API_KEY 🔴 required
    All Products Pack API key obtained from the Servoy Components website. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
  • SOLUTION_NAME 🔴 required
    Name of the primary solution to export to the WAR file.
    WAR export flag: -s
  • DEFAULT_ADMIN_USER 🔴 required
    Default admin username to include in the WAR file. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
    WAR export flag: -defaultAdminUser
  • DEFAULT_ADMIN_PASSWORD 🔴 required
    Default admin password to include in the WAR file. We recommend putting this value in BitBucket Repository Secrets to prevent accidental exposure through the BitBucket Pipeline logs, or from unauthorized users.
    WAR export flag: -defaultAdminPassword
  • PROPERTIES_FILE 🔴 required
    Path and name of the properties file used to start the exporter. Path should be relative to the root directory of your GitHub repository.
    WAR export flag: -p
    Examples:
variables:  
  # ...
  PROPERTIES_FILE: servoy.war.properties        # Use the servoy.war.properties file in the root directory of the repository
  PROPERTIES_FILE: mydir/servoy.war.properties  # Use the servoy.war.properties file in the "mydir" directory of the repository
  • IGNORE_BUILD_ERRORS
    Ignores build errors 🟡 (warning: use of this flag is discouraged; it can cause invalid solutions to be exported)
    WAR export flag: -ie
    Default: false
    Examples:
  variables:
    # ...
    IGNORE_BUILD_ERRORS: true   # Ignore build errors
    IGNORE_BUILD_ERRORS: false  # Don't ignore build errors (default)
  • SKIP_BUILD
    No build markers will be generated. This can greatly decrease export time 🟡 (warning: use of this flag is discouraged; it can cause invalid solutions to be exported)
    WAR export flag: -sb
    Default: false Examples:
  variables:
    # ...
    SKIP_BUILD: true   # Don't generate build markers.
    SKIP_BUILD: false  # Generate build markers (default)
  • DBI
    Export based on DBI files (even if database servers are available).
    WAR export flag: -dbi
    Default: false
    Examples:
  variables:
    # ...
    DBI: true   # Export based on DBI files
    DBI: false  # Don't export based on DBI files (default)
  • PROPERTIES_FILE_WAR
    Path and name of the properties file to be included in the WAR. Path should be relative to the root directory of your GitHub repository. If a WAR property file is not supplied, we will use the property file specified in properties-file.
    WAR export flag: -pfw
    Examples:
  variables:
    # ...
    PROPERTIES_FILE_WAR: servoy.war.properties        # Use the servoy.war.properties file in the root directory of the repository
    PROPERTIES_FILE_WAR: mydir/servoy.war.properties  # Use the servoy.war.properties file in the "mydir" directory of the repository
  • BEANS
    Space separated list of (smart/web client) beans to export
    WAR export flag: -b
    Default: all beans are exported
    Examples:
  variables:
    # ...
    BEANS: bean1.jar bean2.zip  # Include bean1.jar and bean2.zip in the export
    BEANS: <none>               # Don't include any beans in the export
  • EXCLUDE_BEANS
    Space separated list of beans to be excluded from the export
    WAR export flag: -excludeBeans
    Examples:
  variables:
    # ...
    EXCLUDE_BEANS: bean1.jar bean2.zip  # Don't include bean1.jar and bean2.zip in the export
  • LAFS
    Space separated list of look-and-feels (smart client) to export
    WAR export flag: -l
    Default: all lafs are exported Examples:
  variables:
    # ...
    LAFS: laf1 laf2  # Include laf1 and laf2 in the export
    LAFS: <none>     # Don't include any lafs in the export
  • EXCLUDE_LAFS
    Space separated list of look-and-feels to be excluded from the export
    WAR export flag: -excludeLafs
    Examples:
  variables:
    # ...
    EXCLUDE_LAFS: laf1 laf2  # Exclude laf1 and laf2 from the export
  • DRIVERS
    Space separated list of JDBC (database) drivers to export
    WAR export flag: -d
    Default: all drivers are exported
    Examples:
  variables:
    # ...
    DRIVERS: driver1.jar driver2.jar  # Include driver1.jar and driver2.jar in the export
    DRIVERS: <none>                   # Don't include any drivers in the export
  • EXCLUDE_DRIVERS
    Space separated list of drivers to be excluded from the export
    WAR export flag: -excludeDrivers
    Examples:
  variables:
    # ...
    EXCLUDE_DRIVERS: driver1.jar driver2.jar  # Exclude driver1.jar and driver2.jar from the export
  • PLUGINS
    Space separated list of plugins to export
    WAR export flag: -pi
    Default: all plugins are exported
  variables:
    # ...
    PLUGINS: plugin1.jar plugin2.jar  # Include plugin1.jar and plugin2.jar in the export
    PLUGINS: <none>                   # Don't include any plugins in the export
  • EXCLUDE_PLUGINS
    Space separated list of plugins to be excluded from the export
    WAR export flag: -excludePlugins
    Examples:
  variables:
    # ...
    EXCLUDE_PLUGINS: plugin1.jar plugin2.jar  # Don't include plugin1.jar and plugin2.jar in the export
  • COMPONENTS
    Space separated list of components to export
    WAR export flag: -crefs
    Default: all
    Examples:
  variables:
    # ...
    COMPONENTS: component1 component2  # Include component1 and component2 in the export
    COMPONENTS: all                    # Include all components in the export (default)
  • EXCLUDE_COMPONENTS
    Space separated list of components to be excluded from the export
    WAR export flag: -excludeComponentPkgs
    Examples:
  variables:
    # ...
    EXCLUDE_COMPONENTS: component1 component2  # Exclude component1 and component2 from the export
  • SERVICES
    Space separated list of services to export
    WAR export flag: -srefs
    Default: all
    Examples:
  variables:
    # ...
    SERVICES: service1 service2  # Include service1 and service2 in the export
    SERVICES: all                # Include all services in the export (default)
  • EXCLUDE_SERVICES
    Space separated list of services to be excluded from the export
    WAR export flag: -excludeServicePkgs
    Examples:
  variables:
    # ...
    EXCLUDE_SERVICES: service1 service2  # Exclude service1 and service2 from the export
  • ADDITIONAL_SOLUTIONS
    Space separated list of solutions that must be exported, but are not in the current solution's modules (for example, solutions for batch processors)
    WAR export flag: -nas
    Examples:
  variables:
    # ...
    ADDITIONAL_SOLUTIONS: mod_batch_processor mod_rest_api  # Includes solutions "mod_batch_exporter" and "mod_rest_api" in the export, even if the primary solution doesn't include them as dependencies
  • EXPORT_METADATA
    Export metadata tables
    WAR export flag: -md
    Default: false
    Examples:
  variables:
    # ...
    EXPORT_METADATA: true   # Include metadata in the export
    EXPORT_METADATA: false  # Don't include metadata in the export (default)
  • CHECK_METADATA
    Check that metadata for metadata tables is the same for each table, both in the according workspace file and in the actual table in the database before exporting
    WAR export flag: -checkmd
    Default: false
  variables:
    # ...
    CHECK_METADATA: true   # Verify metadata
    CHECK_METADATA: false  # Don't verify metadata (default)
  • SAMPLE_DATA
    Export sample data
    WAR export flag: -sd
    Default: false
    Examples:
  variables:
    # ...
    SAMPLE_DATA: true   # Export sample data
    SAMPLE_DATA: false  # Don't export sample data (default)
  • SAMPLE_DATA_ROW_COUNT
    Number of rows of sample data to export per table
    WAR export flag: -sdcount
    Examples:
  variables:
    # ...
    SAMPLE_DATA_ROW_COUNT: 50  # Include 50 rows of sample data per table in the export
  • I18N
    Export i18n data
    WAR export flag: -i18n
    Default: false
    Examples:
  variables:
    # ...
    I18N: true   # Include i18n data in the export
    I18N: false  # Don't include i18n data in the export (default)
  • USERS
    Exports users
    WAR export flag: -users
    Default: false
    Examples:
  variables:
    # ...
    USERS: true   # Include users in the export
    USERS: false  # Don't include users in the export
  • TABLES
    Export all table information about tables from referenced servers
    WAR export flag: -tables
    Default: false
    Examples:
  variables:
    # ...
    TABLES: true   # Include table information from referenced servers in the export
    TABLES: false  # Don't include table information from referenced servers in the export (default)
  • WAR_FILE_NAME
    The name of the WAR file
    WAR export flag: -warFileName
    Examples:
  variables:
    # ...
    WAR_FILE_NAME: MyFile.war  # Exports the WAR file to MyFile.war, instead of <primary solution name>.war
  • OVERWRITE_GROUPS
    Overwrites groups
    WAR export flag: -overwriteGroups
    Default: false
    Examples:
  variables:
    # ...
    OVERWRITE_GROUPS: true   # Overwrites groups
    OVERWRITE_GROUPS: false  # Doesn't overwrite groups (default)
  • ALLOW_SQL_KEYWORDS
    Allows SQL keywords
    WAR export flag: -allowSQLKeywords
    Default: false
    Examples:
  variables:
    # ...
    ALLOW_SQL_KEYWORDS: true   # Allows table/column names that are reserved SQL keywords
    ALLOW_SQL_KEYWORDS: false  # Doesn't allow table/column names that are reserved SQL keywords (default)
  • STOP_ON_DATA_MODEL_CHANGES
    Stops import if the data model changes
    WAR export flag: -stopOnDataModelChanges
    Default: false
    Examples:
  variables:
    # ...
    STOP_ON_DATA_MODEL_CHANGES: true   # Stops the import if it results in a data model change
    STOP_ON_DATA_MODEL_CHANGES: false  # Don't stop the import if it results in a data model change (default)
  • ALLOW_DATA_MODEL_CHANGES
    A space separated list of server names that allow data model changes. If the value is "all", then data model changes are allowed on all servers
    WAR export flag: -allowDataModelChanges
    Examples:
  variables:
    # ...
    ALLOW_DATA_MODEL_CHANGES: server1 server2  # Allow data model changes only on the server1 and server2 database servers
    ALLOW_DATA_MODEL_CHANGES: all              # Allow data model changes on all servers
  • SKIP_DATABASE_VIEWS_UPDATE
    Skips database views update
    WAR export flag: -skipDatabaseViewsUpdate
    Default: false
    Examples:
  variables:
    # ...
    SKIP_DATABASE_VIEWS_UPDATE: true   # Skips updating database views
    SKIP_DATABASE_VIEWS_UPDATE: false  # Doesn't skip updating database views (default)
  • OVERRIDE_SEQUENCE_TYPES
    Overrides sequence types
    WAR export flag: -overrideSequenceTypes
    Default: false
    Examples:
  variables:
    OVERRIDE_SEQUENCE_TYPES: true   # Overrides the sequence types in the Servoy repository database with the sequence types in the export
    OVERRIDE_SEQUENCE_TYPES: false  # Doesn't override the sequence types in the Servoy repository database (default)
  • OVERRIDE_DEFAULT_VALUES
    Overrides default values
    WAR export flag: -overrideDefaultValues
    Default: false
    Examples:
  variables:
    # ...
    OVERRIDE_DEFAULT_VALUES: true   # Overrides the column default values in the Servoy repository database with the default values in the export
    OVERRIDE_DEFAULT_VALUES: false  # Doesn't override the default values in the Servoy repository database (default)
  • INSERT_NEW_I18N_KEYS_ONLY
    Inserts new i18n keys only
    WAR export flag: -insertNewI18NKeysOnly
    Default: false
    Examples:
  variables:
    # ...
    INSERT_NEW_I18N_KEYS_ONLY: true   # Only inserts new (doesn't update existing) i18n keys
    INSERT_NEW_I18N_KEYS_ONLY: false  # i18n keys are inserted and updated based on the export (default)
  • IMPORT_USER_POLICY
    0 = don't
    1 = create users & update groups
    2 = overwrite completely
    WAR export flag: -importUserPolicy
    Examples:
  variables:
    # ...
    IMPORT_USER_POLICY: 0  # Don't import any users
    IMPORT_USER_POLICY: 1  # Create users & update groups (don't update existing users) (default)
    IMPORT_USER_POLICY: 2  # Overwrite users based on the export
  • ADD_USERS_TO_ADMIN_GROUP
    Adds users to admin group
    WAR export flag: -addUsersToAdminGroup
    Default: false
    Examples:
  variables:
    # ...
    ADD_USERS_TO_ADMIN_GROUP: true   # Adds users to admin group
    ADD_USERS_TO_ADMIN_GROUP: false  # Doesn't add users to admin group (default)
  • UPDATE_SEQUENCES
    Updates sequences
    WAR export flag: -updateSequences
    Default: false Examples:
  variables:
    # ...
    UPDATE_SEQUENCES: true   # Updates Servoy sequences when the WAR is imported
    UPDATE_SEQUENCES: false  # Doesn't update Servoy sequences when the WAR is imported (default)
  • UPGRADE_REPOSITORY
    Automatically upgrade repository if needed
    WAR export flag: -upgradeRepository
    Default: false
    Examples:
  variables:
    # ...
    UPGRADE_REPOSITORY: true   # Upgrades the Servoy repository (if needed)
    UPGRADE_REPOSITORY: false  # Doesn't upgrade the Servoy repository (default)
  • CONTEXT_FILE_NAME
    Path to a Tomcat context.xml that should be included into the WAR/META-INF/context.xml. Path should be relative to the root directory of your GitHub repository.
    WAR export flag: -contextFileName
    Examples:
  variables:
    # ...
    CONTEXT_FILE_NAME: context.xml        # Use the context.xml file in the root directory of the repository
    CONTEXT_FILE_NAME: mydir/context.xml  # Use the context.xml file in the "mydir" directory of the repository
  • USE_AS_REAL_ADMIN_USER
    The default user login will be available as a normal admin user in the solutions as well
    WAR export flag: -useAsRealAdminUser
    Default: false
    Examples:
  variables:
    # ...
    USE_AS_REAL_ADMIN_USER: true   # The default admin user will be treated as a normal admin user in the solutions
    USE_AS_REAL_ADMIN_USER: false  # THe default admin user will not be treated as a normal admin user in the solutions (default)
  • DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES
    SKIP overwrite of old DB server properties
    WAR export flag: -doNotOverwriteDBServerProperties
    Default: false
    Examples:
  variables:
    # ...
    DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES: true   # Doesn't overwrite DB server properties on import
    DO_NOT_OVERWRITE_DB_SERVER_PROPERTIES: false  # Allows DB server properties to be overwritten (default)
  • OVERWRITE_ALL_PROPERTIES
    Overwrite all (potentially changed via admin page) properties of a previously deployed WAR application with the values from the servoy.properties of this WAR export
    WAR export flag: -overwriteAllProperties
    Default: false
    Examples:
  variables:
    # ...
    OVERWRITE_ALL_PROPERTIES: Overwrite all Servoy server properties based on the properties file included in this import
    OVERWRITE_ALL_PROPERTIES: Don't overwrite any Servoy server properties (default)
  • LOG4J_CONFIGURATION_FILE
    A path to a Log4J configuration file that should be included instead of the default one. Path should be relative to the root directory of your GitHub repository.
    WAR export flag: -log4jConfigurationFile
    Examples:
  variables:
    # ...
    LOG4J_CONFIGURATION_FILE: log4j.xml        # Use the log4j.xml file in the root directory of the repository
    LOG4J_CONFIGURATION_FILE: mydir/log4j.xml  # Use the log4j.xml file in the "mydir" directory of the repository
  • WEB_XML_FILE_NAME
    A path to a web.xml that should be included instead of the default one. Path should be relative to the root directory of your GitHub repository.
    WAR export flag: -webXmlFileName
    Examples:
  variables:
    # ...
    WEB_XML_FILE_NAME: web.xml        # Use the web.xml file in the root directory of the repository
    WEB_XML_FILE_NAME: mydir/web.xml  # Use the web.xml file in the "mydir" directory of the repository
  • NG2
    Export Titanium NG2 binaries. If 'sourcemaps' is given, sourcemaps will be generated for .ts files - useful for debugging WAR export flag: -ng2
    Examples:
  variables:
    # ...
    NG2: true        # Export NG2 resources
    NG2: false       # Don't export NG2 resources
    NG2: sourcemaps  # Export sourcemaps along with NG2 resources
  • NG1
    Export NG1 client resources
    WAR export flag: -ng1
    Default: false
  variables:
    # ...
    NG1: true   # Export NG1 resources
    NG1: false  # Don't export NG1 resources (default)
  • LICENSES
    Space delimited licenses to include in the WAR file. Format should be ' '. If you have multiple licenses, use multiple lines. We recommend putting the Servoy license value in GitHub Action Secrets to prevent accidental exposure through the GitHub Action logs, or from unauthorized users.
    Examples:
  variables:
    # ...
    LICENSES: "Servoy Components" ${{ secrets.SERVOY_LICENSE}} SERVER   # Use a single license in the export
    LICENSES: |                                                         # Use multiple licenses in the export
      "Servoy Components" ${{ secrets.SERVOY_COMPONENTS_LICENSE }} SERVER
      "My Other Company" ${{ secrets.MY_OTHER_COMPANY_LICENSE }} 1000
  • EXTRAS_FOLDER
    Path to the extras folder that contains additional plugins, drivers, etc. that should be included in the Servoy install. Path should be relative to the root directory of your GitHub repository. This folder should contain a sub-folder named "application_server".
    Examples:
  variables:
    # ...
    EXTRAS_FOLDER: ServoyDeveloperExtras  # Use the plugins, drivers, etc. in ServoyDeveloperExtras/application_server in our export
  • TIMEOUT
    Number of milliseconds to allow the build process to run before terminating it. Defaults to 30 minutes.
    Examples:
    variables:
      # ...
      TIMEOUT: 600000   # 10 minute timeout
      TIMEOUT: 1800000  # 30 minute timeout
      TIMEOUT: 3600000  # 1 hour timeout
  • POST_WAR_EXTRAS_FOLDER
    Path to the extras folder that contains files that should be copied into the WAR after it's built. Path should be relative to the root directory of your BitBucket repository. NOTE: This option is only available in version 0.2.0 or higher.
    Examples:
    variables:
      # ...
      POST_WAR_EXTRAS_FOLDER: PostWarExtras  # Include the files & folders in PostWarExtras/ in our WAR
  • BUILD_MAX_MEMORY
    Maximum amount of memory that can be consumed by the build process (default 2 GB). NOTE: This option is only available in version 0.3.0 or higher.
    Examples:
    variables:
      # ...
      BUILD_MAX_MEMORY: 2048m  # Limit the WAR builds to 2 GB of memory
      BUILD_MAX_MEMORY: 4096m  # Limit the WAR builds to 4 GB of memory

Supported Servoy Versions

Servoy 6

  1. 6.1.0.1418
  2. 6.1.1.1420
  3. 6.1.2.1421
  4. 6.1.3.1424
  5. 6.1.4.1429
  6. 6.1.5.1433
  7. 6.1.6.1439

Servoy 7

  • 7.2.0.2013
  • 7.3.0.2018
  • 7.3.1.2022
  • 7.4.0.2026
  • 7.4.1.2028
  • 7.4.2.2033
  • 7.4.3.2036
  • 7.4.4.2039
  • 7.4.5.2041
  • 7.4.6.2043
  • 7.4.7.2045
  • 7.4.8.2046
  • 7.4.9.2047
  • 7.4.10.2049

Servoy 8

  • 8.0.0.3020
  • 8.1.0.3027
  • 8.1.1.3029
  • 8.1.2.3031
  • 8.1.3.3033
  • 8.1.4.3035
  • 8.2.0.3103
  • 8.2.1.3105
  • 8.2.2.3107
  • 8.2.3.3109
  • 8.3.1.3205
  • 8.3.2.3207
  • 8.3.3.3209
  • 8.4.0.3402

Servoy 2019

  • 2019.03.3412
  • 2019.06.1.3503
  • 2019.06.2.3504
  • 2019.09.3522
  • 2019.12.3542
  • 2019.12.1.3543

Servoy 2020

  • 2020.03.3562
  • 2020.03.1.3563
  • 2020.03.2.3564
  • 2020.03.3.3565
  • 2020.06.3582
  • 2020.06.1.3583
  • 2020.09.3602
  • 2020.12.3622
  • 2020.12.1.3623

Servoy 2021

  • 2021.03.3642
  • 2021.03.1.3643
  • 2021.03.2.3644
  • 2021.03.3.3645
  • 2021.06.3683
  • 2021.09.3703
  • 2021.12.3722
  • 2021.12.1.3723
  • 2021.12.2.3724

Servoy 2022

  • 2022.03.3742
  • 2022.03.1.3743
  • 2022.03.2.3744
  • 2022.03.3.3745
  • 2022.03.4.3746
  • 2022.03.5.3747
  • 2022.06.3782
  • 2022.09.3803
  • 2022.09.1.3804
  • 2022.09.2.3805
  • 2022.12.0.3823
  • 2022.12.1.3824

Servoy 2023

  • 2023.03.3842
  • 2023.03.1.3843
  • 2023.03.2.3844
  • 2023.03.3.3845
  • 2023.06.3883
  • 2023.09.3902
  • 2023.09.1.3903 (you'll need version 0.2.0 or higher to utilize this version)

    • Related Articles

    • Why doesn't it work in Servoy Developer?

      The plugin only works with Java 8, and Java 9 currently. Java 10+ support is in progress.  Recent Servoy Installers bundle the latest java version into it.  To edit the java version, edit the servoy.ini file located in the developer folder of your ...
    • What is the preferred way to uninstall IT2BE Servoy Components?

      Not, we insist that you keep using them :) Ok, so you really want to uninstall the Components? The preferred way to remove our Components is by using our IT2BE Components Manager. The IT2BE Components Manager will first create an Archive in the ...
    • I don't understand the option 'Upgrade to Servoy 4+' in your store.

      When you are still using the 'Servoy 3.5 version' (pre Servoy 4 Eclipse) of our Components chances are that you do not yet have a maintenance subscription. We created an option, for all Commercial Components, to upgrade. Just look for 'UPGRADE xxx ...
    • What could be a reason that the Smart Client fails?

      The Exchange and ExchangeWS Plug-ins are so called client-server Plug-ins. For the smart client to work we need the following server setting: 'Servoy Server Home' > 'Smart Client Settings' > 'servoy.application_server.trustedRemotePlugins' = ...
    • What could be a reason that the Smart Client fails?

      The LDAPclient Plug-in is a so called client-server Plug-in. For the smart client to work we need the following server setting: 'Servoy Server Home' > 'Smart Client Settings' > 'servoy.application_server.trustedRemotePlugins' = ...