[
https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567471#comment-14567471
]
Sean Busbey commented on HADOOP-11929:
--------------------------------------
{quote}
I am sort of leaning towards calling mvn install after the javac and letting
the personality decide which which modules to build. Effectively, when they are
told that mvninstall is going to happen, they could enqueue . (or whatever
module is appropriate) when told they are working on the branch but then just
enqueue the impacted module at patch time.
I think we can avoid the toggle then too.
{quote}
sounds great to me.
{quote}
If you go with running a full mvn install, then another way to speed it up is
to skip the JavaDoc plugin by passing -Dmaven.javadoc.skip=true. Alternatively,
maybe there is a way to combine this new mvn install with the existing JavaDoc
validation build, although that might be difficult.
{quote}
This would help the HBase build a bunch, I know that our javadoc run takes an
unusually long amount of time. The personality could do this part to though,
right? By defining a profile that skips the javadocs?
> 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)
