ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc De Boeck <mdeb...@gmail.com>
Subject Re: "Optional/conditional strict dependencies"?
Date Fri, 11 Jul 2014 11:14:20 GMT
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 <HGreene@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:hgreene@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:mdeboec@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 <HGreene@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:hgreene@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
> ______________________________________________________________________
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message