Perhaps the "override" rule is what you are looking for: http://ant.apache.org/ivy/history/latest-milestone/ivyfile/override.html
Regards, Marc 2014-07-10 18:24 GMT+02:00 Greene, Hugh <hgre...@tmvse.com>: > Hi all, > > I'm looking for a way to enforce a particular kind of check on versions in > a transitive dependency graph. I have an idea for how to do it, but I'd > like to hear opinions on whether there's a better way, whether it's the > wrong thing to be doing in the first place, etc. > > === Context > > We have multiple teams building, publishing and using multiple in-house > and third-party dependencies, mostly non-Java. > > These teams are using two (soon three) different custom tools built on top > of Ivy; one based on Gradle (1.4), one completely custom. Among many other > things, these tools download dependencies as ZIP files (which might > contain, say, header files), then unzip them to a cache, and put a symlink > to there from the workspace of the module being built. > > > === Requirement > > Some of these have runtime binary-compatibility issues, meaning that all > dependencies for those modules must be using the same version. However, > not all builds want to use all (or any) of these libraries. And some of > the problem libraries are very large, so teams don't want to have to pull > down the files for those libraries, to save time and space. Ideally they > don't want to have to symlinks to them in their workspace at all, for > clarity. > > So, we want a way to be able to express the constraint that *if* some > module M has problem module P in its dependency graph (possibly multiple > times), it must have a specific version P:1.5; but it doesn't have to have > a dependency on P. > > We don't want to always take the latest version, and we don't want to > force conflicts to resolve to a specific version. Some of the problem > modules are C-style static libraries, already compiled in to the modules > which use them, so anything other than strict conflict resolution would > only be misleading. (Suppose I'm building module M, which depends on > module A:2.0, which itself depends on P:1.1. I want M to have this > "optional dependency" on P:1.5. If I "use latest" and the dependency is > resolved to P:1.5, that doesn't change the fact that A:2.0 has code from > P:1.1 compiled into it.) > > And, we want to solve this problem using only features of Ivy which are > supported by Gradle 1.4. > > > === Proposed solution > > For each problem module P, give it a configuration called, say, "marker", > which has no artifacts. > > Configurations of M (all of them?) declare a dependency on only the > "marker" configuration of P. > > Strict conflict resolution is used. > > The tools are modified (if required) so that, if there are no artifacts at > all for a resolved module's configurations, they won't create a symlink for > that module in the workspace. > > > > So, how does that sound? > > Hugh Greene, Senior Software Developer > Toshiba Medical Visualization Systems Europe, Ltd > Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK > Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799 > http://www.tmvse.com / mailto:hgre...@tmvse.com > > DISCLAIMER > Unless indicated otherwise, the information contained in this message is > privileged and confidential, and is intended only for the use of the > addressee(s) named above and others who have been specifically authorized > to receive it. If you are not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this message > and/or attachments is strictly prohibited. The company accepts no liability > for any damage caused by any virus transmitted by this email. Furthermore, > the company does not warrant a proper and complete transmission of this > information, nor does it accept liability for any delays. If you have > received this message in error, please contact the sender and delete the > message. > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________
