[ https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Allen Wittenauer updated HADOOP-11929: -------------------------------------- Attachment: (was: HADOOP-11929.04.patch) > 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)