[
https://issues.apache.org/jira/browse/HBASE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590989#comment-13590989
]
Nick Dimiduk commented on HBASE-7971:
-------------------------------------
bq. And 'clean <other-targets>' removes the top-level target's contents?
Yep. Maven tells you what it's doing, it just suffers from the Java-ism of
being so verbose nobody actually pays attention. Invoke `mvn clean
<your-favorite-phase>` and look at the spew maven generates. It first decided
which modules to act upon and in what order. It then loops through them in
order and for each one, resolves the phase invocation tree into an ordered
list. Finally it executes those phases in order. More succinctly:
{noformat}
for (module in reactor.resolveModuleOrder())
for (phase in module.resolvePhaseOrder())
phase.exec()
{noformat}
For hbase-it, that means it runs, say, [clean compile test package it-test]
(plus all the pre and post subphases) as you'd expect. This dutifully produces
$BASEDIR/target/cached_classpath.txt during the compile (before HBASE-7637) or
test (after HBASE-7637) phase. The top-level hbase pseudo-module is the last
item in the reactor list, so it's run last. It executes the same phases in the
same order: [clean compile test package it-test]. The module contains a target
dir, so clean dutifully nukes $BASEDIR/target and then has nothing to do for
the remaining phases.
bq. cached_classpath.txt is odd.... needs to run last.
Right. I believe it's currently implemented in hbase-it because that module by
definition needs to depend on everything else (except hbase-examples, I
suppose). Since hbase-it manages that file, I think it makes sense to keep it
under that module's target dir anyway. Hence the attached patch.
> mvn clean compile on trunk and 0.95 does not produce
> target/cached_classpath.txt
> --------------------------------------------------------------------------------
>
> Key: HBASE-7971
> URL: https://issues.apache.org/jira/browse/HBASE-7971
> Project: HBase
> Issue Type: Bug
> Components: build
> Affects Versions: 0.95.0, 0.98.0
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Priority: Minor
> Attachments:
> 0001-HBASE-7971-fix-cached_classpath.txt-dev-sandbox.patch
>
>
> The usual workflow of {{mvn clean compile}} followed by {{./bin/hbase foo}}
> no longer works. It looks like it was broken by HBASE-7637, switching the
> phase in hbase-it/pom.xml from {{compile}} to {{test}}. Before I propose the
> obvious patch, a couple questions:
> [~nkeywal]: why is this done in hbase-it instead of anywhere else, such as
> the top-level pom?
> [~eclark]: why does this execution in the compile phase break hadoop-2
> profile while running it in test does not?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
