ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: Ant 2.0 Consideration
Date Mon, 18 Dec 2000 04:08:15 GMT
On 12/14/00 7:50 AM, "James Cook" <jimcook@iname.com> wrote:

> Most IDE's in use by developers display packages, source files, and support
> files such as jsp, html, properties, gif, jpg, etc.  There are some exciting
> possibilities that can be achieved via Ant integration on these projects.
> However, because of the package/file metaphor used by these products, it
> clashes with Ant's task-based metaphor. Note that this clash doesn't preclude
> Ant integration, but it forces the developer into working with Ant instead of
> working with his/her files. Many power users won't care about this, but it can
> be a deterrent to more junior developers.

It is a bummer that people are forced to work with Ant instead of just the
files in their project. But it doesn't have to be that way. I hope that the
IDE integrations that are possible with NetBeans and others will go a bit
further and treat their view of the source files inside of ant in their
native way while calling builds through Ants mechanism.

> Most IDE's will automatically compile all Java source files added to a
> project. Likewise, some will copy certain nodes (.properties, .gif) to an
> output directory automatically. Some IDE's allow the developer to invoke pre-
> or post-processing functions on a particular file. Ant already has more
> support (and definitely more flexibility) for supporting these additional
> tasks than any IDE on the market.

Right. Almost every IDE on the planet (at least the ones that I've tried)
fall flat on their face in this respect.

> 1. A two-way Java class structure including Projects, Targets and Tasks. I
> think that there is a move towards this in Anteater. This approach IMHO is
> much better than exposing the DOM and using that as a read/write source. There
> is too much opportunity for ambiguity between DOM and the resulting Tasks.

Yep. This is exactly what is being done in AntEater -- for exactly these
reasons.

> 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.

File resolution/discovery *needs* to be a service that Ant provides to tasks
(and to IDEs that interface with Ant). It's not optimal at all for tasks to
have to implement that logic themselves. This is something that I've been
hacking on a bit. Some checkins in a few days along these lines (assuming
that I get over the bug that's got me wanting to stay in bed all day! :)

.duncan

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Mime
View raw message