ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <dic...@nortelnetworks.com>
Subject [Patch] addition of an "include level" to the matching task & jav ac task
Date Tue, 30 Jan 2001 17:20:02 GMT
I have found the need to change the behaviour of the javac task in
conjunction with the way that files are included/excluded before the
compiler is called.  

Currently, what happens is that the Javac task creates a set of "candidate"
files.  This is a list of files that match the include and exclude patterns
stated by the task's attributes/parameters.  Next the Javac task goes
through that set of candidates, eliminating source files where the
associated class file is considered up to date with the source file.  Thus,
the task only sends the files to the compile that it thinks are out of date.

My desire is to have a little bit of control over that second stage - the
elimination stage.  

Why?  On a ClearCase file system, file access is slightly slower then local
hard drive access (due to networks, NFS mounts, repository server loads,
etc).  Therefore, accessing two different files in different directories for
time stamps can take a while.

What do I propose?  I want to be able to tell the javac task to ignore the
elimination phase.  I want the task to simply send all files to the
compiler.

How do I propose to do this?  I have added an attribute to the MatchingTask
task called "includelevel".  This is to indicate the level to which I want
to include files.  MatchingTask is only the holder for the attribute -- it
actually does nothing with it.  It is up to subclasses to react to the value
within the attribute.  Therefore, I have also made changes to the javac task
such that if the includelevel attribute equals "all" then all files will be
included in the javac task.  If the includelevel equals "outofdate" (or
anything other then "all" for that matter), then the default behaviour will
be used.

Why have I put the attribute in the MatchingTask class?  I'm sure that there
are sub tasks that could more granularity of control over the include
results.

Does this work?  I have found it to be quicker on slow file systems where
the code base is over 1700 files.

Well?  What does the ant community think?





 <<index.html.txt>>  <<Javac.java.txt>>  <<MatchingTask.java.txt>>


--
Jay Dickon Glanville
P068 - SiteManager Development, Nortel Networks
613-765-1144 (ESN 395-1144)
MS: 045/55/A05
E-Mail: dickon@nortelnetworks.com


Mime
View raw message