ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: Ant 2.0 Consideration
Date Fri, 15 Dec 2000 20:55:02 GMT
> From: James Cook []
> > -----Original Message-----
> > From: Stefan Bodewig []
> > > 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 ...?
> Tasks that do not deal with Filesets would return false when 
> asked about a
> particular file.
> > > 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
> > MatchingTask?
> Because MatchingTask (or FileSet) can (or could) answer the 
> question, "Is
> this file included/excluded from your scope?"

How do you know such task is required for the build? Are you planning to do
the dependency analysis before running ANT to know which targets
will be actually used? How are you planning to dealt with
dependencies that only appear as a result of the action of other tasks?
Foe example: <update> which may set a property if the file needs updating
and that may trigger certain <target> to get called or not.

How about <ant> or <antcall>?

> > 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?
> Ant works on a concept of projects/targets/tasks, while a 
> Java IDE manages
> files based on projects/packages/files. While it is possible 
> to stick Ant
> directly into an IDE and have the person work against the Ant 
> build script
> directly, this breaks the IDE's paradigm. It would be akin to sticking
> Antidote directly in the IDE. It would work, but it would 
> never be truly
> integrated.
> I envision a system where the developer can assign a task at 
> a high level,
> perhaps the project or package level. Then the developer can 
> select which
> files will participate in the task. Maybe when a file is 
> selected, it is
> shown all of the tasks that have been declared "above" it. 
> The developer
> could then check off which tasks that file will or won't 
> participate in. The
> methods that I mentioned previously would help faciliate 
> keeping track of
> which tasks a particular file is participating in.

Well this certaintly looks like an entire different insect,
based on ANT (I grant you that) :-) Perhaps, termite is a good name.

But seriously, IMHO for ANT to be ANT, whatever we define as a build
using some build building tools (e.g., IDE) needs to be representable
as a proper ANT file, that can be exported and used by others not 
using such an IDE. Otherwise, the whole point of portable builds is lost.

Now as for your problem, I think that you are looking at the problem
in the wrong direction. Intead of the IDE asking ANT what it may be
interested in, I could see ANT asking the IDE about files it needs to know
during execution. So rather than MatchingTask or FileSet going to the
disk, or using directly, we should have a registration
that allows the IDE to intercept this questions and respond appropriately.

This can be done by registering a factory that is used by the ProjectHelper
to create these new File objects and those objects will do the right thing 
with respect to IDEs or something else.

Maybe something to consider,

Jose Alberto

> jim

View raw message