Hi Hugh, I see. In that case, your solution with the marker configuration seems like a nice solution for your problem. I don't see directly another way to achieve what you want.
Regards, Marc 2014-07-11 10:52 GMT+02:00 Greene, Hugh <hgre...@tmvse.com>: > Hi Marc, > > thanks for the reply, but overriding is definitely not what I want: > > > ... we don't want to > > force conflicts to resolve to a specific version ... > > If > > - M says that it "conditionally" depends on P:1.5; > - M depends on A:2.0; and > - A:2.0 depends on P:1.1; > > then I want the build (specifically, dependency resolution) to fail. > > > Regards, > > 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. > > > > -----Original Message----- > > From: Marc De Boeck [mailto:mdeb...@gmail.com] > > Sent: 10 July 2014 20:57 > > To: ivy-user@ant.apache.org > > Subject: Re: "Optional/conditional strict dependencies"? > > > > 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 > > > ______________________________________________________________________ > > > > > > ______________________________________________________________________ > > This email has been scanned by the Symantec Email Security.cloud service. > > For more information please visit http://www.symanteccloud.com > > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ >
