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.
Have you considered using the dynamic revision numbers in your ivy files?
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.
Found the following workable solution myself, though tried other options like parsing the ivy.xml through IVY java etc.
Above task to checkout the file to a temporary folder with .svn folder so that cehckin will work correctly.
The above target to parse and change the version.
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: