ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cos...@eng.sun.com
Subject Re: What flavour of scripting?
Date Fri, 03 Mar 2000 22:06:59 GMT
Ok, Pier was right, I'm out of here, too much lost time. 

I saved a copy of the current ant and I'll use it, maybe add few new
tasks. I just want a build tool and not a functional/procedural language. 


> >> optional part of several Apache projects.  And several Apache projects as
> >> option plugins to BSF (example: make no mistake about it, Ant is a
> >> scripting language.  If you have any doubt, take one look at
> >> tomcat-test.xml).
> 
> I looked at test-tomcat.xml and it looked just like a script.  To the point
> where I wondered why you used Ant.
> 
> I was also amazed to find that is relied on the left-to-right execution
> ordering of dependancies.

I don't get it - where ? 

The tests can be executed in any order, in paralel or not. It is trivial
to write a XSL that will generate a .sh or .bat file with the same effect. 

Where is the scripting in that ?

I didn't used Ant - test-tomcat is an XML file with a list of requests and
expected responses. It has nothing to do with ant - it can be used from
any language/program that can read an XML. 

I happen to use Ant as a driver for the tests, but that doesn't mean it's
the only way to do it. GTest doesn't have anything to do with Ant - it is
just a java bean that you can use from any java program. It can be called
from ant ( as any other bean that has an execute() method) - but it can
run without ant. ( it doesn't even extend Task ).

BTW, GTest.java is just one way to perform the tests - you can replace it
with your favorite URL getter and diff and you'll still be able to run the
tests.

If you don't like it - just use something else. It is easy to XSL-it to
anything else. 

> Describing how to build something is describing what sequence of tasks to
> execute.  This in an inherantly procedural activity - you are describing a
> series of tasks that make state changes on the file-system.

Not allways true. In order to build a project you can execute the targets
in any order, and even in paralel ( or on different machines ). Yes, the
current _implementation_ happen to be serial and look like a script. 

That's what I mean be "decription" - you can take the antfile and execute
it without ant, using a fancy and sophisticated build system ( or convert
it to a makefile and use make). 

Or you can use the tasks in a normal java application - without any XML
involved. 

Ant has 3 components:

- a set of tasks - normal java beans with an execute() method.

- a way to describe a build process ( note - <copy> doesn't mean a call to
Copy.java - it can be anything that has the same effect ).

- a simple driver that reads an XML file and creates a hierarchy of
java Objects.

Any of those can be used independently:
- you can create an Expand.java and call execute() in any java project. No
XML or driver needed - _no_ assumption is made in (most) Tasks about the
environment or driver.

- you can convert the antfile to a format that can be used by another
driver ( make ) - the reverse is not true, of course, because make is an
ugly scripting language. 

- you can use the driver to create java beans and call the execute()
method - and use it for projects where you don't actualy build something. 

If you want procedural language and variables - just create another
driver. 
 
> We've had a number of people post requirements saying they'd like certain
> functionality.  We've also had people saying ant should be kept as
> dependant targets each with a simple list of tasks.  There seems to be a
> fundamental conflict here.
> 
> What happens now?
> 
> There have been a number of intermediate solutions listed.  How do we pick
> one and go with it?

No need to pick one - you can implement tasks, or a new driver, or a new
antfile format. Just don't force people to use them !

> As a final suggestion, how about this:
> 
> Properties are constant once defined.  If defined at a certain scope they
> become undefined outside that scope.  Tasks can be nested.  It is an error
> to try to redefine an already defined property.

What about this - we remove ${foo} and properties. Use &entity; which is a
standard XML construct and defined by W3C. 

We had far too many problems and spent too much time discussing
<property>, and if we remove it we'll have just plain XML. Property is
clearly broken.  Antfiles will be just XML files with no other
"conventions" or "rules"  inside. 

Costin




Mime
View raw message