[
https://issues.apache.org/jira/browse/HADOOP-14453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16024180#comment-16024180
]
Allen Wittenauer commented on HADOOP-14453:
-------------------------------------------
bq. Why once-per-day?
Because that's all I need. My general pattern is:
1. Do a pull and merge in changes from trunk overnight
2. Do the mvn install to get local changes down into the appropriate repo while
in another window I look over what actually changed.
3. Review, write a patch, or do whatever, usually in a fresh rebase from trunk
into my test branch
4. Afterward, switch back to trunk and re-build just the jars that were touched
by that patch
5. go to step 3
I almost always work exclusively on trunk. On the rare occasions I work in
other branches that are cut off of trunk (can't remember when I last touched
branch-2), I use a different maven repo via MAVEN\_OPTS so there are no jar
collisions.
Probably worth noting that dev-support/bin/test-patch and dev-support/bin/qbt
with the appropriate flags automates a lot of this.
bq. I have 5 git clones in my machine.
Which begs the question: why don't people have 5 maven repos to match?
maven's shared repo model doesn't really work well with same project/multiple
repo dev patterns because there is nothing to prevent race conditions on it.
Ran two 'mvn installs'? Woops. I wonder which jar those unit tests are
running...
A lot of work went into Yetus to specifically work around that issue. Thus why
we haven't seen any spurious "unknown class" or related issues in testing in
over a year now. They were directly and completely related to having one maven
repo for multiple, simultaneous patch runs.
The community can do what they want with this JIRA (assuming it doesn't break
anything). I'm just pointing out an alternative that has almost always worked
for me, regardless of the project.
> Split the maven modules into several profiles
> ---------------------------------------------
>
> Key: HADOOP-14453
> URL: https://issues.apache.org/jira/browse/HADOOP-14453
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Tsz Wo Nicholas Sze
> Attachments: c14453_20170524.patch
>
>
> Current all the modules are defined at directly under <project>. As a
> result, we cannot select to build only some of the modules. We have to build
> all the modules in any cases and, unfortunately, it takes a long time.
> We propose split all the modules into multiple profiles so that we could
> build some of the modules by disabling some of the profiles. All the
> profiles are enabled by default so that all the modules will be built by
> default.
> For example, when we are making change in common. We could build and run
> tests under common by disabling hdfs, yarn, mapreduce, etc. modules. This
> will reduce the development time spend on compiling unrelated modules.
> Note that this is for local maven builds. We are not proposing to change
> Jenkins builds, which always build all the modules.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
