Trustin Lee wrote:
Hi,
I've just ran JDepends against the current trunk, and it found some
cyclic dependencies:
--------------------------------------------------
- Package Dependency Cycles:
--------------------------------------------------
org.apache.mina.example.tapedeck
|
| org.apache.mina.statemachine.context
|-> org.apache.mina.statemachine
| org.apache.mina.statemachine.transition
|-> org.apache.mina.statemachine
org.apache.mina.statemachine
|
| org.apache.mina.statemachine.transition
|-> org.apache.mina.statemachine
org.apache.mina.statemachine.annotation
|
| org.apache.mina.statemachine.event
| org.apache.mina.statemachine.context
|-> org.apache.mina.statemachine
| org.apache.mina.statemachine.transition
|-> org.apache.mina.statemachine
org.apache.mina.statemachine.context
|
|-> org.apache.mina.statemachine
| org.apache.mina.statemachine.transition
|-> org.apache.mina.statemachine
org.apache.mina.statemachine.event
|
| org.apache.mina.statemachine.context
|-> org.apache.mina.statemachine
| org.apache.mina.statemachine.transition
|-> org.apache.mina.statemachine
org.apache.mina.statemachine.transition
|
| org.apache.mina.statemachine
|-> org.apache.mina.statemachine.transition
I'm not sure we have to fix this because all these classes are pretty
tightly coupled with each other. What should we do with these
packages?
Trustin
Hi,
I assume that JDepends uses uses the import statements in the code,
right? Eclipse will add imports for @link Javadoc tags which is probably
why you see so many cyclic dependencies.
So what do we do in this case? I would hate to have to write fully
qualified class names in Javadoc snippets. I would say that JDepends is
wrong if it only looks at imports. Instead, it should try to figure out
what the actual code depends on. Please correct me if I'm wrong but when
looking at the code in o.a.m.sm.content the only reference I find to
o.a.m.sm.event is in a Javadoc snippet.
/Niklas
