[ 
https://issues.apache.org/jira/browse/MAPREDUCE-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786322#action_12786322
 ] 

Chris Douglas commented on MAPREDUCE-1114:
------------------------------------------

I thought the bulk of the problem was re-resolving these properties during the 
same run. Is that mistaken? The current proposal also works across runs, which 
could be helpful, but again: maintaining the build is already a pain. Adding a 
cache to a bad idea is a well established software engineering practice, but 
I'd favor either fixing our use of ivy or replacing it if middling performance 
requires this.

> 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.

Reply via email to