[
https://issues.apache.org/jira/browse/MAPREDUCE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792749#action_12792749
]
Chris Douglas commented on MAPREDUCE-1114:
------------------------------------------
bq. Some of these are within the same ant run, so they get cached. But 16 of
them actually do some non-cached work [...]
If I understand you correctly, the punchline is that improvements to
intra-build caching are not only tedious, but also not a sound way of reducing
the build time, as most classpaths are independently defined. So without
fundamentally changing how dependencies are resolved, attacking the problem as
in the current patch is the only way to effect a meaningful reduction. Is that
the argument?
bq. fixing ivy doesn't make much sense - we'd be better off focusing on moving
towards Maven.
Is there a JIRA tracking progress in removing ivy? If it's not happening in the
near term, then something like the current patch may be worth keeping in trunk
during interim 0.22 development.
> Speed up ivy resolution in builds with clever caching
> -----------------------------------------------------
>
> Key: MAPREDUCE-1114
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1114
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: build
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Minor
> Attachments: mapreduce-1114.txt, mapreduce-1114.txt,
> mapreduce-1114.txt
>
>
> An awful lot of time is spent in the ivy:resolve parts of the build, even
> when all of the dependencies have been fetched and cached. Profiling showed
> this was in XML parsing. I have a sort-of-ugly hack which speeds up
> incremental compiles (and more importantly "ant test") significantly using
> some ant macros to cache the resolved classpaths.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
