[
https://issues.apache.org/jira/browse/IVYDE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543836
]
Nicolas Lalevée commented on IVYDE-64:
--------------------------------------
In fact I wasn't sure that ivy was hitting the cache. I put some breakpoint and
I saw that ivy was hitting the cache, so I assumed that it was not necessary to
check the cache manually. But as You spotted, what I saw might ivy hitting the
cache while trying to download the artifact. So let's not remove the cache
checking.
About the second point, I don't know very well ivy, so I might be also wrong.
But in the case where ivyde will not try to hit the cache and actually do the
resolve, the artifacts are already "instanciated", and can be retrieved from
the report : report.getArtifacts(). So I see no need to parse the report. Did I
missed something ? And even if we parse the report more than doing a resolve,
the java instance will contain the artifacts, won't it ?
> Simplify the resolve process
> ----------------------------
>
> Key: IVYDE-64
> URL: https://issues.apache.org/jira/browse/IVYDE-64
> Project: IvyDE
> Issue Type: Improvement
> Components: classpath container
> Affects Versions: 1.3.0
> Environment: trunk r595956
> Reporter: Nicolas Lalevée
> Attachments: IVYDE-64-r595956.patch
>
>
> The current trunk, the resolve job is first checking manually if the artifact
> has already been resolved. If not in cache, it let ivy resolve it. And
> finally it parses the xml reports in the cache.
> So first, as far as I have understood, the manual checking against the cache
> is not needed, ivy already does it.
> And then ivy produce in Java some resolve report that already contain every
> needed information, there is no need to parse the reports in cache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
