Hi Cody,

Both tests should pass because bridges.cma.view package uses the bridges.cma.util package but the reverse is not true. In both cases the the dependencyMatch returns false when it should only return false for testDependencyConstraint2().

I'll admit that I'm not happy with the way the DependencyConstraint class turned out, but I'm not sure this is a bug.  

The DependencyConstraint.dependencyMatch() will only return true if:

    - The number of packages analyzed by JDepend equals the number of packages added to the DependencyConstraint

and

    - Every class in the DependencyConstraint must have a dependency graph equal to an analyzed package of the same name

In other words, the graph of packages in the DependencyConstraint must exactly match - in size and content - the graph of packages collected when jdepend.analyze() is invoked.  That is, if you analyze the entire project, then all the packages must be specified in the constraint.  You can of course narrow the analysis to only two projects, but you must specify all of their dependencies in the constraint.  It's not ideal, I realize.

So, I'm guessing that your 'bridges.cma.util' and 'bridges.cma.view' packages actually have other dependencies, other than on themselves.  Looking at a report would help figure this out.  If this is the case, then dependencyMatch() will always return false given your example DependencyConstraint.

I'm investigating other ways to design the DependencyConstraint class.  Ideally, if it fails you'd like to see a expected/actual graph of some form rather than just a boolean return value.  I'm open to opinions as to how this could be made better.  It's something I'd like to clean up in the next release.

Let me know if this makes any sense and whether it helps solve the mystery of your situation.

Thanks,

Mike

-- Mike Clark
http://clarkware.com
(720) 851-2014