开发者

Does Ivy have different resolution behavior depending on status attribute?

开发者 https://www.devze.com 2023-03-23 16:47 出处:网络
My colleague pointed out a flaw in maintaining our artifacts (still somewhat new to Ivy): The release builds are marked as “integration” which means it is rechecking for new versions on each buil

My colleague pointed out a flaw in maintaining our artifacts (still somewhat new to Ivy):

The release builds are marked as “integration” which means it is rechecking for new versions on each build slowing down the build even when it has cached the dependencies.

That did not make much sense to me, since, I think, Ivy still needs to check 开发者_运维技巧what is in repo before making a decision about the version to deliver. So, I decided to research that a bit to understand exactly what are the effects of marking libraries with different status values. I cannot find much in the documentation, though, or on the net. What am I missing? Could someone please shed some light on this?

Thank you


The status is just a string, that can be defined for ivy. They don't affect the resolving of artifacts per se. It has no effect on the default retrieval. It's just a marker for an artifact.

Status:

Status of a revision A module's status indicates how stable a module revision can be considered. It can be used to consolidate the status of all the dependencies of a module, to prevent the use of an integration revision of a dependency in the release of your module.

Three statuses are defined by default in Ivy:

integration: revisions builded by a continuous build, a nightly

build, and so on, fall in this category milestone: revisions delivered to the public but not actually finished fall in this category release: a revision fully tested and labelled fall in this category

You need to declare the dependency as changing or the resolver definition to achieve what your co-worker mentioned:

Changes in artifacts Some people, especially those coming from maven 2 land, like to use one special revision to handle often updated modules. In maven 2 this is called a SNAPSHOT version, and some argue that it helps save disk space to keep only one version for the high number of intermediary builds you can make whilst developing.

Ivy supports this kind of approach with the notion of "changing revision". A changing revision is just that: a revision for which Ivy should consider that the artifacts may change over time. To handle this, you can either specify a dependency as changing on the dependency tag, or use the changingPattern and changingMatcher attributes on your resolvers to indicate which revision or group of revisions should be considered as changing.

Once Ivy knows that a revision is changing, it will follow this principle to avoid checking your repository too often: if the module metadata has not changed, it will considered the whole module (including artifacts) as not changed. Even if the module descriptor file has changed, it will check the publication data of the module to see if this is a new publication of the same revision or not. Then if the publication date has changed, it will check the artifacts' last modified timestamps, and download them accordingly.

So if you want to use changing revisions, use the publish task to publish your modules, it will take care of updating the publication date, and everything will work fine. And remember to set checkModified=true" on your resolver too!

0

精彩评论

暂无评论...
验证码 换一张
取 消