You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ant.apache.org by Jason Rosenberg <ja...@squaretrade.com> on 2001/01/07 06:40:06 UTC

Re: Problem using script task

----- Original Message ----- 
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Friday, December 29, 2000 8:19 AM
Subject: Re: Problem using script task

> At 07:44  28/12/00 -0500, Jason Rosenberg wrote:
> >Ant is a scripting language.  The idea of using a <script> task is a bit
> >nonsensical.  Just extend the Ant Scripting language to do the simple
> >things we need (there are not too many of these).
> 
> ummmmmmmmm .....
> 
> Ant is supposed to be a ***declarative*** scripting language. 

Not really, there are lots of built in procedural tasks, which are
part of the core (javac,mail,fail,etc.).  Actually, I think all the tasks
are procedural.  That is, they execute actions at the time they
are 'called'.  Even the <property> task behaves this way.  Nothing
'declarative' about tasks in Ant.

Perhaps, you could say that the <target> tag is a declarative programming
construct, but, of course, it is useless without procedural glue necessarily
added to it ("if","unless","depends").

Sounds like the old "Lisp is great, its declarative, but umm, could we
please have some loops and conditional execution added" reducto ad absurdum.
Lisp was worthless until looping and flow control was added, but then
the whole elegance of the declarative principal was lost.

There is no such thing as an adequate declarative programming
construct.

> I agree that
> the use of ant-call makes it procedural but that is only because we needed
> templating but couldn't rearrange the core dramatically to do it at the
> time ;) If ant-call was made to be more templatish then ant would return to
> being declarative.
> 

Yes, agreed, templates are the crux of the problem, and antcall is a hack, indeed.
But, what is a template.  It's a reusable task.  One that can be recalled and reused
with different parameters.   Can you say "sub-routine"?

> What you seem to want is a ***procedural*** language which I am definetly
> -1 for a whole bunch of reasons that have been enumerated in the past.
> 

Ant is procedural, and that is what I want.  It is close to being useful,
to date, but just needs to add a very small set of features to close the
case.  Simply admitting that it is procedural would really clear the way.
Let's stop beating around the bush.

> 
> perhaps you also want negation, then implication, maybe xor ? ... Guess
> what you want perl/make - they already exist - lucky you ;)

Actually, implication is more a declarative logic programming construct,
which adds no value to my world view....

> personally I don't relish looking at
> 
> <target name="foo" condition="a ^ ~(b == (c&d|e^f) ) &d" />
> 
> and trying to work out what that means.
> 

Yes, I think the beauty of Ant is that it has the power to keep
things simple and human readable.  I like the <execute-task>
idea mentioned by someone on another topic, or possibly a 
simple case:

<case property="caseProperty">
    <if value="1" execute="doMainCompile"/>
    <if value="2" execute="doPartialBuild"/>
    <default execute="showErrorAndFaile"/>
</case>

The execute attributes refer to other defined targets in the project.
Whatever....The point being is that it is a no-brainer to define the
language such that it is not at all difficult to read the embedded logic.

> >Some fundamental "task" issues are:
> >
> >    if-then-else
> >    switch
> >    loop
> 
> not a chance of making core. If you want it then create your own tasks.
> Look to ant-dev archives for reasoning.
> 

Not sure there is much reasoning to look for.  You seem to be saying
that the pristine declarative nature should be the primary consideration,
and yet, repeatedly, the core has been augmented by lots of absolutely
necessary procedural constructs, both in terms of the core builtin
tasks, and the "depends","if","unless", etc......

I think there are enough people now who see the shortcomings of your
historical reasoning that I would really doubt you are correct in saying
"not a chance of making core"....

Re: Problem using script task

Posted by Peter Donald <do...@apache.org>.

At 12:40  7/1/01 -0500, Jason Rosenberg wrote:
>> At 07:44  28/12/00 -0500, Jason Rosenberg wrote:
>> >Ant is a scripting language.  The idea of using a <script> task is a bit
>> >nonsensical.  Just extend the Ant Scripting language to do the simple
>> >things we need (there are not too many of these).
>> 
>> ummmmmmmmm .....
>> 
>> Ant is supposed to be a ***declarative*** scripting language. 
>
>Not really, there are lots of built in procedural tasks, which are
>part of the core (javac,mail,fail,etc.).  Actually, I think all the tasks
>are procedural.  That is, they execute actions at the time they
>are 'called'.  Even the <property> task behaves this way.  Nothing
>'declarative' about tasks in Ant.

