A while ago I wrote a unit test that used JDepend to help keep developers using a layered approach when using packages. Unfortunately devs worked out that by creating new packages they could work around that limitation instead of using IOC and avoiding circular dependencies.
So Tom mentioned the ant-contrib tasks, Compile With Walls and VerifyDesign.
Compile with Walls is great, packages won't compile if layers are broken. It is marked as deprecated with Verify Design to replace it.
Verify Design works after compilation and can't detect the source code violations of constants imported from other packages.
Compile With Walls requires dependant packages to declare all dependencies and the dependencies of dependencies, which could get unwieldly, but still potentially useful. An option to not have to do that would be nice.
4 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
I’m using JOODI to do exactly this at the moment. Its very fast, and has a few added extra’s thrown in. Kinda like checkstyle, but at a design level that covers multiple classes and packages rather than individual source files.
I personally think that the best way of solving dependency problems is to have physically seperate modules/subsystems/projects/you-name-it. Compile them seperately, and you _know_ what your dependencies are.
COMMENT:
I remember when Simon and James were working on it, I’ll have to check JOODI out.
While you can manage dependencies with modules at compile time it seems to me this would only really work at coarse grained layers; for web, domain, ejb (if u are unfortunate enough to have them).
I would expect it to be more of a pain to try and add finer grained dependency rules thru compilation when with CompileWithWalls and I assume JOODI you add a single line and introduce a new dependency check.
Also is easy for governance, as I should only need to watch for changes to the dependency rules file for potential offenders trying to break rules.
The JDepend API is limited, while it does it’s main task ok. Trying to use it to stem cyclic dependencies or report the offending class/pkg that creates the cycle required me to write code I just shouldn’t have had to.
Sorry to hear that people weasled their way around the JDepend stuff (especially from the level of developers I remember working with back there), but I suppose rules are bound to be broken at some stage. Nice to see a few alternative approaches suggested