ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: Ant Principles
Date Fri, 21 Apr 2000 02:02:25 GMT
> If an object implementing some task can use other objects, we do not  need
> to split the function part and the beans/reflectable part of tasks into two
> objects. Today this is not possible, because task A using task B cannot set
> the project variable,  as it is private. 

In what I've proposed, the properties are a mutable list on the Project
object. This means that all tasks should have access to that list and
can change them. This would allow task A to affect something that task B
does later.

> To allow reuse, either split the
> task object into one implementing the functionality and one that gets
> reflected in and uses the other - OR allow tasks instantiate other task (and
> setting the project instance variable). If the second is preferabkle to the
> first, make it a general principal, that a task being executed may either be
> reflected in or created by another task, which was reflected in.

So, of either of these two options (if I'm reading correctly), the
latter one is more clear to me. All it would take is allowing the Tasks
to look at the list of projects in the currently executing target and
modify that list.

The question is do we really need that much flexibility? I'd think that
at first being able to convey information via the project props would be
enough. 

> Arrgh. I deeply regret not having written "URL object as INTERNAL
> representation of resources" - meaning objects (being either tasks or
> "functional" objects) dealing with resources, should use an URL
> representation, whenever possible. Objects manipulating resources should use
> InputStream and OutputStream for their interfaces. To allow good reuse.

Ah. Ok. So you're saying the canonical representation of resources
internally should be URL objects. The problem with this is that Files
have a richer set of functionality than do URLs, including now the
ability to set read only flags and a whole slew of useful things in
build development. 

The other negative I see with using URLs is that at least the major base
tool that we deal with (javac) can only be used with Files and not with
Streams. The new compiler in JDK 1.3 might have a private com.sun.*
interface for dealing with Streams (I haven't examined it in detail),
but that's 1.3 and given that at least one project contributor is
against moving to 1.2, 1.3 functionality is asking too much.

In a perfect world, a Streams based approach would be nice, but I'm not
sure that we can make that jump yet.

.duncan



Mime
View raw message