New and Noteworthy

Inherit Cartridge Order

The cartridge order determines the execution order in the DBInit, the lookup of pipelines, templates etc. The cartridge order can be configured in the assembly. You can now specify the order more flexibly.

Especially, you can derive the order of cartridges in your assembly from the order in an inherited assembly. The advantage of this approach compared with the cartridge-order.txt file is that cartridges added to the inherited assembly are automatically added to the cartridge order of your assembly.

See Recipe: Add Cartridges to an Assembly in  the Cookbook - Gradle Assembly Tools (valid to 7.8).

Migration

You can keep using your existing cartridge-order.txt file. In this case no action is necessary.

To derive the cartridge order from the order in an inherited assembly, perform the following steps in a developer environment:

1. Run gradlew publish in your assembly.
2. Rename the file <ASSEMBLY>/target/publications/ivy/ivy.xml to ivy.xml.original

3. Add the following block to the build.gradle file of your assembly:

   build.gradle

   assembly {
       cartridges {
   		// TODO: Replace by <org>:<name> of the inherited assembly
   		// TODO: Replace ['cartridge_1', 'cartridge_2'] by the list of your cartridges in the desired order
   		order = listFromAssembly('<org>:<name>') + ['cartridge_1', 'cartridge_2']
       }
   }

4. Remove the cartridge-order.txt file of your assembly.
5. Run gradlew publish in your assembly to verify your migration.
6. Compare the newly created <ASSEMBLY>/target/publications/ivy/ivy.xml to ivy.xml.original. Both should be equal besides the publication attribute. (Or if any dependency elements are permuted, make sure the change in cartridge order does not break your DBInit/application.)

Enhanced Multicast Configuration

The multicast configuration through the deployment has been enhanced in several ways:

1. You can now configure the multicast channel for ORM cache synchronization (in orm.properties) through the deployment.
2. The network interface to bind multicast communication are now configured separately for each appserver host (instead of globally for the cluster).
3. For developers multicast communication is bound to the loopback interface.
   This way all developers can use the same multicast address and port without undesired events across clusters.
4. The multicast extension has been refactored: Each multicast channel (tcm, appserver, orm, cache) has a separate DSL block.

See:

• Recipe: Configure the Deployment   in the Cookbook - Gradle Deployment Tools (7.4 CI - ICM 7.7).
• MulticastExtension  in the Reference - Gradle Deployment Tools.

Migration

The following DSL syntax in the settings.gradle file of the deployment is deprecated:

config {
    multicast {
        appserverMulticastAddress = '239.192.1.1'
        appserverMulticastPort    = 50001
        tcmMulticastAddress       = '239.192.1.2'
        tcmMulticastPort          = 50002
        cacheMulticastAddress     = '239.192.1.3'
        cacheMulticastPort        = 50003
    }
}

Replace it by the following syntax:

config {
    multicast {
        appserver {
            address = '239.192.1.2'
            port = 50001                       
        }
        tcm {
            address = '239.192.1.2'
            port = 50002
        }

        cache {
            address = '239.192.1.2'
            port = 50003
        }

        orm {               
            address = '239.192.1.2'
            port = 50004          
        }
    }
}

New Filter FullContentFilter in Deployment

A new content filter was added to the deployment that can perform arbitrary operations on the whole content of the filtered file as a string. Using this filter covers most applications for which you previously had to create a customer content filter class.

See:

• Recipe: Change Deployed File Content With Filters  in Cookbook - Gradle Deployment Tools (7.4 CI - ICM 7.7).
• FullContentFilter in the Reference - Gradle Deployment Tools.

Deployment Gradle Tasks Report Correct Status

When rerunning the same Gradle based deployment multiple times the output did not display 'UP-TO-DATE' behind tasks that performed no effective changes. This is now fixed.

Open Debug Ports for Developer Environments

When deploying as a developer the start scripts in the deployed server now open Java debug ports for:

• The application server
• DBInit and DBTool
• The Intershop test runner

The ports can be configured in the <ASSEMBLY>/environment.properties (see <ASSEMBLY>/environment.properties.sample).

Unnecessary Configuration shareDirectory for Webserver Deployment Removed

It is no longer necessary to set the shareDirectory property in the settings.gradle when deploying the host type 'webserver'.