ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: dynamically modifying dependency versions during resolve
Date Fri, 27 Jun 2008 01:24:50 GMT
On Thu 2008-06-26 at 19:18h, Shawn Castrianni wrote on ivy-user:
> No, I want to test A against a dependency way down in the hierarchy.
> Why should I have to make A be directly dependent on H when it is
> already indirectly dependent on H?

Because A is not (indirectly) dependent on plain H, but dependent on a
particular revision of H. If you want to test A against a different
revision than the one A effectively depends on, you have to specify
that information for the resolution process of A specifically. The
resolution process of A is defined by A's ivy.xml (and the settings),
so it seems like the most suitable place for that information (besides
the settings).

> Maybe this comes down to how one should specify ivy dependencies.
> It sounds like you are saying that if A needs to be tested against a
> change in H, then that must mean that A has a direct dependency on H
> in the code so it should be declared that way in A's ivy.xml file.

Not quite. What I'm saying is that the existing dependency chain from
A to H does not point to the revision of H you want to test against.
Let's go back to the A->B->C example for the moment as that's a bit
easier to work with :). So, you have an ivy.xml sitting there for A
which says that A depends on the lastest B revision. Let's say the
latest published B revision is B1, and its ivy.xml says that it
depends on C1. So the dependencies effectively declared by A's ivy.xml
are A->B1->C1. But you want to test with C2. Well, tough luck ;), but
that's a different revision than the one A transitively depends on.

What I wonder here is: After you've tested C2 with A and published
it to the public repository, how can that testing be put to use?
Builds of A or dependencies on A will still get the old C1, *unless*
a dependency on C2 is specified somewhere by some module. Then why
should the testing be able to do without specifiying that dependency?

> I have purposely removed all unnecessary direct dependencies if a
> dependency will get picked up indirectly.  This removes a lot of
> conflicts that can occur during dependency resolution.  So even
> though A may call a function in H making it directly dependent on
> it, I have purposely not made H a direct dependency of A because it
> will get it indirectly through B.  My philosophy produces cleaner
> dependency graphs and prevents lots of modifications to ivy.xml
> files to try to keep ivy dependencies in sync with the actual code
> dependencies.  A should be able to make function calls to B, C, D,
> E, F, G, and H without having to be directly dependent on them in
> its ivy.xml file.

It depends. If the function calls made by A to H are not inherently
due to to A's use of B, then A should quite likeley have its own
dependency on H. But that is a bit beside the point.

Maybe the relevant point is that dependency resolution for building a
module X and the published dependencies of module X (for the purpose
of *using* module X) are two different[1] things not only for the
direct dependencies of X but for its transitive dependencies as well.
So the problem with Ivy might be that it only specifically makes that
distinction for direct dependencies (resolved ivy.xml vs. non-resolved
ivy.xml). My feeling is that all the resolution override features are
basically attempts at addressing this problem. But whichever way one
looks at it, making a different choice for transitive dependencies at
build time implies that the choice needs to specified for whatever is
being built, which means that it becomes non-transitive at that point,
because (this is almost too trivial) the intermediate dependencies are
already built and hence not part of what is being built. Of course it
might be specified generically as "upgrade all transitive dependencies
to the latest revision", but it still means that changes(!) to the
transitive dependencies are being specified at the "root" module.

[1] To elabotarate on the distinction: The published dependencies
specify "what am I compatible with" or "what do I require at least",
whereas the build/packaging dependencies specify "what do I actually
want to have included in the build". Of course the latter is, or
should be, constrained by the former, but it's nevertheless a separate
choice, and one for which it doesn't matter whether a dependency is
transitive or direct.

-- Niklas Matthies

Mime
View raw message