The Common Build

Pentaho projects are standardizing on a common set of Ant targets called the common build.  These Ant targets are maintained in common_build.xml which a project will include in its source.  This document is intended to aid developers in understanding and resolving typical errors encountered with projects based on the common build.

Debugging Dev and Build problems in the common environment

overriding a previous definition of ivy:settings with the id 'ivy.instance' is not allowed when using override='notallowed'

Ivy does not allow the execution of ivy:settings Ant task more than once during a build.  You will encounter this error when:

• you are running a sequence of Ant targets, e.g. $ant clean dist test publish
• AND there is an error in the logic of common_build.xml such that it does not properly detect that a prior target has already installed-ivy

Here is a snippet of the install-ivy task, the ivy:settings target should not be executed more than once during an Ant runtime.

<target name="install-ivy"
          depends="install-antcontrib,download-ivy"
          description="Installs IVY tasks for use by this build process">
...
        <ivy:settings url="${ivy.settingsurl}" />
...
  </target>

Conflicting versions of wizbang.jar are appearing in my ivy.xml[*] library in Eclipse. My ivy.xml says I only want wizbang-1.2, but my ivyDE is pulling in wizbang-1.1 also! Where is wizbang-1.1 coming from and how do i fix this?

In this scenario wizbang-1.1.jar is being pulled into your library as a result of a transitive dependency. To illustrate, let's say you have declared these dependencies in your project's ivy.xml file:

<dependency org="acme" name="wizbang" rev="1.2" />
<dependency org="acme" name="elmo" rev="3.0" />

You obviously expect to see wisbang-1.2.jar in your Eclipse ivyDE library, but it is possible with just these two dependencies, that you would also see wizbang-1.1.jar. How? Because of transitive dependencies. A transitive dependency are essentially jars that are required by your direct dependencies. In our example let's assume that you cannot use the elmo jar in a running environment unless you have wizbang-1.1. The makers of elmo would have declared this dependency in the elmo dependency file (a POM (Maven) or ivy.xml (IVY)). By including elmo in your project, IVY will realize that it needs to go grab wizbang-1.1; note that IVY does not know that you already have wizbang-1.2 as a direct dependency of your project.

Runtime dependencies are where you are most likely to encounter problems with transitive dependencies. If your project depends on a particular artifact in order to compile, you will declare this dependency explicitly in your project's ivy.xml file, thus its origin will not be a surprise to you.

So at this point we know how wizbang-1.1.jar got there, but what do we do about it. Obviously we don't want wizbang-1.1 to show up at all since we already have wizbang-1.2. IVY allows you to override the dependency declaration of the artifacts your project needs. In other words IVY provides a way to tell elmo that we do not want it's version of wizbang. In IVY you accomplish this with an exclusion element. A modified snippet of the ivy.xml that excludes the wizbang that orignates from elmo is here:

<dependency org="acme" name="wizbang" rev="1.2" />
<dependency org="acme" name="elmo" rev="3.0" >
    <exclude org="acme" name="wizbang" />
</dependency>