On Nov 16, 2007 11:37 PM, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote:
> 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 changing attribute (which can also be set more globally by using changingPattern on your resolvers) is used when the artifacts themselves are modified for a given version. This is mostly used for maven SNAPSHOT versions, or similar build systems where some intermediary releases don't get a unique version. I'm not in favor of this approach generally, but Ivy supports this. What you have is only changing metadata, which is supported differently by Ivy: all you need to do is set checkModified="true" on your resolver(s). This means that Ivy will check the repository for modified information in the ivy.xml files each time you run a resolve, so this willl slow down your resolution process. But it should work as you want. > > 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. Indeed, dealing with circular dependencies is not easy, and your trick should do the right job. What I dislike with that is that between the two steps you have an inconsistent repository state. Maybe the first publication should be done to a local repository used only for that, and the second one to the real repository. Then you wouldn't even need to use checkModified="true" on your production settings. > > 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. Indeed, this is the best use case I see for using checkModified, and it should work well for you. Xavier > > > 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 > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
