bq. It’s an extremely rare event that this type of re-ordering occurs, so risk/reward favors risk.
Unfortunately HDFS-9214 requires building hadoop-hdfs-client before building hadoop-hdfs, which leads to the failure. Same problem for HADOOP-12500 as it introduces a new module hadoop-common-client. Can you please post a more detailed pointer on how to fix this? ~Haohui On Wed, Oct 21, 2015 at 5:48 PM, Allen Wittenauer <a...@altiscale.com> wrote: > > On Oct 21, 2015, at 5:11 PM, Allen Wittenauer <a...@altiscale.com> wrote: > >> >>> https://issues.apache.org/jira/browse/HADOOP-12500?focusedCommentId=14968065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14968065 >> >> This is yetus. >> >>> >>> Looks like a bug? > > > Actually, looking closer at this last one, this is a fun one. I’m > still experimenting, but it looks like a backwards incompatible change that > breaks the build dependency ordering. It’s trying to grab a jar from the > maven repos that doesn’t exist yet. This *will* succeed if the local cache > already has a copy of it. Chances are, if this commit were to go in, it’ll > break every build that doesn’t run at root until the master maven repo or the > local cache is up-to-date. It’s a flag day for building trunk. > > Unlike the older version, the Yetus’ hadoop module avoids building at > root to speed things up and has a list of modules to build in a particular > order and even injecting other compiles that normally wouldn’t happen in > order to improve test coverage. So old test-patch would let this go through > unabated, the new one does not. It’s an extremely rare event that this type > of re-ordering occurs, so risk/reward favors risk. > > Depending upon your point of view, this is a feature, not a bug. > File a bug (and, preferably, a patch) against Yetus to update the hadoop > personality to tell yetus that a new order is needed.
