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

 Migrate Tools Version

To use Gradle Tools version 2.3 with Intershop 7 version 7.4.6.1 to 7.5.1, perform the following steps to migrate your environment:

1. Import the delivery containing the Gradle Tools 2.3 into your repository, see the previous version's recipe "Import Intershop Delivery" in Cookbook - Setup CI Infrastructure (valid to version 2.1).
2. Adapt your repository server configuration according to the recipe "Configure Artifact Repository Server" in Cookbook - Setup CI Infrastructure:
   
   • If you don't use the public repository, you can skip creation and assignment of the ishRepo proxy repository.
   • In any case you have to create the components repository group.
3. Regenerate corporate plugin configuration and corporate distribution by following the recipe "Create Sources From Intershop Templates" in Cookbook - Setup CI Infrastructure. Run the tasks createCorporateConfiguration and createCorporateDistribution.
4. Build the corporate plugin configuration and the corporate distribution by triggering the automated CI processes.
5. 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.3.+
     filter.com.intershop.build.set.extension-plugins=2.3.+
     version.com.intershop.deployment-bootstrap=2.3.+

6. In settings.gradle deployment files raise the version of deployment-bootstrap to 'com.intershop:deployment-bootstrap:2.3.+'.

 New and Noteworthy

Updated Gradle Version to 2.3

Intershop Gradle Tools 2.3 are based on Gradle 2.3. The previous version 2.1 was based on Gradle 2.1.

See Gradle's own release notes for changes:

• Gradle Release Notes Version 2.2
• Gradle Release Notes Version 2.3

Dependency Management for Third-Party Libraries

We introduced a new way for cartridges of dealing with dependencies to third-party libraries using Gradle-based dependency management. This approach can be used with all Intershop 7 CI releases, given that you are using Gradle Tools 2.3 or later.

See Cookbook - Gradle Build Tools (Using Third-party Libraries in a Cartridge) for further documentation on how to use this feature.

Running Integration Tests during Assembly Build

Gradle Tools 2.3 introduces the functionality to run integration tests during the assembly build, see Concept - Gradle Assembly Tools for details.

Fixed Issues

It Is Not Possible to Integrate JaCoCo and JUnit Results in SonarQube

Problem

It was not possible to integrate JaCoCo in the SonarQube Analysis. It was also not possible to send the JUnit result files to SonarQube during the analysis.

Workaround

There was no workaround.

Solution

JUnit and JaCoCo result files are included in the SonarQube analysis, if this kind of files are available.

Database Dump Is Also Deployed for Host Types webserver and solr

Problem

The database dump is deployed for those host types, that include the local directory. This is not useful for the webserver or solr hosts.

Workaround

Add the following snippet to your assembly deployment logic:

deployment {
    files {
        databaseDump {
            if (!(deploymentBootstrap?.hostType?.hostType?.name in ['appserver', 'all']))
                exclude { true }
        }
    }
}

Solution

Starting with Gradle Tools 2.3, the dump file will only be deployed for host types appserver and all by default.

When using custom host types, you can explicitly configure deployment of the dump file in the deployment DSL:

database {
    deployDump = true
}

Service Creation Issues on Windows

Problem

When executing the post-install script installServices.bat with administrator privileges, the following errors occur:

Could not create service Enfinity_AppServer1, check C:\eserver1\local\bin\isservice.exe Enfinity_AppServer1 \""C:\eserver1\local\bin\nodemanager.bat -win32service -background\install.log

[...]

Could not create service Enfinity_ApacheWebServer1, check C:\eserver1\local\httpd\bin\httpd.exe -k runservice -n Enfinity_ApacheWebServer1 -f C:\eserver1\local\httpd\conf\install.log

Workaround

Create the services manually with the following commands:

1. sc create Enfinity_AppServer1 binPath= "C:\eserver1\local\bin\isservice.exe Enfinity_AppServer1 \"C:\eserver1\local\bin\nodemanager.bat -win32service -background\"" displayname= "INTERSHOP Application Server (1)" obj= ".\username" password= "password" start= demand
2. sc create Enfinity_ApacheWebServer1 binPath= "C:\eserver1\local\httpd\bin\httpd.exe -k runservice -n Enfinity_ApacheWebServer1 -f C:\eserver1\local\httpd\conf\httpd.conf" displayname= "INTERSHOP HTTP Server (1)" obj= ".\username" password= "password" start= auto

Replace the highlighted parts accordingly.

Solution

The problems are fixed in Gradle Tools 2.3.

Host Type all Does Not Inherit includeJavadoc Flag

Problem

When deploying the host type all with environment development, Javadoc is not deployed.

Workaround

Set the flag to include Javadoc manually in the deployment DSL:

developer {
    includeJavadoc = true
    javadocDirectory = new File('[...]')
}

Solution

The host type all will inherit the includeJavadoc flag, so that per default Javadoc is deployed when:

• Any other host type defines includeJavadoc as true, and

• The environment is set to development.

Known Issues

Dependency Management for Third-Party Libraries

A patch release Gradle Tools 2.3.1 is available, that fixes the following issues:

• Libraries defined as libs dependency are not part of testRuntime, i.e. the classes are not available while executing unit tests during the cartridge's build process. This may lead to test failures like

  java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

• The newly introduced assembly task checkLibsCollisions may fail with ConcurrentModificationException if the defined libraries are not already present in the local Gradle cache.

Class Collision Check for Third-Party Library Dependency Management

Problem

The newly introduced assembly task checkLibsCollisions inspects dependency metadata to find the jar files to analyse. This is problematic when excluding certain jar files from the tools cartridge, because this exclusion can only happen during deployment, which does not influence the current collision check.

Workaround

There are two ways to avoid assembly build failure because of a false positive:

• Avoid executing this task altogether by either not invoking it explicitly or excluding execution of this task with -x checkLibsCollisions. You should still execute this task periodically to spot conflicts not intended.

• Tell the task to ignore certain conflicting classes via regex:

  Assembly build.gradle Snippet

  [...]
  checkLibsCollisions {
      excludes << /^some.*Regex.*/
  }