Hi Chuck,
I must say I do not fully agree with you. I believe you are putting too much
stress on the jar as a the only way of packaging software modules. 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 :-)

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.

Just my two cents.

Stefano


--

Stefano Fornari - Sync4j Project Manager / Funambol CTO
=======================================================
Home:
http://www.sync4j.org
FAQ:
http://forge.objectweb.org/docman/view.php/96/39/general.html
Project Documentation:
http://forge.objectweb.org/docman/index.php?group_id=96
Documentation site:
http://sync4j.funambol.com/main.jsp?main=documentation
List archives:
http://groups.yahoo.com/group/Sync4j (login required)
http://sourceforge.net/mailarchive/forum.php?forum_id=215

Sync4j - The open source SyncML mobile application platform

Chuck wrote:
> I've long considered myself a student of Martin's and have studied his OO
> design principles, however his package design principle can be a bit
> confusing. In the context of his package design principles the term
> "package" refers to releasable, binary component such as a DLL or a Jar
> file, and not Java packages which are really just a namespace mechanism. He
> points this out in his white papers on package cohesion (see Granularity
> http://www.objectmentor.com/resources/articles/granularity.pdf ) and he has
> also pointed this out in various newsgroup postings
> (http://groups.google.com/groups?q=uml+packages&start=10&hl=en&lr=&group=com
> p.object.*&scoring=d&selm=pr6v90d3jnud9cf9c7leaoorpi1utt6m8h%404ax.com&rnum=
> 11). From here out I will use the term "jar", "component" or "binary
> package" in reference to Martin's definition of "package" to avoid confusion
> with java "namespace packages".
>
> JDepend can be a bit confusing in that it uses Java "namespaces packages" to
> perform it's analysis while Martin's definition for "package" refers to
> jars; at least in the context of Java. In a way it would make more sense if
> JDepend (or any tool that implements Martin's metrics) would examine various
> jar files and analyze the dependencies there. After all Martin's package
> coupling metrics are about relationships between binary packages and not
> about namespace packages.
>
> However JDepend's approach may still be useful. Assuming that one follows a
> convention of placing all classes within a given namespace package into a
> jar, JDepend may help one to decide how to distribute namespace packages
> amongst jars. Again this assumes that the designer is motivated to utilize
> multiple jars for reasons such as reuse, division of labor during
> development, testability, etc.
>
> Martin's binary package principles indicated that there should be no cycles
> of dependencies between binary packages; with this I agree. (I have seen
> the nightmares of this violation in the C++ world.) JDepend identifies
> cycles between two different namespace packages, but I'm not convinced that
> this is necessarily a bad thing. It seems to me that it depends upon
> whether the namespace packages are in the same jar or not. If they are in
> the same jar then while probably still not ideal, it is something that one
> could live with as it does not introduce all of the various problems that
> Martin points out because of his definition of package.
>
> Unless people utilizing JDepend fully understand Martin's definition of
> packages - and I feel he does not make this point clear enough in his
> writings - then they may be mislead by JDepend into thinking that their
> package structure needs work when finding cycles among the namespace. Keep
> in mind that I'm not writing this so much to criticize JDepend, but rather
> gain deeper insight into Martin's metrics and JDepends implementation of
> them.