[ https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565828#comment-14565828 ]
Sean Busbey commented on HADOOP-11929: -------------------------------------- {quote} The whole premise of this change is that we should spend more human time building and maintaining a complex explicit dependency management infrastructure to save CPU time on the build cluster. {quote} I think there's been a misunderstanding. The point of this particular patch is just to enable test-patch users specify when they need to do something special. The most obvious use case would be when particular profiles are used (either specific to a project or for different test checks). The one I personally care about is the use of a single git repo for multiple related projects (i.e. NIFI-577 or the case of the maven-parent-pom project). The example personality (hadoop.sh) is just Allen moving the long-standing hadoop logic quirks into a single location so we can more easily maintain them. In the process he has found and fixed some errors, but that's strictly a side effect. > add test-patch plugin points for customizing build layout > --------------------------------------------------------- > > Key: HADOOP-11929 > URL: https://issues.apache.org/jira/browse/HADOOP-11929 > Project: Hadoop Common > Issue Type: Improvement > Reporter: Sean Busbey > Assignee: Allen Wittenauer > Priority: Minor > Attachments: HADOOP-11929.00.patch, HADOOP-11929.01.patch, > HADOOP-11929.02.patch, HADOOP-11929.03.patch, hadoop.sh > > > Sean Busbey and I had a chat about this at the Bug Bash. Here's the proposal: > * Introduce the concept of a 'personality module'. > * There can be only one personality. > * Personalities provide a single function that takes as input the name of > the test current being processed > * This function uses two other built-in functions to define two queues: > maven module name and profiles to use against those maven module names > * If something needs to be compiled prior to this test (but not actually > tested), the personality will be responsible for doing that compilation > In hadoop, the classic example is hadoop-hdfs needs common compiled with the > native bits. So prior to the javac tests, the personality would check > CHANGED_MODULES, see hadoop-hdfs, and compile common w/ -Pnative prior to > letting test-patch.sh do the work in hadoop-hdfs. Another example is our lack > of test coverage of various native bits. Since these require profiles to be > defined prior to compilation, the personality could see that something > touches native code, set the appropriate profile, and let test-patch.sh be on > its way. > One way to think of it is some higher order logic on top of the automated > 'figure out what modules and what tests to run' functions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)