ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Sun, 21 Oct 2001 13:10:45 GMT
On Sun, 21 Oct 2001 22:48, Erik Hatcher wrote:
> ----- Original Message -----
> From: "Peter Donald" <>
> To: <>
> Sent: Sunday, October 21, 2001 7:37 AM
> > > Am I at least in the same ballpark as the ideas being discussed here?
> >
> > Sorta .. well actually no. We are talking how the container would support
> > such tasks. While you are talking about the infrastructure the task must
> > create to make script writing easy ;)
> But if the container supports the capability (which it already does for
> Java written Tasks) to allow script tasks to be introspected (in some way,
> perhaps via some metadata provided from the script task itself) and have
> rich types (i.e. filesets) handed to them for free, then that directly
> impacts the infrastructure and complexity required for developing a script
> task.   Or am I still barking up the wrong tree?

Well I guess it is up to the person who ends up writing the script task, how 
the script gets to use it's own task model. We could use the default 
introspection but that would require that task writer conform to ant 
standards or write lots of meta-data which seems counter to the purpose of 
scripting ;)

One way that may be useful would be something like - using a psuedo scripting 
language ;)

println "My files attribute as a string" + model.attributes["files"]
println "My files attribute as a type" + model.getAttribute("files", FileSet)

println "My fileset element as a string" + model.elements["fileset"]
println "My fileset element as a type" + model.getElement("fileset", FileSet)

If you want to do full validation it is probably easier to just writer the 
javacode in my mind ;)

> I'm certainly not an advocate for using <script> in a build generally
> speaking (contrary to popular belief! :), but the <script> issue we're
> discussing seems to me to be implicitly related to issues that have been
> discussed such as the "container" concept.

I see it in a similar light to JSP. JSP is dependent on servlet API but 
theoretically there needed to be no changes to servlet API to accomodate JSPs 
(or XSPs or Velocity Macors or whatever).



"When we remember we are all mad, the mysteries of life 
disappear and life stands explained." -Mark Twain

View raw message