ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <>
Subject RE: Ant project versus jmk (Java in Make)
Date Tue, 22 Feb 2000 08:21:28 GMT
> From: Will Uther []
> I'd love to have that utility!  That sounds cool.  I don't suppose it
> handles different levels of dependancy (as I mentioned in the recent
> 'implcit dependancies' thread)?

I have two versions of that utility, both are still unpolished;-).

The first version just scans the constant-pool of .class files for class
references, and so determines the dependencies between classes. This works
good, although it is not very sophisticated. But hey, it's simple and fast.

Another version I'm working on right now is intelligent enough to determine
dependencies between all methods in all classfiles, and it is using private,
protected, package & public access levels, but I got still some problems
with that (inheritance, interfaces, ...).

> Regards having a separate file, is that neccessary?  If you 
> had some form
> of include arrangement then you could just read the other XML 
> file.  Not
> sure which of these I prefer.  Does XML have a standard 
> include syntax?  Is
> it supported by the parser used in ANT?

I actually don't care how the information is stored, as long as it is
available to the task. I am in favor for a separate file, such that it
can easily be regenerated automatically. The "problem" I have with
inclusion is that the DTD of the Ant build-file must be changed for only
one task, and that inclusion seems to be optional in XML parsers.
BTW: We could always stick to the old "<file>:<depencencies>*" notation,
such that we can use existing tools for the generation of the dependencies.

> > The logic could be placed after the selection of files 
> based on date. Just
> > add
> > the files that are dependant on files on the list to that same list.
> I prefer the more complex logic I mentioned in the "implicit 
> dependencies"
> thread.  There is no need to recompile something that depends upon the
> public interface if only the private interface has changed.

This logic will be really complex, and will consume a lot of cycles/memory.
I would say that simple dependencies, based on java/class files would
be enough. Okay, we might recompile a few files once in a while, for which
recompilation was not necessary, but we don't need the complex analysis,
which takes time, and we can compile in one run, which is a lot faster than
running the compiler multiple times for each set of new dependent files that
is encountered in the analysis.

My 2 cents,


View raw message