[
https://issues.apache.org/jira/browse/HDFS-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Foley updated HDFS-2031:
-----------------------------
Description:
For dev test, need to test an HDFS patch that is dependent on a modified COMMON
jar.
For casual testing, one can build in COMMON with "ant mvn-install", then build
in HDFS with "ant -Dresolvers=internal", and the modified COMMON jar from the
local maven cache (~/.m2/) will be used in the HDFS build. This works fine.
However, running test-patch locally should build:
* pre-patch: build unmodified HDFS with reference to generic Apache COMMON jar
(because the modified COMMON jar may be incompatible with the unmodified HDFS)
* post-patch: build modified HDFS with reference to custom local COMMON jar
Currently, each developer has their favorite way to hack build.xml to make this
work. It would be nice if an ant build switch was available for this use case.
It seems to me the easiest way to accomodate it would be to make
"-Dresolvers=internal" be effective only for the post-patch build of
test-patch, and let the pre-patch build use the generic Apache jar.
Of course the same thing applies to MAPREDUCE test-patch when dependent on
modified COMMON and/or HDFS jars.
was:
For dev test, need to test an HDFS patch that is dependent on a modified COMMON
jar.
For casual testing, one can build in COMMON with "ant mvn-install", then build
in HDFS with "ant -Dresolvers=internal", and the modified COMMON jar from the
local maven cache (~/.m2/) will be used in the HDFS build. This works fine.
However, running test-patch locally with -Dresolvers=internal doesn't work.
There are three use cases, described below.
Summary: request HDFS test-patch to support coordinated change in
COMMON jar, for post-patch build only (was: request test-patch to work with
-Dresolvers=internal, for pre-patch and/or post-patch builds)
Upon further analysis of the build log file, I found that -Dresolvers=internal
does work with test-patch, I just needed to build in COMMON with "ant
mvn-si-install" instead of mvn-install.
So I'm changing this request to focus only on the use case of "coordinated
changes in COMMON and HDFS, where the modified COMMON is incompatible with the
unmodified HDFS".
@Todd - agree that the restructuring gives an opportunity for better solutions,
by looking at operations across components.
> request HDFS test-patch to support coordinated change in COMMON jar, for
> post-patch build only
> ----------------------------------------------------------------------------------------------
>
> Key: HDFS-2031
> URL: https://issues.apache.org/jira/browse/HDFS-2031
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: build
> Reporter: Matt Foley
>
> For dev test, need to test an HDFS patch that is dependent on a modified
> COMMON jar.
> For casual testing, one can build in COMMON with "ant mvn-install", then
> build in HDFS with "ant -Dresolvers=internal", and the modified COMMON jar
> from the local maven cache (~/.m2/) will be used in the HDFS build. This
> works fine.
> However, running test-patch locally should build:
> * pre-patch: build unmodified HDFS with reference to generic Apache COMMON
> jar (because the modified COMMON jar may be incompatible with the unmodified
> HDFS)
> * post-patch: build modified HDFS with reference to custom local COMMON jar
> Currently, each developer has their favorite way to hack build.xml to make
> this work. It would be nice if an ant build switch was available for this
> use case. It seems to me the easiest way to accomodate it would be to make
> "-Dresolvers=internal" be effective only for the post-patch build of
> test-patch, and let the pre-patch build use the generic Apache jar.
> Of course the same thing applies to MAPREDUCE test-patch when dependent on
> modified COMMON and/or HDFS jars.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
