Public Release Notes - Gradle Tools - Version 1.1

Note

This Gradle tools version is included in Intershop 7 version 7.4.6.2.

This Gradle tools version is based on Gradle 1.8.

1 New and Noteworthy

1.1 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:

Advanced Cartridge Order

This example assumes that your cartridge order consists of:

  • (A subset of ) cartridges from an inherited assembly, followed by
  • Your own cartridges

If you need to change the order of inherited cartridges or add your cartridges in the middle, please see Recipe: Add Cartridges to an Assembly in  the Cookbook - Gradle Assembly Tools (valid to 7.8).

  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.)

1.2 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:

Migration

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

config block in settings.gradle
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 block in settings.gradle
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          
        }
    }
}

1.3 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:

1.4 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.

1.5 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).

Note

This only works in conjunction with Intershop 7 version >= 7.4.6.2. In 7.4.6.1 the debug ports are still disabled for developers.

1.6 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'.

Note

This only works for Intershop 7 version >= 7.4.6.2. If using 7.4.6.1 it is still necessary to set shareDirectory to an existing, empty directory as a workaround when deploying host type 'webserver'.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets