Classcyle

[cdempsey]

Have we picked Classcycle as the tool to wrap for class dependencies?

[Mike Nereson]

Have we picked Classcycle as the tool to wrap for class dependencies?

Currently we are using JDepend to detect cyclic dependencies. JDepend is limited in that it can not detect static dependencies. That is, it only detects dependencies between one Object and another Object. It can not detect dependencies from on Object to a package. I'd like to reimplement the org.architecturerules.api.services.CyclicRedundancyService to use Classcycle in hopes of detecting dependencies that would otherwise have gone undetected with JDepend. Does that answer your question? We don't use Classcylce at all yet. In fact someone will really need to research the tool and ensure that it does actually preform above and beyond the current JDepend dependant implementation.

By the way, since you mentioned wrapping. I don't want to reexport any third party dependencies. So while we're reviewing old code and writing new code, lets keep an eye out for returns and parameters of Objects that are not from the JDK or our on domain when writing new API. This will allow us to change the tools we use and prevent our library from breaking when third parties change their APIs.

~ Mike Nereson

[Mike Nereson]

And another note in regard to Issue 59: "DependencyConstraintException should report the violating class." We should be able to utilize Classcycle to resolve this issue. I

~ Mike Nereson

[Chris Dempsey]

Yeah.  I was looking at that issue and was just making sure Classycle was on the short list of choices so I could spend some time getting familiar with it.