[
https://issues.apache.org/jira/browse/IVY-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1159:
-------------------------------
Fix Version/s: 2.2.0-RC1
> Resolved Ivy Properties written to cache during ivy:resolve incorrectly
> represents transitive evictions
> --------------------------------------------------------------------------------------------------------
>
> Key: IVY-1159
> URL: https://issues.apache.org/jira/browse/IVY-1159
> Project: Ivy
> Issue Type: Bug
> Components: Core
> Affects Versions: trunk
> Reporter: Ed Burcher
> Fix For: 2.2.0-RC1
>
> Attachments: IVY1159.tar.gz
>
>
> In ResolveEngine.resolve the code that writes the properties file appears to
> be incorrect.
> When the dependencies collection includes two or more entries for the same
> dependency (one from the root ivy file and the others being transitives), the
> properties file will always only ever be populated with the information from
> the IvyNode that belongs to the root ivy file (effectively the comment states
> this, so it certainly appears intentional).
> This produces the following bugs / undesirable effects:
> * incorrect delivered descriptor in some situations (where a dependency is
> both directly and transitively imported)
> * order of declaration of dependencies alters behaviour
> These are pretty major problems because (as demonstrated below) a
> delivered/published ivy descriptor can identify completely bogus revisions
> for the dynamic->static replacements, which are not to the actual revisions
> used when compiling etc
> Set up
> module *one* has no dependencies and has been published (as rev = 1, say)
> module *two* has a dependency on module one (only) and has been published (as
> rev = 1, also)
> module *three* has dependencies on both modules one and two and *lists them
> in the order two,one*
> In the module three descriptor the revisions mentioned for two and one do not
> actually exist (two=0 & one=0 say - repository only contains rev=1 of both)
> Ivy settings (attached) has a resolver that refers to a local repo, and has
> force=true and local=true set.
> Problem Case - use case: publishing module 3
> 1) ivy:resolve on module three, using refresh=true, transitive=true.
> Otherwise nothing special here.
> then
> 2) ivy:deliver (status=reelase, pubdate=now, deliverpattern supplied,
> pubrevision supplied (rev=1))
> 3) (lastly, the ivy:publish step woud happen here, but is not relevant to the
> problem)
> Expected outcome:
> Because the primary resolver has force=true, rev 1 of both module
> dependencies of 'three' should be selected [Because rev=1 publications are
> the only ones present in the repository] when resolving three's declared deps
> (both of which declare a dep on rev=0).
> Actual outcome:
> Delivered descriptor correctly names two as being resolved to rev=1.
> Incorrectly names module one as being resolved to rev=0 (which doesn't exist
> - and never has!)
> Workaround:
> Reverse the order of the declared dependencies in three's ivy descriptor (i.e
> new order is one, two) - problem does not occur.
> Diagnosis:
> Logs for resolve appear to show everything is fine (the eviction is noted,
> the generated report xml shows the declared direct dependency (one, rev=0)
> being evicted by the transitive dependency (one, rev=1 as declared in two's
> published ivy descriptor)
> However, debugging DeliverEngine.java and ResolveEngine.java - it is apparent
> that the 'resolved ivy properties file' is used to drive the replacement of
> dynamic revisions with static ones during deliver. In the error case, the
> properties file shows this:
> +revision\:\...@\#\:+0\:\...@\#\:+module\:\...@\#\:+one\: <snip> :=0 ?
> +revision\:\...@\#\:+0\:\...@\#\:+module\:\...@\#\:+two\: <snip> :=1 release
> The '?' is put there because the IvyNode that represented the direct
> dependency has no descriptor (correctly, because it has been evicted).
> Because the real selected revision is not put into the properties file, the
> ivy:deliver task is doomed to produce wrong results.
> The correct behaviour in this case would be for the EvictionInfo stored
> against the evicted IvyNode to be inspected to find the appropriate revision
> information. I have attached a pretty ugly example of how this could be
> achieved.
> Just before the comment ("The evicted modules have no description, so we
> can't put their status")
> {code}
> if (depDescriptor == null) {
> EvictionData ed = null;
> for (int j=0; j<confs.length && ed == null;
> j++) {
> ed = dependencies[i].getEvictedData(confs[j]);
> }
> if (ed != null) {
> Collection selected = ed.getSelected();
> if (selected != null) {
> if (selected.size() == 1) {
> IvyNode sel =
> (IvyNode)selected.iterator().next();
> depDescriptor = sel.getDescriptor();
> depResolvedId = sel.getResolvedId();
> if (depResolvedId == null) {
> throw new
> NullPointerException("getResolvedId() is null for (transitive) "
> + dependencies[i].toString());
> }
> rev = depResolvedId.getRevision();
> }
> else if (selected.size() > 1) {
> throw new RuntimeException("Unexpectedly
> large number of selecteds within eviction collection");
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
