Migrate Tools Version

To use Gradle Tools version 2.7 with Intershop 7 version 7.4 to 7.5, perform the following steps to migrate your environment:

1. Gradle Tools 2.7 and later will be delivered exclusively via Intershop's public repository. Please set up your repository server according to Cookbook - Setup CI Infrastructure (valid to Gradle Tools 2.7).

2. Regenerate the corporate configuration and corporate distribution according to Cookbook - Setup CI Infrastructure (valid to Gradle Tools 2.7).

   1. In the Recipe: Create Sources From Intershop Templates it is sufficient to run the tasks createCorporateConfiguration and createCorporateDistribution.

   2. Build the corporate plugin configuration and the corporate distribution by triggering the automated CI processes.
3. For both, your assembly and component set, perform the following steps:
   
   • Change the Gradle distribution used by the Gradle Wrapper by modifying the property distributionUrl in gradle/wrapper/gradle-wrapper.properties.

   • In your gradle.properties files, change the following properties if existent:

     gradle.properties for updated Gradle Tools

     filter.com.intershop.build.set.cartridge-plugins=2.7.1
     filter.com.intershop.build.set.extension-plugins=2.7.1
     version.com.intershop.deployment-bootstrap=2.7.1

4. In settings.gradle deployment files raise the version of deployment-bootstrap to 'com.intershop:deployment-bootstrap:2.7.1'.

 New and Noteworthy

Updated Gradle Base Version

This release of Intershop Gradle Tools is based on Gradle 2.7. The previous release was based on Gradle 2.3. Please see Gradle's release notes for information about changes:

• Gradle 2.4 Release Notes
• Gradle 2.5 Release Notes
• Gradle 2.6 Release Notes
• Gradle 2.7 Release Notes

Dependency Management for Third-Party Libraries

Based on valuable customer feedback and our internal experience, dependency management for 3^rd party libraries has been simplified.

The first incubating implementation tried to stay compatible with the existing Intershop 7 application server's infrastructure, which implied certain functional drawbacks and major performance implications during build & assembly. The new approach relies only on standard Gradle dependency configurations, but requires some modifications within the application server.

Major advantages are:

• The build process does no special handling of 3^rd party libraries anymore. Therefore the new approach is easier to use for developers and offers better compatibility with the Gradle ecosystem.
• The interface between Intershop Gradle Build Tools and Intershop Studio provides improved performance for Component Set imports and other build model related activities.
• The assembly process should use transitive dependency resolving for cartridges, which enables the use of standard Gradle mechanisms for dependency inspection, such as dependencyInsight.

For more information please take a look at the Cookbook Recipe: Using Third-party Libraries in a Cartridge.

GUI Tests with Geb and Spock

Spock is a testing and specification framework. It provides a Groovy-based DSL for writing automated acceptance tests. Geb is a browser automation library. It enables browser automation with using the selenium Web driver technology and very expressive jQuery-like syntax. Together with Geb, you can implement acceptance tests at GUI level in your project.

As an incubating feature, the Gradle Tools support execution of GUI tests as as part of the assembly process on the CI server. A new SourceSet "remoteTest" is introduced for GUI tests as for further test types, that run against a started application server. The ish-assembly plugin provides tasks for executing remoteTests and for dealing with Selenium drivers at the CI environment.

Extended OverridePropertiesFilter

Previously you could only provide static properties to be added (or removed) from a file with the overrideProperties filter like this:

overrideProperties('myFilter') {
    [...]
    properties['to.be.changed'] = 'new value'
    properties['to.be.deleted'] = null
    // This does not work:
    properties['some.property'] = properties['existing.property.from.the.filtered.file']
}

As the filter is configured during Gradle's configuration phase, previously existing properties are not available.

Gradle Deployment Tools 2.7 introduces a new DSL for the overrideProperties filter to set properties dynamically:

overrideProperties('myFilter') {
    [...]
    // This will still work:
    properties['to.be.changed'] = 'new value'
    properties['to.be.deleted'] = null
    withProperties { Properties props ->
        // This will work now:
        props['some.property'] = props['existing.property.from.the.filtered.file']
    }
}

The given closure is not executed during the configuration phase, but during the file copy operation, so its content is available there.

Deprecations

Gradle Compatibility Declaration during Assembly

Starting with version 2.7 Gradle Deployment Tools know the Gradle base version they require. A distinct warning is emitted when trying to execute a deployment process with an incompatible Gradle distribution.

This mechanism replaces the requireGradle declaration during assembly, that is now deprecated and can just be left out.

