On 2/1/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
Actually, it is not only in case of deleted revision that it might be useful to have a range of accepted values. I might be wrong, but currently when you develop a library and you publish it, you can not specify the range of version that you support. I mean, you can do it in your source ivy.xml, but not in the ivy.xml you publish.
No, you can publish exactly what you want. That's why there is a distinction between deliver and publish, which is often not well understood. deliver is responsible for replacing dynamic version contraints by static ones in your ivy file, publish actually publish exactly what you give, with no processing. So you can provide your source ivy file to publish, without deliver (but you will have issues with the revision). You can also disable dynamic revision replacement during deliver. Or you can use deliver and post process the generated ivy file the way you want before doing publish. Everything is possible, not necessarily easy, but possible :-) For example, let say that ivy is a reusable module (just imagine ;-). Ivy
has a dependency with ant. Ivy support [at least] 1.6 and 1.7. You can say that in the ivy source, but once it is published, it will be published with the 1.7 dependency only (or 1.6, I don't know). You have loosed some useful information for your user. And they are now forced to use 1.7. Even if some users might prefer to have only fixed version dependencies, some will prefer to offer more flexibility to their users and will prefer to publish version ranges. Is my understanding correct (I didn't tried a lot to play with version range) Note that there is certainly a lot of issue to consider: - Build reproducibility?
This is my major concern about publishing ivy files with dynamic version constraints. But you can ensure build reproducibilty if you're sure that what is returned by your range won't ever change in the future. Maybe using a list of supported versions instead of a version range would be more appropriate. But the answer is not trivial anyway. - New attributes in the ivy.xml? I don't think this is necessary - New parameters for the resolve and for the publish task? If we want to support some out of the box support of this kind of thing, yes, but the problem is very complex. - What happen if a module publish ranges but its user prefer to have a fixed
version?
Good question! - How can a module provider be sure that he really supports all those
versions? (See https://issues.apache.org/jira/browse/IVY-386)
Good question too. Note that another thing which should be improved is a real notion of supported versions. For the moment even if you declare a dependency with a static version you're not sure you will actually get it, because of conflict management. We can do things to warn or raise error about this, but there is no current support for that. This is something we need to work on if we want better maven 2 compatibility (version ranges in maven 2 raise an error if you assk for two incompatible version ranges for example). - Xavier Gilles
