I'm having problems understanding how I to use dynamic revisions of Ivy effectively in my Java projects.
Currently, I have the following layout:
lib-a
revision: 1.0.0
status: release
dependencies: none
lib-b
revision: 2.0.0
status: release
dependencies: lib-a, rev 1.0.0
project-a
revision: 3.0.0
status: release
dependencies: lib-b, rev 2.0.0
project-b
revision: 4.0.0
status: release
dependencies: lib-b, rev 2.0.0
That means I always keep the status to release and use explicit version numbers.
If I would change lib-a during development, say lib-a, this is quite painful.
I save the changes in lib-a, update the revision in the ivy file to 1.0.1 for a minor change. Then i need to update the dependencies of lib-b to announce the revision 1.0.1 of lib-a. Now I could either update the revision of lib-b and also project-a because project-a is the executable and contains integration tests which I need to run.
The second way is to re-publish lib-b with updated dependencies but same version. This usually works with ant on command line but not for NetBeans with ivy-beans plugin. They still use a cached version of the ivy file of lib-b. So I need to clean to local cache to make it work.
I use a common build-ivy.xml ant script that is in our SVN repository for all projects. Each project has a build.xml in the project's root that most of the time simply includes the build-ivy.xml. Sometimes necessary tasks are added or overwritten.
I've just read here and here that the solution might be using dynamic revisions.
As far as I understand it, I would set the revision in all ivy files to integration-latest and set the status in all ivy files to integration. Then, ivy would always resolve the latest version automatically.
But what would I set the revision of my modules to? Omit it completely?
How would I create a release version? Do I need to change all ivy files and set the status to release or would I perform a deliver task before publishing a module with overwriting the status to release if possible?
