ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Ant 2.0 Consideration
Date Thu, 14 Dec 2000 16:45:52 GMT
James Cook <> wrote:

> 2. Consistent support for how a Task handles File discovery needs to
> be enforced. The MatchingTask is a big step forward in this process,
> but not all Tasks use it. I may be wrong, but the Fileset concept
> seems to fly in the face of MatchingTask as well. It seems that File
> discovery can be achieved in two very different manners.

MatchingTask has been there first. If you look at the implementation
you'll see that MatchingTask holds an implicit FileSet and delegates
all work to this FileSet.

MatchingTask is good for all task that want to restrict themselves to
a single source/base/whatever - directory. Tasks that can handle more
than one directory at once gain a lot of power by using FileSets. The
second benefit of FileSets is that you can refer to sets defined
elsewhere, this lets you make changes at a single point instead of
repeating them.

MatchingTask has mainly been kept for backwards compatibility.

> 3. The reason I think File discovery is so important comes back to
> the fact that these IDEs utilitize a package/file structure. In
> order for Ant to be fully integrated, I need to be able to ask each
> Task if a particular file is affected by the Task.

How would this apply to echo/sql/property ...?

> For example, given a particular File object, I should be able to ask
> a Copy Task if it will include this task.  Since the Copy Task does
> not extend MatchingTask, this becomes impossible.

Why? Or better, why would this be possible if Copy extended

> Perhaps, a solution is to require Tasks to implement an
> isIncluded(File[])/isExcluded(File[]) method.

This would certainly be possible for all tasks that use FileSets -
either explicit or implicit. Given that most task include files not
only based on their name and some patterns but also on timestamp
comparisons, this could lead to a lot of scanning for files on the
disk, but it sure would be possible.

I'm not sure what one would gain with it though - but I'm not an IDE
user myself. A coworker is using Dirk Bogdol's JBuilder integration
quite successfully right now, but he's using a buildfile of mine, not
one put together using an UI.

Could you please expand a little on how an IDE would benefit if it
knew whether a given task in a given buildfile would actually affect a
given file?

> 4. The converse of #3 would be the ability for a given Task object
> to include or exclude a specific file. This capability can be
> supported by the methods doInclude(File[]) or doExclude(File[]).

Don't think so. The current mechanisms to specify includes/excludes
are lot more powerful than that.


View raw message