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 Sat, 29 Sep 2001 05:10:57 GMT
> On Sat, 29 Sep 2001 01:36, Erik Hatcher wrote:
> > The reason would be so that <script> can be used to write "ad hoc" Tasks
> > more easily and get directly at its Task instance rather than going
> > a roundabout way of hardcoding in an arbitrary reference name.
> You still haven't answered my question ;) What advantage is it to give
> to this object. What features does this add to script writers arsenal?
> methods/data does it give access to that you need and otherwise would want
> be available?

Peter -
The advantage is that it allows <script> code to work more seamlessly like a
real Task does.   It more cleanly has access to "itself" without having to
go through a level of indirection by knowing its own 'id' value.

> Tighter coupling makes it more difficult for the ant core to evolve in
> future. It also adds more complexity than is needed - especially as I
> know what possible advantage allowing such access gives ;)

The advantage is cleanliness and just seems like the right thing to do.
Here is a concrete example of the differences between having 'self' and not
having it.

<project name="TestProj" default="test1">
  <property name="xyz" value="123"/>
  <property name="" value="???"/>
  <target name="test1">
    <script language="javascript"> <![CDATA[
    ]]> </script>

  <target name="test2">
    <script language="javascript" id="scriptTask"> <![CDATA[
      scriptTask.log("xyz = " + xyz);
      //scriptTask.log(" = " +;
      for (i in this) {
        scriptTask.log(i + " = " + this[i]);
      scriptTask.log(" = " +
    ]]> </script>

Target "test1" takes advantage of the "self" modification [beans.add("self",
this)].  Target "test2" does it the old-fashioned way, where it has to know
its own "id" in order to access itself as a Task.   I mainly view <script>
as a way to prototype tasks or do them in a more ad hoc way than writing a
Java class.   There are other questionable uses like having it control other
tasks and targets which I don't really see much need for personally.   In
target "test2", the "project" object is used - just for demonstration
purposes.   Also, an Ant property is displayed, followed by all the objects
exposed to the script, and then an example of getting properties that get
skipped by addBeans.  Here is the output of running both targets:

Buildfile: test.xml

   [script] test1

Overriding previous definition of reference to scriptTask
   [script] test2
   [script] xyz = 123
   [script] TestProj
   [script] project =
   [script] scriptTask =
   [script] TestProj =
   [script] xyz = 123
   [script] basedir = C:\jakarta\jakarta-ant
   [script] self =
   [script] bsf =
   [script] test1 = test1
   [script] test2 = test2
   [script] = ???


Total time: 1 second

Its almost useless to have the the Ant properties added for direct access.
As you can see I had to comment out the line to get the
directly because its illegal JavaScript syntax, and most of us use dotted
properties.   The addBeans method skips objects (references, properties, and
targets) that have illegal Java identifier names - so its really wisest to
use project.getProperty to get at properties.   I'm almost of the opinion
that the <script> task should *only* expose "self" and let the user navigate
to other objects (including "project") through methods and members defined
on Task.   That would seem to fit in better with your goals, wouldn't it
Peter?   I'm sure some folks use <script> to do some wild and crazy
flow-control and iterations over other targets and tasks.  But in the spirit
of backwards compatibility I'm fine with leaving it as-is with the addition
of "self".   Peter, I see you already committed the "project" patch, but I'd
like to also see the attached patch committed with the "self" addition - I
hope you can see it in your heart to allow this through!  :)   I don't quite
see what would be so bad about this change and how that too tightly couples
things.   <script> is a Task, I just want it to be able to work like one
easily.  :)   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 of the issue that brought on
this change.


View raw message