ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: [PATCH] Script enhancement to standardize the "project" object exposed
Date Sun, 30 Sep 2001 03:25:01 GMT

> No task should be accessing it's containing target IMO and considering
> stdout is redirected to task at this stage what is wrong with using
> (or whatever the builtin javascript method is). ie

The <script> task seems to be designed for ad hoc task creation, so why
shouldn't it act just like being in the execute() method and have the same

JavaScript does not itself have a way to print that I know of - it relies on
provided objects to do so ('alert' in web browsers to pop up a dialog box).
I believe (and please correct me if I'm wrong) that to do a
System.out.println from JavaScript you'd have to get a handle to the System

> As I don't like tasks accessing their target, I still can't see a need for
> reference to the task.

But you're arguing against capability that already exists, just in a more
obtuse way.   Tasks, Targets, Project, and Properties are all accessible
already, just not cleanly.   All I'm asking for is a known name to access
the enclosing task.

> Not really ;) IMHO the script tasks should only have access to the
> bare minimum required for functionality and usability.

What functionality do you see <script> providing?    I view it as a way to
write a Task without having to create a Java class, compile it, and
<taskdef> it.   I view it simply as the implementation of the execute()
method of Task, and in that light I think it should be able to have clean
access to the Task object.

Others probably have a view of it creating other Tasks, and other more
esoteric things.   But the capability to get crazy with <script> already
exists, I just am arguing for it to be execute().

> > I don't quite see what would be so bad about this change and
> > how that too tightly couples things.
> because it makes it easier to get to task object - not something I
> deem as necessaary or wanted ;)

But again, the capability to get carried away with <script> already exists
in a much bigger way than I'm lobbying for.

> > Suppose someone creates generic
> > <script>'s in a common file that gets entity-reference included in other
> > build.xml's that all have different project names?   That was the heart
> > the issue that brought on this change.
> I agree with that ;) A single value for current project makes sense. I
> agree that it would have been nicer if no properties were added into
> BSF scope/context/whatever it is called. However I don't agree that you
> access to task object and nor do I see value in giving access to target.

The same argument applies to the Task though, and that was my point.  Task
makes even more sense to me than Project.  <script> *is* a task.   It is
simply the implementation of execute().   Shouldn't it enjoy the same
privileges that a Java Task enjoys with easy member access?   Shouldn't we
just view the <script> code as execute()?

I've never seen so much discussion over one line of code before!  :)


View raw message