this task (which will be a great built-in task IMHO).
gracias
The logic _is_ a bit confusing. I had to wrestle with this a bit myself. I believeDESCRIPTION
The dependset task compares a set of source files with a set of target files. If any of the source files is more recent than any of the target files, all of the target files are removed.
Yes, this is the way it would be most useful. 8-) But the way you've implemented it, seems to be backwards to me.
You compare each file from the target filesets to all files from the source filesets with some special treatment for target files that don't have a corresponding source. This will not capture missing target files. You then determine all target files that are out of date with respect to any source file and delete these files.
To me the more logical approach would be to compare source files to target files, not giving targets as filesets but as a list of filenames for the targets and remove all targets (not just the outdated ones) if any of the source files is newer than the target files or a target file doesn't exist?
an example might help.
<dependset> <srcfiles dir="bar" includes="my-buildfile.xml"/> <targetfiles dir="foo" includes = "**/*.html"/> <targetfiles dir="baz" includes="**/*.class"/> </dependset>
Here we want to ensure that our java and XML source files get re-compiled if the buildfile changes.
If any of the HTML or class files does not exist yet, no problem-- they will be generated in the
usual way using <javac> <style> or whatever.
If any of the HTML or class files is NEWER than the buildfile, I don't need to remove them. They
are OK.
If any of the HTML or class files is OLDER than the buildfile, nuke 'em.
So-- I pass the target filesets to the SourceFileScanner as the files() param.
I pass the source fileset ("my-buildfile.xml") to the SourceFileScanner using a MergingMapper.
I tell the SourceFileScanner to restrict using the OLDER-THAN comparator.
I get back the set of files that are OLDER than the buildfile. I delete them.
The reason I use a fileset for the sources and not just a list of files is for convenience.
- you might have a whole directory of buildfiles, sub-buildfiles, included buildfiles, etc.
- you might have a set of included XSLT "common" transformers
- you might have a whole directory of DTD files
- etc.
Using FileSets enables you to easily account for all of these in a single invocation of <dependset>.
In fact, this just about sums up our own build environment :-)
***********************
A real issue is what to do when one or more SOURCES (not targets) doesn't exist? In the example above, that would mean that a buildfile does not exist. This is not so preposterous when you realize that I might be generating
my buildfile using XSLT or whatnot.
This is where I believe you need a choice: to ignore or not to ignore.
NOT IGNORE: Sometimes you want this situation to be interpreted as though ALL target files
are out of date. For example, there is some intermediate file (copyright notice?) that has not been
generated yet but needs to be incorporated in all target files-- so kill em all...
IGNORE: Other times you might want this situation to be interpreted as if the target files
are NOT out of date. For example, you might have a boilerplate <dependset> rule that includes
"*.dtd". But one of your projects does not yet happen to have any DTD files. Setting ignore=true means
that this will not result in any target files being removed.
Therefore, I chose to parameterize SourceFileScanner's comparison algorithm. By default it works as before, but you can invert it by choosing a different FileComparator a la Strategy pattern.
Even though you wouldn't need it if you followed my route, I think this is a useful extension and a better approach than subclassing IMHO. We may need to compare other things than timestamps in the future ...
agreed
You will notice that I also had to enhance MergingMapper slightly to accomodate multiple files.
Here I may have created a new Mapper type instead, but it works for me both ways.
agreed. Does anyone in ant-dev land have a strong opinion about this?
Stefan
Craeg
