Your point is not clear to me. You say you are interested in "design flaws
between...distributable modules". From my viewpoint the jar is THE
redistibutable module so I don't know how you could deliver separate
distributable modules and not be interested in jar files.

Now I do understand the value in understanding the cycles in namespace
patches if one is trying to consider how to package classes that are spread
across multiple namespace packages into various jars. One of course does
this to avoid all of the problems associated with cyclic dependencies amount
binary packages. I'm under the impression however that this is not what you
mean. What do you mean?

> Hi Chuck,
> I must say I do not fully agree with you.

I'm glad you disagree ;) as now a dialog can begin which is what I was
looking for.

> I believe you are putting too much
> stress on the jar as a the only way of packaging software modules.

At least for java - how else do you (binary) package for deployment?
Martin's package principles are aimed at binary packages.

>Personally, I
> would find JDepend of very little use if it would look just into jars... I
could
> write my dependency analyzer myself if I wanted something like that :-)

but it can/does look into jars

> I much prefer having a tool that helps me understanding design flaws
between
> what I could deliver as separate distributable modules, regardless the
fact I
> actually distribute them as really separated jars.

Oh I do see value in using JDepend to understand namespace package cycles in
considering what namespace packages might go into separate redistributable
modules (for me of course... jars), I stated that in my initial post.

Can you clarify your disagreement?