Minor Description
Scenario: Ivy resolution using a dual resolver with haltonfailure set to true.
In this situation if Ivy cannot locate the ivy.xml file it does not halt, but continues on with a search of the artifact repository to see if the artifact exists. This is to allow a situation where no ivy.xml is available and to reduce the number of ivy.xml files which need to be written.
This behavior is useful in some cases. However, in a formal build environment using strict CM methodology it is undesirable and potentially dangerous.
Request is to enhance the ivy resolver to allow for "strict" resolution. Strict meaning that any failure during the resolve results in a build error.
On a personal basis I would prefer that Ivy behavior be modified so that haltonfailure does just that - issues a build exception on any resolution problem. If one wanted the default behavior, then one would add an attribute modifying that behavior - for instance: an allowNoIvyFile attribute. I like this better than a "strict" attribute because the semantics are cleaner and it conforms to user expectations - that any failure in the resolve will result in a build error if haltonfailure is set to true.
It is unclear to me whether the allowNoIvyFile attribute should be placed on the resolve task or on the resolver configuration. Personally, I lean to making it an attribute of the resolver conf. In so doing I am effectively saying that for this repository I do not always expect that an artifact will have an ivy.xml