I think your on the right track here. Resolving for installation and deployment is a separate exercise.
On Dec 11, 2007 1:00 AM, Nascif Abousalh-Neto <[EMAIL PROTECTED]> wrote: > 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 > > > -- Regards, John Gill
