You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Allen Wittenauer (JIRA)" <ji...@apache.org> on 2014/07/29 21:12:40 UTC

[jira] [Resolved] (HADOOP-6340) Change build/test/clean targets to prevent tar target from including clover instrumented code

     [ https://issues.apache.org/jira/browse/HADOOP-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Allen Wittenauer resolved HADOOP-6340.
--------------------------------------

    Resolution: Won't Fix

> Change build/test/clean targets to prevent tar target from including clover instrumented code
> ---------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-6340
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6340
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: build
>    Affects Versions: 0.20.1
>            Reporter: Lee Tucker
>            Assignee: Giridharan Kesavan
>
> Currently the clover targets in build.xml cause the code generated in the build root to contain clover instrumented code.   Should the tar target be called, this instrumented code is packaged up and made part of what would be delivered to the grid for use.   Installing cloverized code on real clusters is generally a very bad idea unless it's done with significant upfront thought.   
> I propose that we alter the targets so that when clover is enabled, the compile target does two passes.   The first would generate the uninstrumented code in the standard build root.  The second pass would then generate clover instrumented code in a build-clover build root.  That way, the tar target would only pick up uninstrumented code.   I strongly suggest a 2 pass compile, and not a different target, because you never want the two sets of objects to be out of sync.  (For instance, you might want to run the clover instrumented unit tests, and then package the uninstrumented code to be delivered to the next step in your QA/Release process.)
> The test targets would also need to be altered.  I'd propose that the test results still be placed in their current location in the build root, regardless of whether the tests were run with instrumented or uninstrumented code.   This means that when clover is enabled, that the test target would execute against the objects in build-clover, but report results in build.  (This would allow currently existing test infrastructure to continue to report results without modification.)
> The clean target(s) would also need to be enhanced to clean out both build roots.
> The only drawback to this approach I can see is that if you wanted to produce instrumented code to be delivered to a real grid, you'd have to create the package from build-clover instead of build manually, or we'd have to add a "tar-with-clover" target that did it for you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)