Le 29 févr. 08 à 22:12, Juha Ranta a écrit :
Hi Nicolas,
On 29.2.2008, at 22:40, Nicolas Lalevée wrote:
I have no answer but a question :)
It seems strange to me of having a dynamic revision that does not
change between two builds. What is the rationale behind it ?
Nicolas
Each project in CVS has its own ivy.xml in the root directory. As an
example, let's consider that the mainline development of a projects
takes place in the trunk of CVS and the ivy.xml in this projects
says "latest.integration" as the revision for some of the
dependencies. When the build server checks out the project from CVS,
it also gets the ivy.xml with the "latest.integration"
dependencies". However, when Ivy resolves the "latest.integration"
dependencies, those resolved dependencies get an actual revision.
For example, the build may resolve and retrieve revision 13 of
dom4.jar and use that during the build. When the next build is
triggered, it may be that there's revision 14 of dom4j.jar in the
repository, so this new build will retrieve revision 14 of
dom4j.jar. The "dynamic" ivy.xml of the project in CVS has not
changed at all, but the generated "static" ivy.xml has different
revisions in the dom4j.jar dependency.
During my builds from the build server, my script actually checks in
the generated "static" ivy.xml to CVS, tags it with the build tag,
and then checks in the original "dynamic" ivy.xml. This way the
builds are reproducible and this is the foundation from which I
create release or bug fix branches, for instance. I know it's not
necessary to make this kind of "snapshots" of every single
continuous integration build like I'm doing, but making this kind of
"snapshots" at milestones is very important if you, for instance,
possible need to make make bug fixes on earlier versions of your
project while you're already developing new stuff.
ah OK, I was thinking that the dynamic revision you talk about was a
project one. So your issue is in fact with your repository.
First, maybe it is a bad idea to have lastest.integration on a
repository, see Stephane's mail in the "ivy integration with automated
build tools" thread in this mailing list.
If you really want to deal with it, maybe you can try to work with the
cache which holds that last dependency report. First you save the old
report, then you trigger an ivy:resolve which will generate another
report, and finally we could compare the both report to see if
something changed. And it might be interesting to have a such feature
in Ivy if you are willing to contribute :)
Nicolas
