Not always. If you publish a module with an unresolved configuration, and you have dynamic dependencies on that configuration, they will be left unresolved (i.e. "rev='latest.integration'") in the repository.
And why would you ever publish without resolving? We just found an use case: circular dependencies combined with dynamic revisions. We use both "compile" and "runtime" configurations, and we found out that some modules introduced circular dependencies using the second one. If we resolved both, we would end up with the wrong resolved versions, by virtue of dynamic versions and build ordering - since you can't build the entire cycle in the same pass, the first one would get an incorrect (old) version. So we are going to resolve only for compile, then build and publish. Only in a second pass we will resolve for runtime (when we actually need it, for example to create installers or testware to test the software). Now let me get my pain medicine... :-) /Nascif -----Original Message----- From: Jing Xue [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 10:42 AM To: [email protected] Subject: Re: Sharing ivyconf.xml Quoting Niklas Matthies <[EMAIL PROTECTED]>: > I agree (in theory ;)). But that's not really my point. My point is > that you can't (practically, reliably) have Ivy dependencies from > module revisions onto shared Ivy settings. > Because the purpose, or > at least one major purpose, of the Ivy settings is to define the > resolution process across available revisions (in particular in the > light of dynamic dependencies and non-strict conflict resolution). If I understand it correctly, isn't this resolution process only involved when the module is having its dependencies resolved for the first time, prior to publish? Once it's published, the dependencies are fixed in the published version of ivy.xml, which is anchored by a versioned repository. So when this module A participates in the resolution process of another module B, the original ivy settings under which A was resolved shouldn't matter at all. ...right? (argh this thing makes my head hurt. :-) ) Cheers. -- Jing Xue
