You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Greene, Hugh" <HG...@tmvse.com> on 2014/07/10 18:24:28 UTC
"Optional/conditional strict dependencies"?
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
______________________________________________________________________
Re: "Optional/conditional strict dependencies"?
Posted by Marc De Boeck <md...@gmail.com>.
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 <HG...@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 <HG...@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
> ______________________________________________________________________
>
RE: "Optional/conditional strict dependencies"?
Posted by "Greene, Hugh" <HG...@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 <HG...@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
______________________________________________________________________
Re: "Optional/conditional strict dependencies"?
Posted by Marc De Boeck <md...@gmail.com>.
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 <HG...@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
> ______________________________________________________________________