views:

40

answers:

1

Hello.

At our company, we use a base ant file that is included by everyone to do their builds. It contains the things we want to define globally and uniform, like build-test, test-coverage, build-release, publish on ivy, etc.

I would like to enforce that in the ivy resolve that is done for creating a release build, libraries that have test (integration) status are rejected. Basically, that for a release build, you can only use release-class libraries.

However, I cannot find a way to enforce this in the ivy resolve ant task (not in the ivy.xml file).

Does anybody have an idea on how to accomplish this?

A: 

Option 1

Strictly speaking you have two sets of resolved libraries, so this could be solved by having two ivy files. One listing dependencies on the latest integration revisions the other the latest release versions.

The build.xml file would then have two resolution targets, controlled by a release property

<target name="resolve-int" unless="release.build">
    <ivy:resolve file="ivy-int.xml"/>
</target>

<target name="resolve-rel" if="release.build">
    <ivy:resolve file="ivy-rel.xml"/>
</target>

<target name="resolve" depends="resolve-int,resolve-rel"/>

Option 2

Use a property to determine the desired dynamic revision:

ivy.xml

<ivy-module version="2.0">
    <info organisation="com.myspotontheweb" module="demo"/>
    <dependencies>
        <dependency org="commons-lang" name="commons-lang" rev="${dynamic.revision}"/>
    </dependencies>
</ivy-module>

build.xml

The property dynamic.revision has a default value of latest.integration

<project xmlns:ivy="antlib:org.apache.ivy.ant" name="demo-ivy" default="resolve">

    <property name="dynamic.revision" value="latest.integration"/>

    <target name="resolve">
        <ivy:resolve/>
    </target>

    ..    

</project>

A release build would then override this value, possibly from the command-line as follows:

ant -Ddynamic.revision=latest.release
Mark O'Connor
That would work indeed; but both cases put a restriction on the format of the ivy file. The issue I'm facing is that I'm not writing the ivy files (so I can't make sure there are two, or that they're referencing a property). The whole idea is to be able to set the rules, and if the supplied ivy file does not comply, trigger an error. But the ivy file is supplied by someone else.
Joeri Hendrickx
In that case use option 2 coupled with a script that first validates ivy.xml against a set of business rules that you want to enforce.
Mark O'Connor
IVy is not designed to validate it's own content. It does appear to me that what you really need is to agree some rules with the ivy author and then enforce them via XML validation. One such validation engine I've used to enforce XML content is http://www.schematron.com/
Mark O'Connor
Ok, I'll try that. That was basically the question, whether ivy could do that by itself.
Joeri Hendrickx