A package cycle occurs when one of your java packages depends on another, and that other package depends back on the first package, either directly or indirectly.
Removing package cycles from a project has a number of advantages. It forces you to properly layer your code, which in turn forces you to think about how to properly layer it early on. Properly layered code is more reusable, more testable, and much more maintainable.
The best way to manage package cycles is to include a junit test in your project that enforces 0 package cycles. Examples here: http://clarkware.com/software/JDepend.html#junit
But what should you do if you already have a project that contains dependency cycles? Sonar is an excellent starting point. Sonar produces a pretty chart that allows you to navigate through your cycles and fix them. But iterations with Sonar can be slow and cumbesome–you have to commit your code and then wait for a build and analysis.
The eclipse JDepend plug-in is one way to tighten that iteration–it brings your dependency analysis to your IDE. But I find the JDepend plug-in to be really limited. the provided UI is a stack of obscure tables that, for me anyway, don’t clearly point to my package cycles.
I recently discovered an AWESOME eclipse plug-in for dependency analysis called STAN (http://stan4j.com/). It’s free if your project is smaller than 500 classes or if your work is non-commercial. Otherwise there is a reasonable license fee. It produces beautiful dynamic clickable cycle diagrams that are intuitive and easily facilitate the work of eliminating package cycles.