A MAVEN cycle-dependent big case!

Today to the application Jar package upgrade version, Oh, the version number rose to a higher version, when the compilation started, the compilation does not pass.

Detailed error information is as follows:

[ERROR] Failed to execute goal in Project Ton-search-api:could not resolve dependencies for project Com.*.hto:ton-sear Ch-api:jar:1.31.0-snapshot:failure to find Com.*.hto:ton-search-api:jar:1.31.0-snapshot in http://mvn.*-yun.com/ Content/groups/public/was cached in the local repository, resolution would not be reattempted until the update interval of Dtdream has elapsed or updates is forced, [help 1]
[error] 
[ERROR] to see the full stack trace of the Errors, re-run Maven with THE-E switch.
[ERROR] re-run Maven using the-x switch to enable full debug logging.
[error] 
[ERROR] For more information about the errors and possible solutions, please read the following art Icles:
[ERROR] [help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ error] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   MVN & Lt;goals>-rf:ton-search-api

Initially thought is Maven convulsions, so directly open Web search error solution, find a lot of said "directly to the local warehouse Ton-search-api delete." I have tried many times and I can't.

In the end, it can only be repeated from the Code dependencies: the original TON-SEARCH-API This module is another colleague added, the API relies on other APIs, here called Ton-busib-api, And Ton-busib-api relies on TON-SEARCH-API, two API packages are interdependent. Drunken drunk, originally API jar package to be lightweight small, incredibly will happen API relies on other API this thing, undoubtedly aggravated the API package. Very indecent. However, this is not my concern, I am more concerned about how to solve the problem.

Sure enough, in the place where the loop-dependent packets are introduced:

<exclusions>
<exclusion>
<groupId>com.*.hto</groupId>
<artifactId>ton-search-api</artifactId>
</exclusion>
</exclusions>

It is possible to break off the cyclic dependency.

To put it simply: another big case of cyclical dependence. A packet depends on the B packet, and the B packet relies on a packet, When a package version from the 1.0.0 upgrade to 2.0.0, a package in the compile time, go to remote warehouse Download B package, found that B packet dependent a package, and then continue to download a package 2.0.0 version of the remote repository, the result maven silly, asked a: brother, your own 2.0.0 jar package is not compiling it. You have not compiled successfully, how do you deploy. You did not deploy, you let me download what. You're a fool to me. I quit. I threw it wrong.