welll - these are procedural tasks yes but that doesn't have anything to do
with the representation which is/should be declarative. 

>Sounds like the old "Lisp is great, its declarative, but umm, could we
>please have some loops and conditional execution added" reducto ad absurdum.
>Lisp was worthless until looping and flow control was added, but then
>the whole elegance of the declarative principal was lost.
>
>There is no such thing as an adequate declarative programming
>construct.

sure there is. There is a whole bunch of em actually. Look to many
data-representation programming constructs, SQL constructs, some XML
constructs .... but right - they must be failures ?

>Yes, agreed, templates are the crux of the problem, and antcall is a hack,
indeed.
>But, what is a template.  It's a reusable task.  One that can be recalled
and reused
>with different parameters.   Can you say "sub-routine"?

yes ..... but I am not sure you understand what declarative means. It
refers to representation and not features. Declarative constructs can still
have selection, limited iteration, sequence and reusable blocks but it is
how they are repsented that differs from procedural programming.

>> What you seem to want is a ***procedural*** language which I am definetly
>> -1 for a whole bunch of reasons that have been enumerated in the past.
>> 
>Ant is procedural, and that is what I want.  It is close to being useful,
>to date, but just needs to add a very small set of features to close the
>case.  Simply admitting that it is procedural would really clear the way.
>Let's stop beating around the bush.

There are some procedural bits in it but I think they will be removed if
they are essential parts of ant (ie the ant-call functionality). Other
tasks may be left that allow you to do procedural stuff (ie MT stuff talked
about recently) but I will fight tooth and claw to prevent core becoming
procedural.

Luckily for you Ant2.0 will most likely have reusable bits so you can
reimplement it any way you want. There has been one person who has
approached me to use Ant2.0 as a general scripting interface (ie
procedural) for their project (a java based desktop environment) and I know
of two other xml-procedural scripting initiatives (xmlshell and another).
So feel free to add the functionality you want - I think the core will be
flexable enough for that (I hope it will). 

But don't expect the default ant build representation to become procedural.

>> <target name="foo" condition="a ^ ~(b == (c&d|e^f) ) &d" />
>> 
>> and trying to work out what that means.
>> 
>
>Yes, I think the beauty of Ant is that it has the power to keep
>things simple and human readable.  I like the <execute-task>
>idea mentioned by someone on another topic, or possibly a 
>simple case:
>
><case property="caseProperty">
>    <if value="1" execute="doMainCompile"/>
>    <if value="2" execute="doPartialBuild"/>
>    <default execute="showErrorAndFaile"/>
></case>

these sorts of things are possible in future but we won't know yet. I used
to be in favour of xslt-like preprocessing for templating but that can only
represent structural constraints (ie static) while some people have
demanded dynamic templating like above (and like what ant-call satisfies).
Difficult to say how it will be satisfied atm till we have a play.

>> >Some fundamental "task" issues are:
>> >
>> >    if-then-else
>> >    switch
>> >    loop
>> 
>> not a chance of making core. If you want it then create your own tasks.
>> Look to ant-dev archives for reasoning.
>> 
>
>Not sure there is much reasoning to look for.  You seem to be saying
>that the pristine declarative nature should be the primary consideration,
>and yet, repeatedly, the core has been augmented by lots of absolutely
>necessary procedural constructs, both in terms of the core builtin
>tasks, and the "depends","if","unless", etc......

arguing from ignorance love that approah. There is reason if you care to read.

>I think there are enough people now who see the shortcomings of your
>historical reasoning that I would really doubt you are correct in saying
>"not a chance of making core"....

It is not my reasoning as such. I was just a user when most of the
"discussion" was going down and ignored it for most purposes. I think
Duncan was around then and maybe Sam Ruby but other than that there has
been a full refresh of the guards so no one else was involved I don't
think. If you want details look in the archives.

You are free to develope any tasks you want thou - some of the active
developers on ant-dev have case/if tasks to suit their needs and you will
be easily able to do the same. However it is unlikely that the nature of
the tool will change as much as you want it to so if you want procedural
elements that can not be represented at task level feel free to fork. Thats
the beauty of OSS - you scratch what itches.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Peter Donald <do...@apache.org>.

At 04:10  9/1/01 -0800, Jerry Huth wrote:
>You can think of it as "smart templating": using a program rather than
>static templates so that the generated build scripts can be extremely
>complex (i.e. feature-rich) with a Constant time programming effort.

