Automate ivy revision increase for all my projects using ant script

1
votes

i own 20 ivy projects out of 50 other projects(owned by others), i use some versions of their binaries in my projects.

Issue is during release, i have to manually increase the version of my 20 ivy files, checkin the files and build the binaries. which is time consuming. though eclipse find and replace helps.

steps to automate using ant:

1) checkout the ivy files alone. 2) using scripts/logic to change the version for only my modules/my modules dependency with one another. 3) check in the files. 4) tag the branch for release.

Stuck at step 2 rest all are relatively easy.

Tried xml task, but facing challenges on searching as we dont know the exact index some times.

Appreciate your help.

3
javaantivy
It is not clear to me if you're asking about your own revision number, or the one of the dependencies you're referring to. Keep in mind that you can always use ant properties inside an ivy descriptor, so you could use this to specify your own revision. – Joeri Hendrickx
thanks Joeri. i am referring to version of the dependency file. <ivy-module version="2.0"> <info organisation="com.selva" module="my-module" revision="home123" status="release"/> <dependency org="com.selva" name="my-module1" revision="module123" /> </ivy-module> – Selvakumar Esra

3 Answers

3
votes

Have you considered using the dynamic revision numbers in your ivy files?

<dependency org="myorg" name="myname1" revision="latest.release"/>
<dependency org="myorg" name="myname2" revision="latest.integration"/>

Ivy will cleverly resolve these dependencies in the ivy.xml file that is published to ivy repositories.

Use ivy to generate buildnumber

The buildnumber is a very clever task that generates the next number in a sequence, based on the versions you've already been published.

Controlling the build order

Another ivy multi-module tip is to use buildlist task to control the order in which your modules are built. It works based on the inter-dependencies declared in the ivy files of each sub-module. This ensures that the latest.release and latest.integration revisions will find the expected revision.

Resolving the dynamic revisions

As I've said this is normally done automatically, but sometimes you'll need to actually see the real versions used, for example when generating a Maven POM file (when publishing to a Maven repo).

The following examples use the ivy deliver and makepom tasks to create a Maven POM with the dynamic revisions expanded. 

<target name="generate-pom">
    <ivy:deliver deliverpattern="${build.dir}/ivy.xml" pubrevision="${publish.revision}" status="${publish.status}"/>
    <ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/${ivy.module}.pom"/>
</target>

<target name="publish" depends="build,generate-pom">
    <ivy:publish resolver="${publish.resolver}" pubrevision="${publish.revision}" overwrite="true" publishivy="false" >
        <artifacts pattern="${build.dir}/[artifact](-[classifier]).[ext]"/>
    </ivy:publish>
</target>
1
votes

If you always want to use the latest release, have you thought about using version ranges in dependencies? There will be no more need to edit the files for a new release. It would look like the following for spring core:

<dependency org="org.springframework" name="spring-core" rev="[2.5,4.0[" conf="optional->default"/>
0
votes

Found the following workable solution myself, though tried other options like parsing the ivy.xml through IVY java etc.

<target name="autoincrementivy" depends="prompt-user.password">
    <exec executable="svn" failonerror="${svn.failonerror}">
        <arg value="--non-interactive"/>
        <arg value="--trust-server-cert"/>
        <arg value="--username"/>
        <arg value="${svn.user}"/>
        <arg value="--password"/>
        <arg value="${svn.password}"/>
        <arg value="checkout"/>
        <arg value="--depth"/>
        **<arg value="immediates"/>**
        <arg value="${svn.repository}/@{module.name}/trunk"/>
         <arg value="${temp.checkout.dir}/@{module.name}"/>
    </exec>
<move file="${temp.checkout.dir}/ivy.xml" tofile="${temp.checkout.dir}/ivy_src.xml"/>
<ant target="changeVersion" antfile="../deploy.xml" >
   <property name="dest.file" value="${temp.checkout.dir}/ivy.xml"/>
  <property name="src.file" value="${temp.checkout.dir}/ivy_src.xml"/>
  <property name="target.version" value="${tag.version}"/>
</ant>
<!-- cehckin the file-->
</target>

Above task to checkout the file to a temporary folder with .svn folder so that cehckin will work correctly.

    <target name="changeVersion">

    <xmltask source="${src.file}" dest="${dest.file}" preserveType="true" >
        <replace path="/ivy-module/info/@revision" withText="${target.version}" />
        <replace path="/ivy-module/dependencies/dependency[@name='my-common']/@rev"       withText="${target.version}" /> 
<replace path="/ivy-module/dependencies/dependency[@name='my-gui-common']/@rev" withText="${target.version}" /> 
        </xmltask>  
        <fixcrlf file="${src.file}" eol="cr" />
    </target>

The above target to parse and change the version.