I manage the page with javadepend, which has not been updated in
years. I stashed a copy of javadepend there mainly to preserve
history.
We had a similar problem where we needed to find dependencies and
someone use Ivy, which seemed to work reasonably well.
http://java-source.net/open-source/build-systems/ivy
Yes, it is always possible to miss classes because of reflection, but
Ivy gave us a leg up on analyzing dependencies. If you really want to
know what packages are used, do treeshaking by running java -verbose
and exercise the program. We use this to quite effectively for
shipping small jars. However, it is difficult to do treeshaking
automatically and get a complete set of jars unless you effectively
exercise the program.
Also, the Eclipse Metrics package has a dependency visualizer that
might be of interest. I looked at it briefly this week.
About the ant/make thing. After using both and shipping both, I've
come to the conclusion that that Ant and Make to be pretty much
functionally equivalent. One can argue about the details though.
To ship software, what I need is the following:
1. Before compilation, some checks and searches need to happen.
Checks for the right version of the compiler etc., searches for
extensions. Historically, this is done with configure, though ant
can do more of this than it used to.
Unfortunately, portions of my user community does not want to run
configure before starting Eclipse. Nor do they want to run an
ant task from within Eclipse.
2. During compilation, packages that won't compile need to be skipped.
Many years ago, ant could not handle dependencies, now it can.
Also, many years ago, the ant page said it was written by people
who did not understand make. I've seen this issue before when
people complain about make and then start writing their own system.
3. At release time, each package needs to have some sort of manifest
that lists files and subdirectories to be shipped. Currently, the
manifest for Ptolemy is in makefiles, but it could be in separate text
files, which could be read by recursive ant files.
4. At user run time, I'd like to provide modules and provided updates
similar to Eclipse/Equinox and the oSGI work. This requires dependency
analysis based on versions, including supporting modules that
themselves might require different versions of _the_same_ jar file.
This is difficult, and requires classpath support.
The manifest files are what refute some of the arguments put forth in
"recursive make considered harmful."
Ant and Eclipse's "Just compile everything" strategy does not work for
research projects where some packages in a tree will not compile
unless missing dependencies are present.
Thus, I'm interested in Maven, but really looking for something that
handles complex configuration and package dependencies.
Personally, I'm pretty happy with the package system, it does make
modularizing large projects (>300k LOC) possible. However, more
work needs to be done concerning supporting multiple projects.
_Christopher
Aryeh M. Friedman said:
Isn't this a catch-22 though in that if you are in a mixed lang
enviroment and either need the java compiled first (in the case of it
being the backend) or the other lang being done first (JNI) and it is
being compiled by someone who has not developed it then it then
follows there are no .class files. Why did sun get rid of -depend on
javac anyways? I also found JavaDepend
(
http://ptolemy.eecs.berkeley.edu/~cxh/java/javadepend/) but it
doesn't work on anything newer then 1.1 and I am doing 1.5 projects.
Also in an other post in the thread someone mentioned if a compile
doesn't work with say javac `find . -name '*.java'` or javac *.java
then it is time to break it apart into standalone jar's. This too
raises a depend issue in that if oyu have several packages which ones
need to be recompiled when X changes.
In short I am *NOT IMPRESSED* with Java's ability to manage large
projects, In a way this is the same issue recursive make has
http://aegis.sourceforge.net/auug97.pdf
--
Christopher Brooks (cxh at eecs berkeley edu) University of California
Chess Executive Director US Mail: 337 Cory Hall #1774
Programmer/Analyst Chess/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718 (office: 400A Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480