When I think smart-templates I think XSLT + some XSLT extentions. Would
that satisfy you needs ? XSLT could do all the static structural templating
and the XSLT extentions could be used to "insert" context information into
XSLT process like a list of files in current directory.

>Of course it depends which "real world" you're in.  The simple fact of
>the matter is that companies with very large software projects
>(millions or tens of millions of LOC's or more) simply do not use ANT
>or MAKE directly.  They use generator programs such as I described.

even medium sized projects don't use MAKE directly. Hell - even small
projects tend to generate (or hand craft build files to template) nowadays
I have found.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Jason Rosenberg <ja...@squaretrade.com>.

----- Original Message ----- 
From: "Jerry Huth" <je...@Sun.COM>
To: <an...@jakarta.apache.org>
Sent: Tuesday, January 09, 2001 7:10 PM
Subject: Re: The RIGHT Direction for ANT (was Re: Problem using script task)

> 
> But this really gets to the heart of why you can't see my point.  When
> you're in the forest one tree may look a lot bigger than another, but
> when you're at 20,000 feet they're all just a bunch of toothpicks.
> 

Well, maybe you are preaching only to the huge mondo
corporations with a bizillion lines of outdated legacy
code to be maintained.

That's not my situation.  Your whole argument assumes
that there should be an automated way for a program
to guess how to build just about anything, a priori.

Not very realistic.

So, if I have a directory with a bunch of source files,
I suppose you are saying it should just be a cake-walk
to have an automated process that will go through the
directory, and based on file types, etc., just make
standardized, rigid, decisions about how each source
file should be dealt with, without actually inspecting
the source files, etc.

This is not my world, and I don't need anything other
than, precisely, Ant with just a few, minor extensions
to make it more workable, especially in the area
of templating.

My understanding is that Ant 2.0 is supposed to do a lot
of the things I am requesting, although I haven't heard
or seen the specifics of Ant 2.0 yet, or any projected
release date.  In fact, it seems like everyone is still
arguing about it and pointing fingers, so it may still take
a while.

Jason

Re: The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Jerry Huth <je...@Sun.COM>.

Jason Rosenberg wrote:
> In my experience, the "dependency-generator" program to which
> you refer is usually a manual process.  Assuming you have built up
> a workable build environment, the job of generating the build-sets
> and dependent deliverable modules, requires little overhead above
> and beyond writing the code itself for which dependencies you are
> trying to track.


Actually I wasn't talking about just dependency generation.  Maybe I
should have called the program I was referring to a "build script
generator".  What I'm talking about is a program that generates the
ANT files (or Make files).  I'm not talking about just automatically
generating dependencies.  I'm talking about automatically generating
the complete build scripts!  I'm talking about using MAKE or ANT for
all they're really good at: processing low-level computer-generated
dependency scripts!

You can think of it as "smart templating": using a program rather than
static templates so that the generated build scripts can be extremely
complex (i.e. feature-rich) with a Constant time programming effort.


> So, frankly it is essential that the build environment is easy to work
> with, and has a set of features which make it easy to create the
> "dependency-reading" programs needed for each module.


Exactly:  Nothing is easier than using a program to automatically 
create the build scripts.


> So, if I have a working template that builds Weblogic EJB's in my 
> environment, for instance, then certainly, I don't want to have to 
> painstakingly redefine the sequence of compiling and jarring and 
> distributing the EJB individually, but rather, I want to reuse it.  
> So, I create a template that knows how to build and jar and distribute
> my ejb's, knows how to clean up after them, knows how
> to update them from cvs, in a standard way.  This is all above
> and beyond the simple 'ejbjar' task that is currently an 'optional'
> task in Ant.  Because I can write a reusable template that
> knows for my environment where all the important classes
> are located (for setting the classpath), etc., the ability to
> have a reusable, customized procedure, really isn't asking
> for too much.
> 
> Now, I simply declare that project X is an EJB, and my
> template now knows what to do with it.  That is the power
> of templating.


I know that simply adding a static template feature to ANT seems like
a great idea if all you've ever done before is written the ANT or MAKE
scripts manually (and honestly you are "on the right track" since you
intuitively understand that there is a better way than writing them by
hand).  However, the programming effort to go the next step and have a
separate program that completely generates the build scripts requires,
as I say, only a Constant time effort but is infinitely more powerful
than static templates.


> I have now done this, but it is rather ugly, since the process of
> creating reusable templates amounts to transferring the bulk
> of my Ant implementation to javascript code called from the
> <script> task.
> 
> Your high-browed discussion of dependency-reading vs.
> dependency-generating programs is a bit off base, not sure
> if it has much of an audience in the real world.


Of course it depends which "real world" you're in.  The simple fact of
the matter is that companies with very large software projects
(millions or tens of millions of LOC's or more) simply do not use ANT
or MAKE directly.  They use generator programs such as I described.

I didn't just make up my analysis of the effort required to develop
and maintain large software build systems; it came from my own
experience.  And in that experience I've found that it was easier to
work on very large software projects with a build script generator
program than on medium-sized projects using just ANT or MAKE.


> What is the big-"O" order for the job of writing software?
> If I write some new code, I also need to define how the
> software should be built, and how it should be deployed.
> This doesn't add significantly to the 'order'.  Especially,
> if the job of stating how to build the module is nothing
> more than labelling the project as (an ejb, a java package,
> a jsp page, or whatever).
> 
> Templating is truly powerful, and I now see how great
> it can be, with my Ant/Javascript implementation.  This
> would have been a royal pain in the butt with Make.
> 
> Probably the biggest flaw in your argument is to have
> lumped together Make and Ant as equivalents.  Ant
> is clearly much easier and much more powerful and
> much more portable than Make.  That's why Ant is
> attractive.  It has little to do with dependency tracking.


But this really gets to the heart of why you can't see my point.  When
you're in the forest one tree may look a lot bigger than another, but
when you're at 20,000 feet they're all just a bunch of toothpicks.



 
> ----- Original Message -----
> From: "Jerry Huth" <je...@Sun.COM>
> To: <an...@jakarta.apache.org>
> Sent: Tuesday, January 09, 2001 1:57 PM
> Subject: The RIGHT Direction for ANT (was Re: Problem using script task)
> 
> >
> > This discussion about whether or not ANT should have more advanced
> > features such as templates is amusing because the obvious answer is
> > that if your software system is so large that you need such advanced
> > features, then your build system should include both a
> > dependency-generation program as well as a dependency-reading program.
> >
> > ANT and MAKE are dependency-reading programs.  They are meant to read
> > dependency scripts and fire the actions.  They are not meant as
> > human-written scripting languages for large software systems.
> > Dependency-generation programs are those that write out the dependency
> > scripts: they generate the ANT or MAKE build scripts so that humans
> > don't have to.
> >
> > As software systems grow in size, the folly of trying to use the
> > dependency scripts to define your whole software build system becomes
> > more and more apparent.  No matter how many advanced features you add
> > to your dependency-reading program, you will always be able to build
> > large software systems easier using a dependency-generation program in
> > combination with the dependency-reading program.
> >
> > In fact, the only reason to add advanced features to ANT or MAKE is to
> > allow them to be used (however awkwardly) for medium-sized software
> > projects.  For large software projects it is clear that using the two
> > programs in combination is infinitely easier than trying to build the
> > whole system with only a dependency-reading program.  Indeed, MAKE
> > has become exorbitantly bloated with "advanced" features over the
> > years, but still it is completely inadequate for large software
> > systems unless it is used in combination with a dependency-generation
> > program.
> >
> > Mathematically the reason why using the two programs together is
> > easier is that the dependency-generation program requires only
> > Constant time effort (it is not dependent on the size of the software
> > system being built), whereas dependency scripts always require at
> > least some O(n) effort (n is the number of lines of source code being
> > built).  Furthermore, using a dependency-generation program allows you
> > to minimize the O(n) effort by putting the "smarts" of the build
> > system in the dependency-generation program, thus allowing the O(n)
> > scripts to be reduced to their smallest possible size.  Indeed, when
> > used with a good dependency-generation program, the O(n) effort is so
> > small that it is easily handled by the source code developers
> > themselves.
> >
> > Theoretically if a software system is "sufficiently uniform" than a
> > feature as simple as templates could allow ANT or MAKE to be used
> > without a dependency-generation program; but of course as software
> > systems grow in size, their degree of uniformity inevitably lessens
> > due to the increasing need for automation and other advanced build
> > features, so there is always a point at which the use of a separate
> > dependency-generation program is easier.
> >
> > Ultimately, software build systems should provide the most advanced
> > build features to the end-user (the software developer) while reducing
> > the O(n) build script maintainence effort to its minimal value.  And
> > this is precisely why using the two programs in combination is so
> > effective: coding the advanced features of a build system in the
> > Constant-time part (the dependency-generation program) will always
> > require less effort than coding them in the O(n) part (the dependency
> > scripts).
> >
> > What this means for the future direction of ANT is that we shouldn't
> > repeat the mistakes of MAKE by continuing to pile on more and more
> > features of dubious usefullness.  Instead we should focus our efforts
> > on providing an ANT file generator that is sufficiently general to be
> > useful to the software community at large.
> >
> > The irony of using a dependency-generator program is that when you
> > have one you only need very basic features in the dependency-reading
> > program.  ANT doesn't need any more features, it needs a companion ANT
> > file generator program!
> >
> > ---
> >
> > Jerry Huth
> > Sun Microsystems
> > (650) 786-4658
> > jerry.huth@sun.com
> >
> >
> >
> > -------------------------------------------------------------------------
> > Jason Rosenberg wrote:
> > >
> > > > On 1/6/01 9:40 PM, "Jason Rosenberg" <ja...@squaretrade.com> wrote:
> > > >
> > > > > Ant is procedural, and that is what I want.  It is close to being useful,
> > > > > to date, but just needs to add a very small set of features to close the
> > > > > case.  Simply admitting that it is procedural would really clear the way.
> > > > > Let's stop beating around the bush.
> > > >
> > > > Nope. Let's not. There are things that Ant needs. IMHO, turning into
> > > > something procedural isn't one of them. I'd rather just write my
> > > > buildscripts in JavaScript if that were the case.
> > > >
> > >
> > > Well, I got into this debate because I wanted to have reusable templates
> > > which are applied across a large set of like modules, etc.  And, as we have
> > > seen, Ant 1.2 is still not adequate in terms of templating, etc.  So, this
> > > leaves us with having to use JavaScript, via the script task, if we want
> > > to have any sort of elegance with Ant.  So, for now, not only are you
> > > right in saying that if you want to do anything procedural, you should
> > > use JavaScript, you also need to add that you really end up doing
> > > everything in JavaScript anyway, even when you are using Ant.
> > >
> > > > I come down to the opinion that calling something data or code is pretty
> > > > tough. After all, software is just data at some point. :) However there is a
> > > > visceral line drawn about what Ant is good for, and at what point it's not.
> > > > That line has been labeled with the somewhat, but sort of useful terms of
> > > > "procedural vs. declarative". Neither term is totally appropriate. But we
> > > > use them anyway :)
> > > >
> > >
> > > Ant is a build management tool.  It's purpose is to build software.  This
> > > means doing things like javac and javadoc and copy and ejbjar, etc.
> > > These are all procedural tasks.  If you want to be able to represent
> > > a software build module declaratively, then you need to be able
> > > to define it as a data object, with attributes which define how to
> > > build it.  In order to do this constructively, you simply have to have
> > > templates or sub-routines, etc.
> > >
> > > > > Yes, I think the beauty of Ant is that it has the power to keep
> > > > > things simple and human readable.  I like the <execute-task>
> > > > > idea mentioned by someone on another topic, or possibly a
> > > > > simple case:
> > > > >
> > > > > <case property="caseProperty">
> > > > >   <if value="1" execute="doMainCompile"/>
> > > > >   <if value="2" execute="doPartialBuild"/>
> > > > >   <default execute="showErrorAndFaile"/>
> > > > > </case>
> > > >
> > > > But here you are saying you want a "if" target implementation that could
> > > > take any set of attributes and do something. "<execute-target>" only does
> > > > just that. It's a difference. And, imho, it's a big one.
> > > >
> > >
> > > I don't understand what you said here.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org

