ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] Script enhancement to standardize the "project" object exposed
Date Sun, 30 Sep 2001 02:27:27 GMT
On Sat, 29 Sep 2001 15:10, Erik Hatcher wrote:
> 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.

Thats the same thing you said before - still doesn't tell me what I needed to 
know ;)

> 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[
>       self.log(self.owningTarget.getName());

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

   <target name="test1">
     <script language="javascript"> <![CDATA[
       print ( "some string" );
     ]]> </script>

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

> Its almost useless to have the the Ant properties added for direct access.

I agree ;)

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

which is why project should be exported ;) also because it allows creation of 
other tasks.

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

Not really ;) IMHO the script tasks should only have access to the absolute 
bare minimum required for functionality and usability. self.log() is not 
needed as stdout gets redirected to logging anyways and I don't like the idea 
of task accessing it's target. Hence you haven't really demonstrated anything 
that I see as needed.

However I guess it would be nice if an easier adaptor log object was added to 
context so you could do something like

   <target name="test1">
     <script language="javascript"> <![CDATA[
       logger.debug( "some debug message" ); "some info message" );
       logger.error( "some info message" );
     ]]> </script>

however I haven't had to use BSF yet so ... ;)

When Ant2 arrives the script task will hopefully only have acccess to to the 
TaskContext and zero other objects (unless we want to make it easier for 
usability to access property values in different scopes but thats 
another thing altogether).

> 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 ;)

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

I agree with that ;) A single value for current project makes sense. I also 
agree that it would have been nicer if no properties were added into inital 
BSF scope/context/whatever it is called. However I don't agree that you need 
access to task object and nor do I see value in giving access to target.



| "Common sense is the collection of prejudices        |
|  acquired by age 18. " -Albert Einstein              |

View raw message