A good practice is to have the fact that a version can change, even if rarely, be reflected in the version number itself. So you might have a -SNAPSHOT or -dev suffix or a -_timestamp_ suffix.
Beyond that, it's a good idea to publish the module with a status that indicates that it is an integration version. The out-of-the-box status for this is "integration". See the documentation for ivy:deliver and ivy:publish to see about setting the status. Once you've done this, if you have all your potentially changing, i.e. integration, versions going into a particular Ivy repository/directory, then you can tell the Ivy resolver pointing at that repo to never trust the cache. Do something like: changingPattern="*" changingMatcher="glob" Or the regular expression equivalent... If you don't have a separate repository or directory for integration versions, then you need to make use of the suffix in the version itself to indicate it could change. And then specify changingPattern accordingly. But even if you do have a separate repo for integration versions, it's just good practice to incorporate the changeability of the module into the version. When you see a revision like 3.0.1, it's a good indication that this is a release version. On Mon, Jul 30, 2012 at 8:26 AM, Chris Rimmer <chr...@we7.com> wrote: > I am in the process of splitting up a large codebase and hoping to start > using ivy to manage dependencies. As a first step, I have split it into two > pieces, A and B. There is some shared code used by both A and B. This is > held in a jar file which is an artifact of A and used by B. I don't > anticipate this shared code changing very often, so I am quite happy to > manage the versions manually. So the version number of module A is just > held in a properties file checked into source control. The initial version > (0.1) is published in a shared repository (the shared jar is the only > artifact) and B has a dependency on v0.1. > > What I would like to do would for our continuous integration process to > detect if the shared code has been changed, but the version number has not > been incremented. So someone has probably forgotten to publish a new > version of A having changed the shared code. While it is possible to find > the latest version of a module using the <ivy:findrevision> ant task, it > does not seem to be easy to compare what is built from version control with > what it is in the shared repository. > > My question is, am I approaching this the wrong way and if so, what should > I be doing to handle this differently? > > Thanks > > Chris >