Re: The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Jason Rosenberg <ja...@squaretrade.com>.

In my experience, the "dependency-generator" program to which
you refer is usually a manual process.  Assuming you have built up
a workable build environment, the job of generating the build-sets
and dependent deliverable modules, requires little overhead above
and beyond writing the code itself for which dependencies you are
trying to track.

So, frankly it is essential that the build environment is easy to work
with, and has a set of features which make it easy to create the
"dependency-reading" programs needed for each module.

So, if I have a working template that builds Weblogic EJB's in my 
environment, for instance, then certainly, I don't want to have to 
painstakingly redefine the sequence of compiling and jarring and 
distributing the EJB individually, but rather, I want to reuse it.  
So, I create a template that knows how to build and jar and distribute
my ejb's, knows how to clean up after them, knows how
to update them from cvs, in a standard way.  This is all above
and beyond the simple 'ejbjar' task that is currently an 'optional'
task in Ant.  Because I can write a reusable template that
knows for my environment where all the important classes
are located (for setting the classpath), etc., the ability to
have a reusable, customized procedure, really isn't asking
for too much.

Now, I simply declare that project X is an EJB, and my
template now knows what to do with it.  That is the power
of templating.

I have now done this, but it is rather ugly, since the process of
creating reusable templates amounts to transferring the bulk
of my Ant implementation to javascript code called from the
<script> task.

