You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Phil Surette <ph...@home.com> on 2001/09/28 10:13:54 UTC
Re: [PATCH] Script enhancement to standardize the "project" object
exposed
What about adding in the target as well, e.g. something like:
addBeans(project.getTargets());
addBeans(project.getReferences());
beans.put("project", getProject());
+ beans.put("target", getOwningTarget());
+
BSFManager manager = new BSFManager ();
When I first started using the script tag a couple of weeks ago
I just naturally expected to see both the target and the
project predefined in all scripts. They are the context for the
script. Having access to the grandparent (project) - while a
_big_ improvement - without access to the parent (target)
just seems wrong somehow.
(yes, you can get at the target if you know its name, but this
is just as inelegant as needing to know the project name: it creates
an easily broken dependency between the task name and the embedded
script and a real trap for all those cut-and-pasters out there)
Erik Hatcher wrote:
>
> Well, with a +1000000, I couldn't resist making the change I proposed. :)
>
> Attached is a patch against the ANT_14 versions of Script.java and the
> documentation file for this task.
>
> Here is the sample build file that I used to test my change with:
>
> <project default="test">
> <target name="test">
> <script language="javascript"> <![CDATA[
> echo = project.createTask("echo");
> main.addTask(echo);
> for (i=1; i<=10; i++) {
> echo.setMessage(i*i);
> echo.execute();
> }
> ]]> </script>
> </target>
>
> <target name="main"/>
> </project>
>
> ----- Original Message -----
> From: "Peter Donald" <do...@apache.org>
> To: <an...@jakarta.apache.org>
> Sent: Thursday, September 27, 2001 5:01 PM
> Subject: Re: Javascript errors
>
> > On Fri, 28 Sep 2001 05:06, Erik Hatcher wrote:
> > > This problem actually could be alleviated with a patch to the <script>
> task
> > > such that the project reference was fed to BSF with the name "project"
> > > rather than as the name of the project. I've got a few such similar
> > > patches on my to-do list for the <script> task to make using it easier.
> I
> > > won't have time to get to this patch very soon though, but it appears to
> be
> > > a straightforward change.
> >
> > +1000000 ;)
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > When a stupid man is doing something he's ashamed of, he always
> > declares that it is his duty.
> > George Bernard Shaw
> >
>
> ------------------------------------------------------------------------
> Name: patchfile.txt
> patchfile.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Just a couple of quick comments:
- 'this' does not work as that is a pre-defined BSF name, 'this' contains
members of all the objects that Script.java places within its context (so it
will contain 'self', and all the other references and properties that have
legal Java identifiers). 'self' is the name I've submitted.
- Thanks for the example where the Task reference comes in handy.
Erik
----- Original Message -----
From: "Phil Surette" <ph...@home.com>
To: <an...@jakarta.apache.org>
Sent: Sunday, September 30, 2001 4:47 PM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed
> Wow! Step away from my computer for a couple of days and I see
> my suggestion has borne strange fruit!
>
> I'm new to this list so I guess my vote doesn't count, but I'd
> give a +1 to the 'self' addition if I could... though I think
> Erik said that 'self' did not work. I prefer 'script' to
> 'thisScript' since long, verbose names are not very
> scripty.
>
> The addition of 'project' is a great improvement over the
> current state of affairs. I'm glad that got through.
> Ideally I'd like to see 'project' and 'this' both, since
> it is the 'project' object you will be working with most of
> the time, and once again having to type script.project
> all over the place is not very scripty.
>
> I don't think backward compatibility of scripts is a huge
> issue. Scripts will be as backward compatible as regular
> tasks. If you don't want people creating dependencies
> on the Ant API, you shouldn't publish the API in the
> distribution ;)
>
> Finally, here's a possible valid reason why scripts should be able
> to access their task (easily, since they can do it awkwardly already):
> BuildExceptions. When a script wants to throw a BuildException,
> it should be using the BuildException constructor that
> takes a Task argument.
>
Re: [PATCH] Script enhancement to standardize the "project" object
exposed
Posted by Phil Surette <ph...@home.com>.
Wow! Step away from my computer for a couple of days and I see
my suggestion has borne strange fruit!
I'm new to this list so I guess my vote doesn't count, but I'd
give a +1 to the 'self' addition if I could... though I think
Erik said that 'self' did not work. I prefer 'script' to
'thisScript' since long, verbose names are not very
scripty.
The addition of 'project' is a great improvement over the
current state of affairs. I'm glad that got through.
Ideally I'd like to see 'project' and 'this' both, since
it is the 'project' object you will be working with most of
the time, and once again having to type script.project
all over the place is not very scripty.
I don't think backward compatibility of scripts is a huge
issue. Scripts will be as backward compatible as regular
tasks. If you don't want people creating dependencies
on the Ant API, you shouldn't publish the API in the
distribution ;)
Finally, here's a possible valid reason why scripts should be able
to access their task (easily, since they can do it awkwardly already):
BuildExceptions. When a script wants to throw a BuildException,
it should be using the BuildException constructor that
takes a Task argument.
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
On Sun, 30 Sep 2001 16:40, Erik Hatcher wrote:
> The first sentence of the Ant2 goals begins like this: "Even though Ant2
> is expected to be incompatible with the current Ant1 series...". And then
> later: "Tasks written for Ant1 won't work in Ant2 as the API of Ant's core
> and the names of utility classes are going to change."
>
> So why worry about <script> breaking builds?
Because the percentage of users who write tasks is small compared to those
who use ant. <script/> is more in "user" land rather than "developer" land. I
am not sure how widely used it is (I don't use it any of my build files) so I
guess
> Anyone upgrading from 1.x to
> 2.0 will have many other issues to contend with (most likely) than
> <script>, no? And any tool that is developed to convert Ant 1.x
> build.xml files to Ant 2.0 format could warn the user when it encounters
> <script> that there are likely to be issues with that task, and there are
> likely to be other similar scenarios of a conversion.
Hopefully the conversion will be automatable for all of stuff that ant-dev
maintains. It will make "best effort" attempts at unknown tasks. So I guess
the "unknown" tasks will require warnings so I guess more warnings for
ant-dev maintained stuff is maybe OK.
> I truly understand what you are saying about exposing Task (or other
> internal objects) to script code and how internal code changes could break
> such code. But I don't agree that its a bad thing. Anyone using
> <script> should know they are playing with fire and risk incompatibilities
> in future releases.... but a 1.x release won't change Task, do you think?
> Exposing "self" to <script> is not going to open the floodgates to folks
> all of a sudden writing tasks in this manner, and wacky insane things could
> be done with <script> already.
I don't know about that. I remember that adding some features to other tasks
ended up in lots of people using them in short order (if/unless attributes of
<target/> remind me of this as does zipfileset). I know of lots of people who
have wanted to use script like functionality but never had because it is a
pain to install. Not sure if that will change though ;)
BTW Sam whats the status of BSF -> Apache move?
> I'm done lobbying for this though - its really a matter of principle to me
> as I'm not architecting build scripts that use <script>. I'm happy that
> "project" got added, and would be much happier if "self" also got added.
> Sam gave a +1. I'm not sure of the politics involved at the committer
> level, but does that constitute a vote on that change where other
> committers are asked to weigh in on it?
Well one -1 is enough to block it but consider my -1 upgraded to -0 so you
may have convinced some other committer to do it ;)
--
Cheers,
Pete
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Saturday, September 29, 2001 9:04 PM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed
> On Sun, 30 Sep 2001 13:25, Erik Hatcher wrote:
> > 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
> > capabilities?
>
> Who saids it shouldn't?
You are! :) By keeping a level of indirection between the script code
and the Task object it prevents standard access to the facilities available
to a Task. It also prevents code reuse by having to hard-code task
references to the task id.
Granted, there is not much to a Task that <script> would need direct access
to that a Project doesn't provide (for example, the log methods are
available on Project also). I would characterize my stance more on
principle than technical reasons. <script> code is a Task's execute
implementation, and should really only have access to the Task instance -
and getting the Project reference from that is trivial.
> Hmmm - I thought you could access java objects directly in BSF. Something
> like prefixing it with "java." or similar. Not sure. If not then feel free
to
> send a patch that places a reasonable adaptor object that looks like
Yes, and Sam showed us how (duh!). Logging isn't really the main thing I
envisioned a Task doing, that was just a simplistic example I provided.
Sam provided nice examples of the use of the <script> task - and yes those
examples only needed Project. And now that "project" has been added, the
"openjms" could be changed and those script sections could be externalized
and reused in other build scripts easily (many thanks for committing that
patch already Peter).
> I like that it is obtuse because that means less people will use it and
thus
> less people will complain when we break compatability with ant2.
The first sentence of the Ant2 goals begins like this: "Even though Ant2 is
expected to be incompatible with the current Ant1 series...". And then
later: "Tasks written for Ant1 won't work in Ant2 as the API of Ant's core
and the names of utility classes are going to change."
So why worry about <script> breaking builds? Anyone upgrading from 1.x to
2.0 will have many other issues to contend with (most likely) than <script>,
no? And any tool that is developed to convert Ant 1.x build.xml files to
Ant 2.0 format could warn the user when it encounters <script> that there
are likely to be issues with that task, and there are likely to be other
similar scenarios of a conversion.
> > 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.
>
> Doing this would mean that we are guarenteeing that we break compatability
> with future iterations of ant. Do you see this as a good thing?
<script> is not by any stretch of the imagination a major player in build
scripts. I would only use it (and I haven't used it in any production
builds, only for demonstration purposes anyway! :) to prototype a task or do
simple things like Sam's examples of incrementing a build number or
replacing characters in a string. Compatibility will only be broken when
the Task contract changes - and that will cause major ripples throughout
other Java-based tasks as well, so breaking <script> backwards compatibility
at that point is perfectly reasonable to me.
> Some functionality would benefit to be added for usability sake. However
this
> is not the thing I dislike - It is binding to implementation specific
objects
> that will mandate that we break compatability in future that seems kinda
> foolish to me. Sure it is already accessible but it is obtuse enough that
> most people will not use it and thus it will be easier for use to support
in
> future.
I truly understand what you are saying about exposing Task (or other
internal objects) to script code and how internal code changes could break
such code. But I don't agree that its a bad thing. Anyone using <script>
should know they are playing with fire and risk incompatibilities in future
releases.... but a 1.x release won't change Task, do you think? Exposing
"self" to <script> is not going to open the floodgates to folks all of a
sudden writing tasks in this manner, and wacky insane things could be done
with <script> already.
I'm done lobbying for this though - its really a matter of principle to me
as I'm not architecting build scripts that use <script>. I'm happy that
"project" got added, and would be much happier if "self" also got added.
Sam gave a +1. I'm not sure of the politics involved at the committer
level, but does that constitute a vote on that change where other committers
are asked to weigh in on it?
Erik
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
On Sun, 30 Sep 2001 13:25, Erik Hatcher wrote:
> 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
> capabilities?
Who saids it shouldn't?
> 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
> object.
Hmmm - I thought you could access java objects directly in BSF. Something
like prefixing it with "java." or similar. Not sure. If not then feel free to
send a patch that places a reasonable adaptor object that looks like
class Logger
{
debug(message)
info(message)
error(message)
}
etc.
Any other reasonable abstractions will also be considered if you need access
to other things.
> 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.
I like that it is obtuse because that means less people will use it and thus
less people will complain when we break compatability with ant2.
> 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.
Doing this would mean that we are guarenteeing that we break compatability
with future iterations of ant. Do you see this as a good thing?
> 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()?
Some functionality would benefit to be added for usability sake. However this
is not the thing I dislike - It is binding to implementation specific objects
that will mandate that we break compatability in future that seems kinda
foolish to me. Sure it is already accessible but it is obtuse enough that
most people will not use it and thus it will be easier for use to support in
future.
> I've never seen so much discussion over one line of code before! :)
The line of code is almost irrelevent - it is the concept. Should we be
making changes to ant now that will make it easier to write build files that
will break in the future?
--
Cheers,
Pete
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Peter,
> 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
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
capabilities?
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
object.
> As I don't like tasks accessing their target, I still can't see a need for
a
> 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
absolute
> 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
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.
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! :)
Erik
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
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="dotted.property" 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>
</target>
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 dotted.property
> 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" );
logger.info( "some info message" );
logger.error( "some info message" );
]]> </script>
</target>
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.
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
> 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
through
> > a roundabout way of hardcoding in an arbitrary reference name.
>
> You still haven't answered my question ;) What advantage is it to give
access
> to this object. What features does this add to script writers arsenal?
What
> methods/data does it give access to that you need and otherwise would want
to
> 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
don't
> 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="dotted.property" value="???"/>
<target name="test1">
<script language="javascript"> <![CDATA[
self.log(self.owningTarget.getName());
]]> </script>
</target>
<target name="test2">
<script language="javascript" id="scriptTask"> <![CDATA[
scriptTask.log(scriptTask.owningTarget.getName());
scriptTask.log("xyz = " + xyz);
//scriptTask.log("dotted.property = " + dotted.property);
scriptTask.log(project.getName());
for (i in this) {
scriptTask.log(i + " = " + this[i]);
}
scriptTask.log("dotted.property = " +
project.getProperty("dotted.property"));
]]> </script>
</target>
</project>
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
test1:
[script] test1
test2:
Overriding previous definition of reference to scriptTask
[script] test2
[script] xyz = 123
[script] TestProj
[script] project = org.apache.tools.ant.Project@3753f8
[script] scriptTask =
org.apache.tools.ant.taskdefs.optional.Script@63b895
[script] TestProj = org.apache.tools.ant.Project@3753f8
[script] xyz = 123
[script] basedir = C:\jakarta\jakarta-ant
[script] self = org.apache.tools.ant.taskdefs.optional.Script@63b895
[script] bsf = com.ibm.bsf.util.BSFFunctions@31aa65
[script] test1 = test1
[script] test2 = test2
[script] dotted.property = ???
BUILD SUCCESSFUL
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 dotted.property
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.
Thanks,
Erik
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
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 through
> a roundabout way of hardcoding in an arbitrary reference name.
You still haven't answered my question ;) What advantage is it to give access
to this object. What features does this add to script writers arsenal? What
methods/data does it give access to that you need and otherwise would want to
be available?
> What problems do you see with allowing uniformly named access to the Task
> instance given that it could already be reached in a more obtuse way?
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 don't
know what possible advantage allowing such access gives ;)
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Friday, September 28, 2001 8:08 AM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed
> What is the reason for allowing script access to itself and it's target?
What
> value does it add? Access to project is required because currently you
need
> it to create tasks and uniformlly access properties.
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 through
a roundabout way of hardcoding in an arbitrary reference name.
You don't need Project access to get at properties - they are added as well
as references.
What problems do you see with allowing uniformly named access to the Task
instance given that it could already be reached in a more obtuse way?
Erik
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
On Fri, 28 Sep 2001 18:08, Stefan Bodewig wrote:
> On Fri, 28 Sep 2001, Erik Hatcher <ja...@ehatchersolutions.com>
>
> wrote:
> > I modified it to be "me", like below:
> >
> > beans.put("me", this);
>
> How about "self"?
I like self but ...
> I'm not sure whether the other committers will agree that adding
> references to the current target and the task itself. It is fine with
> me, but given that Pete vetoes adding a property with the name of the
> current target, it seems likely he wouldn't enjoy these changes
> either.
yep - I don't like it ;)
What is the reason for allowing script access to itself and it's target? What
value does it add? Access to project is required because currently you need
it to create tasks and uniformlly access properties.
--
Cheers,
Pete
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Peter Donald <do...@apache.org>.
On Fri, 28 Sep 2001 23:45, Erik Hatcher wrote:
> Pete already gave a resounding +100000 to making the Project object
> accessible.
A slight correction. Pete gave a +10000 to standardizing on the name to use
to acces project and thus removing all need for the most ugly project name
attribute ;)
--
Cheers,
Pete
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
> How about "self"?
"self" has my vote!
> I'm not sure whether the other committers will agree that adding
> references to the current target and the task itself. It is fine with
> me, but given that Pete vetoes adding a property with the name of the
> current target, it seems likely he wouldn't enjoy these changes
> either.
Code within <script> already has access to all references and properties, so
it could already get to its own task instance if it wanted. The purpose of
<script> is to allow "ad hoc" tasks to be created, so it seems that giving
cleaner access to the Task object would only help that purpose.
Pete already gave a resounding +100000 to making the Project object
accessible.
And yes to Jose's question about using self.project and self.owningTarget -
I had just left the getProject in there from past tests with my
modification.
Erik
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 28 Sep 2001, Erik Hatcher <ja...@ehatchersolutions.com>
wrote:
> I modified it to be "me", like below:
>
> beans.put("me", this);
How about "self"?
I'm not sure whether the other committers will agree that adding
references to the current target and the task itself. It is fine with
me, but given that Pete vetoes adding a property with the name of the
current target, it seems likely he wouldn't enjoy these changes
either.
Stefan
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
Taking a look at your script, shouldn't we be able to say:
me.project and me.owningTarget
no need to call the method invocation me.getProject(), etc.
With respect to the name, I would propose either "script" or "thisScript". What people think?
Jose Alberto
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: <an...@jakarta.apache.org>
Cc: <ph...@home.com>
Sent: Friday, September 28, 2001 8:47 AM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object exposed
> Actually I just tried "this" and it doesn't work.... it must be a special
> BSF auto-provided object which contains all the other objects that
> Script.java exposed (a "for each in" gave me that info).
>
> I modified it to be "me", like below:
>
> beans.put("me", this);
>
> and it all worked well. So anything other than "this" would be fine. What
> is the best choice? "me"? "task"? "thisTask"? Here is my example
> script now:
>
> <project default="test">
> <property name="xyz" value="123"/>
> <target name="test">
> <script language="javascript"> <![CDATA[
> proj = me.getProject();
> echo = proj.createTask("echo");
> main.addTask(echo);
> for (i in me) {
> echo.setMessage(i);
> echo.execute();
> }
> ]]> </script>
> </target>
> <target name="main"/>
> </project>
>
> I'm sure there is a better way to get output, but I'm just using the method
> shown in the documentation for now. The above outputs this which shows
> that "me" is a Task and has access to all the methods and member variables:
>
> [echo] getTaskName
> [echo] location
> [echo] taskName
> [echo] notifyAll
> [echo] runtimeConfigurableWrapper
> [echo] project
> [echo] setLocation
> [echo] setTaskName
> [echo] setProject
> [echo] getRuntimeConfigurableWrapper
> [echo] setSrc
> [echo] log
> [echo] execute
> [echo] setDescription
> [echo] addText
> [echo] getDescription
> [echo] equals
> [echo] notify
> [echo] class
> [echo] perform
> [echo] wait
> [echo] setOwningTarget
> [echo] toString
> [echo] hashCode
> [echo] description
> [echo] init
> [echo] setLanguage
> [echo] getProject
> [echo] maybeConfigure
> [echo] getOwningTarget
> [echo] getClass
> [echo] owningTarget
> [echo] getLocation
>
> I'll gladly submit an updated patch once we decide the best name for the
> task and if we want to expose the Project directly, although I'm inclined to
> only expose the Task and let the script get at the project reference if it
> wants. If a committer patches it, please make sure to modify the
> documentation patch to match the actual name chosen and to reflect that its
> a Task object now rather than a Project.
>
> Erik
>
> ----- Original Message -----
> From: "Erik Hatcher" <ja...@ehatchersolutions.com>
> To: "ant-dev" <an...@jakarta.apache.org>
> Cc: <ph...@home.com>
> Sent: Thursday, September 27, 2001 10:50 PM
> Subject: Re: [PATCH] Script enhancement to standardize the "project" object
> exposed
>
>
> > I'm all for "target" being added also. Actually if we just add "this"::
> >
> > beans.put("this", this);
> >
> > it would give access to the instance of the <script> task itself which
> could
> > then get the project and target directly using getProject and
> > getOwningTarget.
> >
> > Actually using "this" seems to be the cleanest short-term patch in order
> to
> > allow easy access to everything a custom task could access under a simple
> > pre-defined fixed name. I had thought of this change before, but didn't
> > remember that idea until you brought up the "target" suggestion.
> >
> > Could whoever commit this modify the Script.java change to the above?
> >
> > Thanks,
> > Erik
> >
> > ----- Original Message -----
> > From: "Phil Surette" <ph...@home.com>
> > To: <an...@jakarta.apache.org>
> > Cc: <an...@jakarta.apache.org>
> > Sent: Friday, September 28, 2001 1:13 AM
> > Subject: Re: [PATCH] Script enhancement to standardize the "project"
> object
> > exposed
> >
> >
> > > What about adding in the target as well, e.g. something like:
> > >
> > > addBeans(project.getTargets());
> > > addBeans(project.getReferences());
> > >
> > > beans.put("project", getProject());
> > >
> > > + beans.put("target", getOwningTarget());
> > > +
> > > BSFManager manager = new BSFManager ();
> > >
> > > When I first started using the script tag a couple of weeks ago
> > > I just naturally expected to see both the target and the
> > > project predefined in all scripts. They are the context for the
> > > script. Having access to the grandparent (project) - while a
> > > _big_ improvement - without access to the parent (target)
> > > just seems wrong somehow.
> > >
> > > (yes, you can get at the target if you know its name, but this
> > > is just as inelegant as needing to know the project name: it creates
> > > an easily broken dependency between the task name and the embedded
> > > script and a real trap for all those cut-and-pasters out there)
> > >
> > > Erik Hatcher wrote:
> > > >
> > > > Well, with a +1000000, I couldn't resist making the change I proposed.
> > :)
> > > >
> > > > Attached is a patch against the ANT_14 versions of Script.java and the
> > > > documentation file for this task.
> > > >
> > > > Here is the sample build file that I used to test my change with:
> > > >
> > > > <project default="test">
> > > > <target name="test">
> > > > <script language="javascript"> <![CDATA[
> > > > echo = project.createTask("echo");
> > > > main.addTask(echo);
> > > > for (i=1; i<=10; i++) {
> > > > echo.setMessage(i*i);
> > > > echo.execute();
> > > > }
> > > > ]]> </script>
> > > > </target>
> > > >
> > > > <target name="main"/>
> > > > </project>
> > > >
> > > > ----- Original Message -----
> > > > From: "Peter Donald" <do...@apache.org>
> > > > To: <an...@jakarta.apache.org>
> > > > Sent: Thursday, September 27, 2001 5:01 PM
> > > > Subject: Re: Javascript errors
> > > >
> > > > > On Fri, 28 Sep 2001 05:06, Erik Hatcher wrote:
> > > > > > This problem actually could be alleviated with a patch to the
> > <script>
> > > > task
> > > > > > such that the project reference was fed to BSF with the name
> > "project"
> > > > > > rather than as the name of the project. I've got a few such
> > similar
> > > > > > patches on my to-do list for the <script> task to make using it
> > easier.
> > > > I
> > > > > > won't have time to get to this patch very soon though, but it
> > appears to
> > > > be
> > > > > > a straightforward change.
> > > > >
> > > > > +1000000 ;)
> > > > >
> > > > > --
> > > > > Cheers,
> > > > >
> > > > > Pete
> > > > >
> > > > > When a stupid man is doing something he's ashamed of, he always
> > > > > declares that it is his duty.
> > > > > George Bernard Shaw
> > > > >
> > > >
> > >
> > ------------------------------------------------------------------------
> > > > Name: patchfile.txt
> > > > patchfile.txt Type: Plain Text (text/plain)
> > > > Encoding: quoted-printable
> > >
> >
> >
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Actually I just tried "this" and it doesn't work.... it must be a special
BSF auto-provided object which contains all the other objects that
Script.java exposed (a "for each in" gave me that info).
I modified it to be "me", like below:
beans.put("me", this);
and it all worked well. So anything other than "this" would be fine. What
is the best choice? "me"? "task"? "thisTask"? Here is my example
script now:
<project default="test">
<property name="xyz" value="123"/>
<target name="test">
<script language="javascript"> <![CDATA[
proj = me.getProject();
echo = proj.createTask("echo");
main.addTask(echo);
for (i in me) {
echo.setMessage(i);
echo.execute();
}
]]> </script>
</target>
<target name="main"/>
</project>
I'm sure there is a better way to get output, but I'm just using the method
shown in the documentation for now. The above outputs this which shows
that "me" is a Task and has access to all the methods and member variables:
[echo] getTaskName
[echo] location
[echo] taskName
[echo] notifyAll
[echo] runtimeConfigurableWrapper
[echo] project
[echo] setLocation
[echo] setTaskName
[echo] setProject
[echo] getRuntimeConfigurableWrapper
[echo] setSrc
[echo] log
[echo] execute
[echo] setDescription
[echo] addText
[echo] getDescription
[echo] equals
[echo] notify
[echo] class
[echo] perform
[echo] wait
[echo] setOwningTarget
[echo] toString
[echo] hashCode
[echo] description
[echo] init
[echo] setLanguage
[echo] getProject
[echo] maybeConfigure
[echo] getOwningTarget
[echo] getClass
[echo] owningTarget
[echo] getLocation
I'll gladly submit an updated patch once we decide the best name for the
task and if we want to expose the Project directly, although I'm inclined to
only expose the Task and let the script get at the project reference if it
wants. If a committer patches it, please make sure to modify the
documentation patch to match the actual name chosen and to reflect that its
a Task object now rather than a Project.
Erik
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: "ant-dev" <an...@jakarta.apache.org>
Cc: <ph...@home.com>
Sent: Thursday, September 27, 2001 10:50 PM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed
> I'm all for "target" being added also. Actually if we just add "this"::
>
> beans.put("this", this);
>
> it would give access to the instance of the <script> task itself which
could
> then get the project and target directly using getProject and
> getOwningTarget.
>
> Actually using "this" seems to be the cleanest short-term patch in order
to
> allow easy access to everything a custom task could access under a simple
> pre-defined fixed name. I had thought of this change before, but didn't
> remember that idea until you brought up the "target" suggestion.
>
> Could whoever commit this modify the Script.java change to the above?
>
> Thanks,
> Erik
>
> ----- Original Message -----
> From: "Phil Surette" <ph...@home.com>
> To: <an...@jakarta.apache.org>
> Cc: <an...@jakarta.apache.org>
> Sent: Friday, September 28, 2001 1:13 AM
> Subject: Re: [PATCH] Script enhancement to standardize the "project"
object
> exposed
>
>
> > What about adding in the target as well, e.g. something like:
> >
> > addBeans(project.getTargets());
> > addBeans(project.getReferences());
> >
> > beans.put("project", getProject());
> >
> > + beans.put("target", getOwningTarget());
> > +
> > BSFManager manager = new BSFManager ();
> >
> > When I first started using the script tag a couple of weeks ago
> > I just naturally expected to see both the target and the
> > project predefined in all scripts. They are the context for the
> > script. Having access to the grandparent (project) - while a
> > _big_ improvement - without access to the parent (target)
> > just seems wrong somehow.
> >
> > (yes, you can get at the target if you know its name, but this
> > is just as inelegant as needing to know the project name: it creates
> > an easily broken dependency between the task name and the embedded
> > script and a real trap for all those cut-and-pasters out there)
> >
> > Erik Hatcher wrote:
> > >
> > > Well, with a +1000000, I couldn't resist making the change I proposed.
> :)
> > >
> > > Attached is a patch against the ANT_14 versions of Script.java and the
> > > documentation file for this task.
> > >
> > > Here is the sample build file that I used to test my change with:
> > >
> > > <project default="test">
> > > <target name="test">
> > > <script language="javascript"> <![CDATA[
> > > echo = project.createTask("echo");
> > > main.addTask(echo);
> > > for (i=1; i<=10; i++) {
> > > echo.setMessage(i*i);
> > > echo.execute();
> > > }
> > > ]]> </script>
> > > </target>
> > >
> > > <target name="main"/>
> > > </project>
> > >
> > > ----- Original Message -----
> > > From: "Peter Donald" <do...@apache.org>
> > > To: <an...@jakarta.apache.org>
> > > Sent: Thursday, September 27, 2001 5:01 PM
> > > Subject: Re: Javascript errors
> > >
> > > > On Fri, 28 Sep 2001 05:06, Erik Hatcher wrote:
> > > > > This problem actually could be alleviated with a patch to the
> <script>
> > > task
> > > > > such that the project reference was fed to BSF with the name
> "project"
> > > > > rather than as the name of the project. I've got a few such
> similar
> > > > > patches on my to-do list for the <script> task to make using it
> easier.
> > > I
> > > > > won't have time to get to this patch very soon though, but it
> appears to
> > > be
> > > > > a straightforward change.
> > > >
> > > > +1000000 ;)
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Pete
> > > >
> > > > When a stupid man is doing something he's ashamed of, he always
> > > > declares that it is his duty.
> > > > George Bernard Shaw
> > > >
> > >
> >
> ------------------------------------------------------------------------
> > > Name: patchfile.txt
> > > patchfile.txt Type: Plain Text (text/plain)
> > > Encoding: quoted-printable
> >
>
>
Re: [PATCH] Script enhancement to standardize the "project" object exposed
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
I'm all for "target" being added also. Actually if we just add "this"::
beans.put("this", this);
it would give access to the instance of the <script> task itself which could
then get the project and target directly using getProject and
getOwningTarget.
Actually using "this" seems to be the cleanest short-term patch in order to
allow easy access to everything a custom task could access under a simple
pre-defined fixed name. I had thought of this change before, but didn't
remember that idea until you brought up the "target" suggestion.
Could whoever commit this modify the Script.java change to the above?
Thanks,
Erik
----- Original Message -----
From: "Phil Surette" <ph...@home.com>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Friday, September 28, 2001 1:13 AM
Subject: Re: [PATCH] Script enhancement to standardize the "project" object
exposed
> What about adding in the target as well, e.g. something like:
>
> addBeans(project.getTargets());
> addBeans(project.getReferences());
>
> beans.put("project", getProject());
>
> + beans.put("target", getOwningTarget());
> +
> BSFManager manager = new BSFManager ();
>
> When I first started using the script tag a couple of weeks ago
> I just naturally expected to see both the target and the
> project predefined in all scripts. They are the context for the
> script. Having access to the grandparent (project) - while a
> _big_ improvement - without access to the parent (target)
> just seems wrong somehow.
>
> (yes, you can get at the target if you know its name, but this
> is just as inelegant as needing to know the project name: it creates
> an easily broken dependency between the task name and the embedded
> script and a real trap for all those cut-and-pasters out there)
>
> Erik Hatcher wrote:
> >
> > Well, with a +1000000, I couldn't resist making the change I proposed.
:)
> >
> > Attached is a patch against the ANT_14 versions of Script.java and the
> > documentation file for this task.
> >
> > Here is the sample build file that I used to test my change with:
> >
> > <project default="test">
> > <target name="test">
> > <script language="javascript"> <![CDATA[
> > echo = project.createTask("echo");
> > main.addTask(echo);
> > for (i=1; i<=10; i++) {
> > echo.setMessage(i*i);
> > echo.execute();
> > }
> > ]]> </script>
> > </target>
> >
> > <target name="main"/>
> > </project>
> >
> > ----- Original Message -----
> > From: "Peter Donald" <do...@apache.org>
> > To: <an...@jakarta.apache.org>
> > Sent: Thursday, September 27, 2001 5:01 PM
> > Subject: Re: Javascript errors
> >
> > > On Fri, 28 Sep 2001 05:06, Erik Hatcher wrote:
> > > > This problem actually could be alleviated with a patch to the
<script>
> > task
> > > > such that the project reference was fed to BSF with the name
"project"
> > > > rather than as the name of the project. I've got a few such
similar
> > > > patches on my to-do list for the <script> task to make using it
easier.
> > I
> > > > won't have time to get to this patch very soon though, but it
appears to
> > be
> > > > a straightforward change.
> > >
> > > +1000000 ;)
> > >
> > > --
> > > Cheers,
> > >
> > > Pete
> > >
> > > When a stupid man is doing something he's ashamed of, he always
> > > declares that it is his duty.
> > > George Bernard Shaw
> > >
> >
>
------------------------------------------------------------------------
> > Name: patchfile.txt
> > patchfile.txt Type: Plain Text (text/plain)
> > Encoding: quoted-printable
>