ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Ant 2.0 Consideration
Date Thu, 14 Dec 2000 17:05:19 GMT
At 10:50  14/12/00 -0500, James Cook wrote:
>In order for Ant to be integrated to the point that I am hoping, it will be
>necessary for several things to change in the Ant design.
>1. A two-way Java class structure including Projects, Targets and Tasks. I
>that there is a move towards this in Anteater. This approach IMHO is much
>than exposing the DOM and using that as a read/write source. There is too
>opportunity for ambiguity between DOM and the resulting Tasks.

Neither proposal will allow you to directly manipulate task instances atm
for good reason. They both handle it through an abstract - mymidon does it
via condifuration objects while AntEater does it through nested hashtables
(I assume as it is not done fully yet).

>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
>of MatchingTask as well. It seems that File discovery can be achieved in two
>very different manners.

this is largely due to the fact that ant evolved rather than designed with
all this in mind from the start. Fileset is actually an evolution of
MatchingTask as it was found matching task was not sufficiently flexable
for all uses. MatchingTask will likely be removed in Ant2 I suspect to and
all handling of filesets handled via filesets and mappers. Thou it is
really too early to tell atm ;)

>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
>by the Task. 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. Perhaps, a solution is to
>Tasks to implement an isIncluded(File[])/isExcluded(File[]) method.

I am not sure if this is advisable for all tasks - or even most tasks. I
think that the only way around this is careful crafting of ant files and
interaction between IDEs etc. The reason is that a simple check can only
occur after scanning and scanning usually occurs during execution. While
this could be moved outside it would involve a considerable rearchitecture
of a large number of tasks and it still wouldn't be acceptable performance
in some IDEs. Say you have a project with 200 files will you roll through
each one individually checking them? Even for tasks like timestamp or
things like CVS where it is impossible to check if a file is effected ?

>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[]).

I see this as a no-go for same reasons as 3. I suspect what you are wanting
to do is use the tasks that ant defines directly instead of indirectly
through ant. Which I think should be possible and we should be able to do
it with some standard interface. There was talk of using full beanized
interfaces but that has yet to be resolved.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message