Your high-browed discussion of dependency-reading vs.
dependency-generating programs is a bit off base, not sure
if it has much of an audience in the real world.

What is the big-"O" order for the job of writing software?
If I write some new code, I also need to define how the
software should be built, and how it should be deployed.
This doesn't add significantly to the 'order'.  Especially,
if the job of stating how to build the module is nothing
more than labelling the project as (an ejb, a java package,
a jsp page, or whatever).

Templating is truly powerful, and I now see how great
it can be, with my Ant/Javascript implementation.  This
would have been a royal pain in the butt with Make.

Probably the biggest flaw in your argument is to have
lumped together Make and Ant as equivalents.  Ant
is clearly much easier and much more powerful and
much more portable than Make.  That's why Ant is
attractive.  It has little to do with dependency tracking.

Jason





----- Original Message ----- 
From: "Jerry Huth" <je...@Sun.COM>
To: <an...@jakarta.apache.org>
Sent: Tuesday, January 09, 2001 1:57 PM
Subject: The RIGHT Direction for ANT (was Re: Problem using script task)


> 
> This discussion about whether or not ANT should have more advanced
> features such as templates is amusing because the obvious answer is
> that if your software system is so large that you need such advanced
> features, then your build system should include both a
> dependency-generation program as well as a dependency-reading program.
> 
> ANT and MAKE are dependency-reading programs.  They are meant to read
> dependency scripts and fire the actions.  They are not meant as
> human-written scripting languages for large software systems.
> Dependency-generation programs are those that write out the dependency
> scripts: they generate the ANT or MAKE build scripts so that humans
> don't have to.
> 
> As software systems grow in size, the folly of trying to use the
> dependency scripts to define your whole software build system becomes
> more and more apparent.  No matter how many advanced features you add
> to your dependency-reading program, you will always be able to build
> large software systems easier using a dependency-generation program in
> combination with the dependency-reading program.  
> 
> In fact, the only reason to add advanced features to ANT or MAKE is to
> allow them to be used (however awkwardly) for medium-sized software
> projects.  For large software projects it is clear that using the two
> programs in combination is infinitely easier than trying to build the
> whole system with only a dependency-reading program.  Indeed, MAKE
> has become exorbitantly bloated with "advanced" features over the
> years, but still it is completely inadequate for large software
> systems unless it is used in combination with a dependency-generation
> program.
> 
> Mathematically the reason why using the two programs together is
> easier is that the dependency-generation program requires only
> Constant time effort (it is not dependent on the size of the software
> system being built), whereas dependency scripts always require at
> least some O(n) effort (n is the number of lines of source code being
> built).  Furthermore, using a dependency-generation program allows you
> to minimize the O(n) effort by putting the "smarts" of the build
> system in the dependency-generation program, thus allowing the O(n)
> scripts to be reduced to their smallest possible size.  Indeed, when
> used with a good dependency-generation program, the O(n) effort is so
> small that it is easily handled by the source code developers
> themselves.
> 
> Theoretically if a software system is "sufficiently uniform" than a
> feature as simple as templates could allow ANT or MAKE to be used
> without a dependency-generation program; but of course as software
> systems grow in size, their degree of uniformity inevitably lessens
> due to the increasing need for automation and other advanced build
> features, so there is always a point at which the use of a separate
> dependency-generation program is easier.
> 
> Ultimately, software build systems should provide the most advanced
> build features to the end-user (the software developer) while reducing
> the O(n) build script maintainence effort to its minimal value.  And
> this is precisely why using the two programs in combination is so
> effective: coding the advanced features of a build system in the
> Constant-time part (the dependency-generation program) will always
> require less effort than coding them in the O(n) part (the dependency
> scripts).
> 
> What this means for the future direction of ANT is that we shouldn't
> repeat the mistakes of MAKE by continuing to pile on more and more
> features of dubious usefullness.  Instead we should focus our efforts
> on providing an ANT file generator that is sufficiently general to be
> useful to the software community at large.
> 
> The irony of using a dependency-generator program is that when you
> have one you only need very basic features in the dependency-reading
> program.  ANT doesn't need any more features, it needs a companion ANT
> file generator program!
> 
> ---
> 
> Jerry Huth
> Sun Microsystems
> (650) 786-4658
> jerry.huth@sun.com
> 
> 
> 
> -------------------------------------------------------------------------
> Jason Rosenberg wrote:
> > 
> > > On 1/6/01 9:40 PM, "Jason Rosenberg" <ja...@squaretrade.com> wrote:
> > >
> > > > Ant is procedural, and that is what I want.  It is close to being useful,
> > > > to date, but just needs to add a very small set of features to close the
> > > > case.  Simply admitting that it is procedural would really clear the way.
> > > > Let's stop beating around the bush.
> > >
> > > Nope. Let's not. There are things that Ant needs. IMHO, turning into
> > > something procedural isn't one of them. I'd rather just write my
> > > buildscripts in JavaScript if that were the case.
> > >
> > 
> > Well, I got into this debate because I wanted to have reusable templates
> > which are applied across a large set of like modules, etc.  And, as we have
> > seen, Ant 1.2 is still not adequate in terms of templating, etc.  So, this
> > leaves us with having to use JavaScript, via the script task, if we want
> > to have any sort of elegance with Ant.  So, for now, not only are you
> > right in saying that if you want to do anything procedural, you should
> > use JavaScript, you also need to add that you really end up doing
> > everything in JavaScript anyway, even when you are using Ant.
> > 
> > > I come down to the opinion that calling something data or code is pretty
> > > tough. After all, software is just data at some point. :) However there is a
> > > visceral line drawn about what Ant is good for, and at what point it's not.
> > > That line has been labeled with the somewhat, but sort of useful terms of
> > > "procedural vs. declarative". Neither term is totally appropriate. But we
> > > use them anyway :)
> > >
> > 
> > Ant is a build management tool.  It's purpose is to build software.  This
> > means doing things like javac and javadoc and copy and ejbjar, etc.
> > These are all procedural tasks.  If you want to be able to represent
> > a software build module declaratively, then you need to be able
> > to define it as a data object, with attributes which define how to
> > build it.  In order to do this constructively, you simply have to have
> > templates or sub-routines, etc.
> > 
> > > > Yes, I think the beauty of Ant is that it has the power to keep
> > > > things simple and human readable.  I like the <execute-task>
> > > > idea mentioned by someone on another topic, or possibly a
> > > > simple case:
> > > >
> > > > <case property="caseProperty">
> > > >   <if value="1" execute="doMainCompile"/>
> > > >   <if value="2" execute="doPartialBuild"/>
> > > >   <default execute="showErrorAndFaile"/>
> > > > </case>
> > >
> > > But here you are saying you want a "if" target implementation that could
> > > take any set of attributes and do something. "<execute-target>" only does
> > > just that. It's a difference. And, imho, it's a big one.
> > >
> > 
> > I don't understand what you said here.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>