Build Plugin ish-tloc-plugin

The build plugin ish-tloc-plugin has been deprecated, as tloc itself is deprecated as of Intershop 7 release 7.5. This plugin will be removed with the next major version of Intershop Gradle Tools.

Build Plugin ish-jaxb-plugin

This plugin will be replaced with the intershop-jaxb plugin. This plugin comes with a new configuration, different from the existing. It is still included and the assignment can be deactivated with a project property 'disableStandardJaxb'.

Potential Breaking Changes

Rework of Incubating Concept for Dependency Management of Third-Party Libraries

The previous incubating implementation in Gradle Tools 2.3 based on the separate configuration libs has been replaced and is not available anymore. Please see section New and Noteworthy for further information.

• The new concept only works with Intershop Commerce Suite 7.6.
• Customers using an Intershop version prior to 7.6, who
  
  • Do not use the incubating feature yet do not need to take action. When upgrading to Intershop 7.6 or newer, please follow the Guide - 7.6 Build Changes.
  • Already use the incubating feature should stay with Gradle Tools 2.3. When upgrading to Intershop 7.6 or newer, please proceed as follows:

  • • Existing libs dependency declarations are replaced with standard compile dependencies. A simple search & replace over the component set sources should be enough for all ordinary dependency declarations, e.g.:

      Dependency declaration migration for 3rd party libraries

      # inside the component set source directory
      find . -iname build.gradle | xargs sed -r "s|^(\s+)libs|\1compile|g" -i

    • For the assembly cartridges must be included transitively, see Cookbook - Gradle Assembly Tools (valid to 7.8). As libraries are then placed in the respecting environments' configurations, excludes should be defined for all configurations:

      build.gradle of Assembly

      // What was previously:
      // configurations.libs {
      // is now:
      configurations.all {
          exclude group:'com.example', module:'excluded-lib'
      }

Hotfix Import Workflow Replaced by the Intershop Public Repository

Hotfix import tool has been replaced by a continuous delivery process via Intershop Public Repository.

You can continue to use the hotfix import tool generated by previous versions of Gradle Tools if you need to consume hotfixes without using the Intershop Public Repository.

Updated Spock Framework to 1.0

All previous Gradle Tools releases used Spock 0.7 as test framework. Gradle Tools 2.7 updates this to the 1.0 release of Spock.

Spock extensions of Intershop's Gradle Tools have been recompiled for Spock 1.0. If you use those in your own test cases, you have to update to Spock 1.0, too.

Disallow Duplicate Archive Entries

The zip file format does not forbid adding a given entry to the zip file multiple times. Starting with Gradle Tools 2.7 packages created via ish-base-plugin (e.g., a cartridge's share zip) must be duplicate-free. Under normal circumstances there can be no duplicates, except where the build logic mistakenly defines the same srcDir of a package more than once.

Build Plugin ish-sonar-plugin Deactivated

In preparation for future changes, the ish-sonar-plugin is not applied per default anymore. If you use SonarQube for static code analysis, you must apply this plugin explicitly:

buildscript {
    dependencies {
        classpath group: 'com.intershop.build.gradle', name: 'ish-component-plugin'
    }
}

apply plugin: 'intershop-sonar'

New Plugins with Independent Lifecycle

Starting with this version some of the Intershop Plugins for Gradle have their own lifecycle and a separate version.

Examples with their latest version and the functionality:

This list of plugins will be extended. With the independent lifecycle it is possible to update this plugins between two major versions of the Intershop Gradle Tools.

Version History

Gradle Tools 2.7.1

The 2.7.1 hotfix release of Intershop's Gradle Tools includes the following changes:

• The method com.intershop.assembly.test.BaseAssemblySpec.noImagesFromDirectoryRunning(File) has been deprecated and its body has been replace with a no-op implementation. It was part of the AssemblySpec executed during a assembly build, and tried to verify that there is no application server still running from a previous execution on the given deployed server. This verification was not robust enough and caused more harm than good, which is why it has been disabled. No action is needed for migration.

• On Linux the deployment uses an invalid mode for certain files, which may lead to an exception like the following:

  org.gradle.internal.nativeintegration.filesystem.FileException: Could not set file mode 37777777777 on '/opt/intershop/eserver1/share/ivy.xml'.

  Those files will now be deployed with mode 444 instead. No action is needed for migration.

• Downloading the web driver for executing Geb tests in the assembly is now cached correctly, i.e., the archive will only be downloaded once and stored inside the GRADLE_USER_HOME directory. No action is needed for migration.