hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HADOOP-6340) Change build/test/clean targets to prevent tar target from including clover instrumented code
Date Tue, 29 Jul 2014 19:12:40 GMT

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

View raw message