Re: The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Peter Donald <do...@apache.org>.

At 10:57  9/1/01 -0800, Jerry Huth wrote:
>This discussion about whether or not ANT should have more advanced
>features such as templates is amusing because the obvious answer is
>that if your software system is so large that you need such advanced
>features, then your build system should include both a
>dependency-generation program as well as a dependency-reading program.
...snip good stuff...

I largely agree. I think XSLT transforms are the way to go in the future.
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

The RIGHT Direction for ANT (was Re: Problem using script task)

Posted by Jerry Huth <je...@Sun.COM>.

This discussion about whether or not ANT should have more advanced
features such as templates is amusing because the obvious answer is
that if your software system is so large that you need such advanced
features, then your build system should include both a
dependency-generation program as well as a dependency-reading program.

ANT and MAKE are dependency-reading programs.  They are meant to read
dependency scripts and fire the actions.  They are not meant as
human-written scripting languages for large software systems.
Dependency-generation programs are those that write out the dependency
scripts: they generate the ANT or MAKE build scripts so that humans
don't have to.

As software systems grow in size, the folly of trying to use the
dependency scripts to define your whole software build system becomes
more and more apparent.  No matter how many advanced features you add
to your dependency-reading program, you will always be able to build
large software systems easier using a dependency-generation program in
combination with the dependency-reading program.  

