Hi, In our build system implementation based on Ivy, we are finding different use cases that seem to require changes to an already published ivy.xml.
The only thing close to support for that feature that we found in the documentation was the attribute changing=true in the dependency node. It says: "if the dependency artifacts may change without revision change, false otherwise (since 1.2). Artifacts update will be looked after only if the publication date of the ivy file has changed. Note that this is not a recommended use and that it avoid some cache optimization in ivy. No, defaults to false" I am not sure if it would apply to changes in the published ivy.xml file itself, though. The general use case is how to add more information or metadata without changing the version. Here are the two use cases we are dealing with: 1) Circular Dependencies The more serious problem we face is how to deal with circular dependencies. We have been able to change our projects so that we don't have those at compile time; but when we consider the entire dependency graph, including runtime dependencies as well (through the use of Inspection, class.forName, etc) we get some circular dependencies. Them the problem becomes, what happens with the resolved versions? Say we have A -> B (conf=compile, rev=latest.integration) B -> A (conf=runtime, rev=latest.integration) Say both modules are currently on version 1.0 and both will produce version 2.0. If I resolve for the "compile" configuration, build and publish, I will end up with B depending on A v1.0! The desired solution is to have both A and B using the real latest version, 2.0. The only way out seems to be running a full build (including publish) based on the "compile" configuration, and then to resolve and publish again, but wihtout changing versions, for "runtime". This would fix the version used by B since now the A 2.0 version would be available in the repo. 2) Build Promotion We would like to be able to change the "status" of a version after it was published. Actually in the most general case, we would like to be able to associate different status values for the same version, for different products might use the same jar, and it might have been validated for one product but still not approved by the testing team of another. Assuming that we can fix the version resolution to include extra attribute checking (http://ant.apache.org/ivy/history/trunk/concept.html#extra), we would still have the problem of how to add those extra attributes to the published ivy.xml files. Any ideas? Other then using multiple repositories to re-publish the versions with the new information (either fixing versions for circular dependencies or adding attributes for build promotion), what could we do? Thanks, Nascif
