[
https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568154#comment-14568154
]
Allen Wittenauer commented on HADOOP-11929:
-------------------------------------------
Based upon Colin's feedback, I've simplified the patch and will deal with these
other issues in another JIRA. In particular:
bq. 1. setting the right combinations of profiles on relevant architectures
I've ripped this out. Builds are as they were before with just -Pnative if the
appropriate native flag is enabled. We will need to redo the research on what
works and what doesn't at a later date.
bq. 2. ensuring that the right combination of maven builds are triggered (i.e.
need to trigger mvn install first, need to compile hadoop-common if any other
submodule is being compiled
I've mostly ripped this out. The ordering of modules now the same as the
currently running code, bugs and all. mvn install is still done first since
that's need for other projects.
bq. 3. re-using the Hadoop build scripts for NiFi, HBase and other non-Hadoop
projects
I've kept this in since that's the entire reason this JIRA exists.
bq. 4. fixing parallel test builds
This was never part of this patch officially, so it's gone.
bq. 5. fixing issues with ClientBaseWithFixes.java, TestSSLHttpServer.java,
KeyStoreTestUtil.java, and some other tests (possibly concurrency related?)
This was never part of this patch officially, so it's clearly been ripped out
as well.
> 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)