In fact, the only reason to add advanced features to ANT or MAKE is to
allow them to be used (however awkwardly) for medium-sized software
projects.  For large software projects it is clear that using the two
programs in combination is infinitely easier than trying to build the
whole system with only a dependency-reading program.  Indeed, MAKE
has become exorbitantly bloated with "advanced" features over the
years, but still it is completely inadequate for large software
systems unless it is used in combination with a dependency-generation
program.

Mathematically the reason why using the two programs together is
easier is that the dependency-generation program requires only
Constant time effort (it is not dependent on the size of the software
system being built), whereas dependency scripts always require at
least some O(n) effort (n is the number of lines of source code being
built).  Furthermore, using a dependency-generation program allows you
to minimize the O(n) effort by putting the "smarts" of the build
system in the dependency-generation program, thus allowing the O(n)
scripts to be reduced to their smallest possible size.  Indeed, when
used with a good dependency-generation program, the O(n) effort is so
small that it is easily handled by the source code developers
themselves.

Theoretically if a software system is "sufficiently uniform" than a
feature as simple as templates could allow ANT or MAKE to be used
without a dependency-generation program; but of course as software
systems grow in size, their degree of uniformity inevitably lessens
due to the increasing need for automation and other advanced build
features, so there is always a point at which the use of a separate
dependency-generation program is easier.

