Hi. I have added IVY-433 issue.
I described there the reason why dynamic versions don't always become static during "deliver" task where there are extra attributes. See https://issues.apache.org/jira/browse/IVY-433 In short, the problem is that the resolved module in the cache contains all the extra attributes while the mechanism to convert dynamic to static revisions in XmlModuleDescriptorUpdater file use only org, module, revision and branch attributes (line 193). The result is that actual resolved revision stored in "resolvedRevisions" variables doesn't being "get" by the HashMap and the static revision remains. In the issue I describe 2 possible solutions. On 3/12/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
Hi, Here is the picture: In previous Ivy versions (before 1.4 if I remember well), dynamic revisions replacement was done at resolve time, the deliver step was just updating general metadata (module revision and status) from a file in cache with dynamic revisions replaced. But with the introduction of the flag to disable dynamic revision replacement. We had to store the information of which dynamic revision was resolved to which static one separately, ie. for each dependency what is the static revision to use. That's the pupose of this property file. The bug comes from bad keys in this file, or at least bad matching of the keys against the dependencies we find in the ivy file. HTH, - Xavier On 3/12/07, easyproglife <[EMAIL PROTECTED]> wrote: > > Hi. > > I have noticed the discussion about the problem in converting dynamic > revisions to static during deliver/publish. > > I have applied IVY-404 patch locally but still getting dynamic revisions > in > "delivered" ivy.xml. > > > Can you help me understanding the dynamic to static revision mechanism? > > Can you please describe briefly how does it work and what is the role of > those properties files in the cache root? > > > I can track the source code myself but I lack the "big picture" > understanding of how the dynamic to static revision mechanism works and > what > can makes it go wrong. > > Thanks. >
