A while back, I wrote JarAnalyzer and have received many positive comments from developers who have found the ability to analyze dependencies among .jar files valuable. Recently, I began working on a .Net project, and I was quite surprised to see how few open source utilities are available for .Net development. Really nothing compared to the Java world. As I began search for .Net source code analyzers, I quickly found there weren't too many open source utilities that do for .Net what JarAnalyzer did for Java. That is, analyze a set of .Net assemblies and report on the dependencies. So I decided to roll my own, and have created AssAnalyzer.
30/05: Cyclic Dependencies
Excessive dependencies are bad. But cyclic dependencies are especially bad. Cyclic dependencies are manifest in various ways at different levels within a system. It's also possible that acyclic relationships at one level cause cycles at another. Huh? Here's the basics.
23/05: Physical Dependencies
Many of us spend time designing class relationships. In fact, a significant benefit of TDD (Test Driven Development) is the positive influence it has on design. A few years back, the Martin Metrics sparked interest in managing higher level dependencies, explaining their importance, and giving birth to JDepend, and other static analysis utilities such as JarAnalyzer. Yet, an important higher-level unit of deployment has been largely ignored…the .jar file.
06/04: JarAnalyzer Upgrade
I've made some significant changes to JarAnalyzer. First and foremost, I've cleaned up the internals of the utility and brought it under test. This was a wonderful experience, and one I hope to share sometime soon. Here's some of what you can do with the newest version.
Software tends to rot over time. When you establish your initial vision for the software's design and architecture, you imagine a system that is easy to modify, extend, and maintain. Unfortunately, as time passes, changes trickle in that exercise your design in unexpected ways. Each change begins to resemble nothing more than another hack, until finally the system becomes a tangled web of code that few developers care to venture through. The most common cause of rotting software is tightly coupled code with excessive dependencies.
06/03: Call to JARS
I've updated JarAnalyzer and fixed the bug (previously called a feature:-)) associated with running JarAnalyzer on a suite of .jar files that have cyclic dependencies. This makes the utility useful in helping to identify the cyclic dependencies between deployable units in your application. So I'm calling on all of you to run JarAnalyzer on your application. You can choose the .xml output, visual component diagram, or both (samples below). It will only take a few minutes, and the result will provide you with useful information. I'm also asking for some feedback from you.
10/02: JarAnalyzer Update
Recently, I added the ability to generate a GraphViz DOT output to JarAnalyzer. This means that you can generate two different types of output formats using JarAnalyzer. The first is an xml file. The second is a GraphViz compliant DOT file that can be used to generate a visual representation of the relationships between the jar files. Each can be run within the Ant task included with JarAnalyzer. You can also run JarAnalyzer as a standalone utility.
07/01: Dependency Management
When designing and architecting large enterprise applications, I take a very keen interest in managing the physical dependencies between deployable units. A physical dependency exists when one deployable module has a compile time dependency on another deployable module.
(RSS 2.0)