Ultimately, software build systems should provide the most advanced
build features to the end-user (the software developer) while reducing
the O(n) build script maintainence effort to its minimal value.  And
this is precisely why using the two programs in combination is so
effective: coding the advanced features of a build system in the
Constant-time part (the dependency-generation program) will always
require less effort than coding them in the O(n) part (the dependency
scripts).

What this means for the future direction of ANT is that we shouldn't
repeat the mistakes of MAKE by continuing to pile on more and more
features of dubious usefullness.  Instead we should focus our efforts
on providing an ANT file generator that is sufficiently general to be
useful to the software community at large.

The irony of using a dependency-generator program is that when you
have one you only need very basic features in the dependency-reading
program.  ANT doesn't need any more features, it needs a companion ANT
file generator program!

---

Jerry Huth
Sun Microsystems
(650) 786-4658
jerry.huth@sun.com

-------------------------------------------------------------------------
Jason Rosenberg wrote:
> 
> > On 1/6/01 9:40 PM, "Jason Rosenberg" <ja...@squaretrade.com> wrote:
> >
> > > Ant is procedural, and that is what I want.  It is close to being useful,
> > > to date, but just needs to add a very small set of features to close the
> > > case.  Simply admitting that it is procedural would really clear the way.
> > > Let's stop beating around the bush.
> >
> > Nope. Let's not. There are things that Ant needs. IMHO, turning into
> > something procedural isn't one of them. I'd rather just write my
> > buildscripts in JavaScript if that were the case.
> >
> 
> Well, I got into this debate because I wanted to have reusable templates
> which are applied across a large set of like modules, etc.  And, as we have
> seen, Ant 1.2 is still not adequate in terms of templating, etc.  So, this
> leaves us with having to use JavaScript, via the script task, if we want
> to have any sort of elegance with Ant.  So, for now, not only are you
> right in saying that if you want to do anything procedural, you should
> use JavaScript, you also need to add that you really end up doing
> everything in JavaScript anyway, even when you are using Ant.
> 
> > I come down to the opinion that calling something data or code is pretty
> > tough. After all, software is just data at some point. :) However there is a
> > visceral line drawn about what Ant is good for, and at what point it's not.
> > That line has been labeled with the somewhat, but sort of useful terms of
> > "procedural vs. declarative". Neither term is totally appropriate. But we
> > use them anyway :)
> >
> 
> Ant is a build management tool.  It's purpose is to build software.  This
> means doing things like javac and javadoc and copy and ejbjar, etc.
> These are all procedural tasks.  If you want to be able to represent
> a software build module declaratively, then you need to be able
> to define it as a data object, with attributes which define how to
> build it.  In order to do this constructively, you simply have to have
> templates or sub-routines, etc.
> 
> > > Yes, I think the beauty of Ant is that it has the power to keep
> > > things simple and human readable.  I like the <execute-task>
> > > idea mentioned by someone on another topic, or possibly a
> > > simple case:
> > >
> > > <case property="caseProperty">
> > >   <if value="1" execute="doMainCompile"/>
> > >   <if value="2" execute="doPartialBuild"/>
> > >   <default execute="showErrorAndFaile"/>
> > > </case>
> >
> > But here you are saying you want a "if" target implementation that could
> > take any set of attributes and do something. "<execute-target>" only does
> > just that. It's a difference. And, imho, it's a big one.
> >
> 
> I don't understand what you said here.