RE: Parameterized "task-function"

["Rosen, Alex" <ar...@silverstream.com>]

OK, switching over to ant-dev...

> perhaps - but we already have "methods" via ant-call and they were
> generally found to be lacking. A few days ago jerry.huth@eng.sun.com posted
> something to ant-dev titled "The RIGHT Direction for ANT" which pretty much
> reverted me to thinking that static templating is way to go. He also
> advocated separation between rules/templates and data operated on. If you
> think it is backward you should pop onto ant-dev and respond to this
> message ;)

Unfortunately I don't feel I have the knowledge to comment on that message,
since I have no experience with very large projects, or dependency generators.
If we really think that any moderately complex project will need to be built
via a dependency generator, and the Ant file itself will never be seen by
humans, then my point is irrelevent. I'm not convinced of this, however. There
are still LOTS of complex projects that use hand-written Make files, and I
suspect that will always be the case with Ant, too, whether that's the right
way to go or not.

> ant-call is your friend. It is here and now ;) Thou it may
> not be in the future - who can tell ;)

(1) <ant> and <antcall> are currently lacking, but is that because they don't
belong, or because they just need improvement? Or the Ant system could be
friendlier to this style of usage?
(2) I'm arguing more about Ant 2.0 than now, so this discussion is very much
relevent.

> >You want to use a
> >declarative language to figure out what to build, but you
> really want to use a
> >procedural language to describe how to build it.
>
> essentially. All procedural-ness is hidden in tasks and tasks
> should NOT
> interact with each other.

I understand what you mean, but that's clearly not the case in one sense. When
I execute a <javac> task and then a <jar> task, these tasks do "interact" in
some sense, in that the <jar> task wouldn't do anything useful if it were not
preceeded by the <javac> task. If I switch the order of these XML elements, it
breaks.

> >Is there anything declarative about describing how to build
> something (as
> >opposed to describing what to build)?
>
> I am not sure what you mean. Declarative is a representation and doesn't
> govern these sorts of things. I am not even sure thats a useful distinction
> to make. The declarative approach can both describe a process (how) and the
> data (what) so I am not sure what you are saying.

I agree that there's a continuum from declarative to procedural. But some
things are more over toward one side or the other. Anything where order matters
is clearly more procedural than declarative, and that's clearly true of <javac>
and <jar>. The minute you have both of these tasks in the same file, you're
making an inherently procedural statement - first do this, then do that.
There's really nothing declarative about it, and that seems like a useful
distinction to make. And, it shows that "all procedural-ness is hidden in
tasks" is not completely true.

The cleanest, but inconvenient, way would be to have ALL procedural-ness in the
tasks. E.g. if I want to perform a Javac and then a Jar command, I have to
write a Task that calls these procedures, and in my Ant file I have to execute
the task <javac-plus-jar>. The procedural-ness that's supported in the current
Ant file seems like it's a way to work around the inconvenience of this: you
can include some prodecural-ness in the Ant file, as long as it's limited - no
looping, no real function calls, etc. That's fine, but it shows that there is
some procedural-ness left in the Ant file.

Here's a radical idea (though I wouldn't be surprised if it's been thought of
before and rejected). What if *all* procedural-ness had to be written in Java,
but that Java could go in the same file as the declarative statements? Then
your earlier example might become something like:

<target name="foo">
  	<java>
		buildJar("bean1");
		buildJar("bean2");
		buildJar("bean3");
	</java>
</target>

<java>
	private void buildJar(String name)
	{
		javac("src/java/" + name, "build/" + name);
		jar(name + ".jar", "build/" + name);
		signjar(name + ".jar");
		cab(name + ".cab", "build/" + name);
		signcab(name + ".cab");
	}
</java>

Ant would generate a Java file and compile it (if it was out of date), which
contained all the procedural code that would be called by Ant when running the
build file. E.g.

public class MyProject
{
	public void targetFoo()
	{
		buildJar("bean1");
		buildJar("bean2");
		buildJar("bean3");
	}

	private void buildJar(String name)
	{
		...
	}
}

For larger projects, or if the idea of mixing Java and XML in the same file
makes you nauseous, Ant can support having all Java code in a separate file.
But I think to make it at all convenient, Ant would have to automatically
compile the Java code for you when necessary.

This idea is more of a thought experiment than an actual proposal. But I think
it does actually make things cleaner - the declarative code is in XML, and the
procedural is in Java. (JavaScript could be supported too.) You've got all the
scripting features you want (functions, looping, etc), without sullying the
dependency information.

> The reason procedural is avoided is because it tends to be brittle,
> difficult to maintain, difficult to understand etc. In simple cases
> procedural wins out in simplicty because declarative has a
> high entry cost but for these exceptions we have the script task.

But that only applies to declarative tasks. Some tasks are inherently
procedural, and are much better served by a procedural style, and what you've
said above is not the case for those tasks. (That's why we all use Java.) We've
both agreed that describing how to build something is a procedural task.

--Alex

Re: Parameterized "task-function"

[Jason Rosenberg <ja...@squaretrade.com>]

----- Original Message ----- 
From: "Rosen, Alex" <ar...@silverstream.com>
To: "'ant-dev'" <an...@jakarta.apache.org>
Sent: Friday, January 12, 2001 1:01 PM
Subject: RE: Parameterized "task-function"


> OK, switching over to ant-dev...
> 

Now the fun is beginning
.....

> > >You want to use a
> > >declarative language to figure out what to build, but you
> > really want to use a
> > >procedural language to describe how to build it.
> >
> > essentially. All procedural-ness is hidden in tasks and tasks
> > should NOT
> > interact with each other.
> 
> I understand what you mean, but that's clearly not the case in one sense. When
> I execute a <javac> task and then a <jar> task, these tasks do "interact" in
> some sense, in that the <jar> task wouldn't do anything useful if it were not
> preceeded by the <javac> task. If I switch the order of these XML elements, it
> breaks.
> 

Yep, when things are order dependent, they are procedural, you're prescribing
a process.

> 
> Here's a radical idea (though I wouldn't be surprised if it's been thought of
> before and rejected). What if *all* procedural-ness had to be written in Java,
> but that Java could go in the same file as the declarative statements? Then
> your earlier example might become something like:
> 
> <target name="foo">
>   <java>
> buildJar("bean1");
> buildJar("bean2");
> buildJar("bean3");
> </java>
> </target>
> 
> <java>
> private void buildJar(String name)
> {
> javac("src/java/" + name, "build/" + name);
> jar(name + ".jar", "build/" + name);
> signjar(name + ".jar");
> cab(name + ".cab", "build/" + name);
> signcab(name + ".cab");
> }
> </java>
> 

In one sense, I like this embedded java idea.  It takes away the need
for having the <script> task, and having to include all the bsf and
rhino stuff to get it all to work, etc.

But there are probably serious caveats.  You probably will need to
ensure that there are rules for what kinds of java can be written.
You might get into trouble if you start accessing Ant internals
via java code, etc., or if you start trying to use externally defined
java classes which may or may not be in your classpath, etc.

You might try to have a pre-processing step which disallows
any import statements, or fully qualified references to anything
but a set of agreed upon Ant functions, such as javac, jar, signjar,
etc.

But all in all, I am liking the possibilities with this idea.

Jason

RE: Parameterized "task-function"

["Rosen, Alex" <ar...@silverstream.com>]

> eek :)

I figured you'd say that :) Like I said, it's more of a thought experiment than
an actual proposal.

I guess what it comes down to is that there are 3 choices for doing procedural
tasks in Ant:

1) Do templating using XSLT.
2) Do scripting using, essentially, an Ant-specific language, using elements
like <if>, <case>, etc.
3) Do scripting using an existing language like Java or JavaScript.

Number 1 feels totally unnatural to me, because it's denying the inherently
procedural nature of the job. Number 2 is what Jason is proposing, but I'm not
wild about the idea of essentially creating a new scripting language. So I'm
exploring Number 3. Granted, it's got problems of its own. If you use Java, it
means having to compile it. No matter what language you use, people will have
to learn that language. (XSLT has the same problem, BTW.)

I could accept XSLT better if it were presented as "it's not great, because
it's trying to cram a procedural task into a declarative system, but it sucks
less than the alternatives." Right now it sounds like "XSLT is a perfectly fine
way to go," which I don't agree with.

Alex

RE: Parameterized "task-function"

[Peter Donald <do...@apache.org>]

At 01:01  12/1/01 -0500, Rosen, Alex wrote:
>OK, switching over to ant-dev...
>
>> perhaps - but we already have "methods" via ant-call and they were
>> generally found to be lacking. A few days ago jerry.huth@eng.sun.com posted
>> something to ant-dev titled "The RIGHT Direction for ANT" which pretty much
>> reverted me to thinking that static templating is way to go. He also
>> advocated separation between rules/templates and data operated on. If you
>> think it is backward you should pop onto ant-dev and respond to this
>> message ;)
>
>Unfortunately I don't feel I have the knowledge to comment on that message,
>since I have no experience with very large projects, or dependency
generators.
>If we really think that any moderately complex project will need to be built
>via a dependency generator, and the Ant file itself will never be seen by
>humans, then my point is irrelevent. I'm not convinced of this, however.
There
>are still LOTS of complex projects that use hand-written Make files, and I
>suspect that will always be the case with Ant, too, whether that's the right
>way to go or not.
>
>> ant-call is your friend. It is here and now ;) Thou it may
>> not be in the future - who can tell ;)
>
>(1) <ant> and <antcall> are currently lacking, but is that because they don't
>belong, or because they just need improvement? Or the Ant system could be
>friendlier to this style of usage?

Essentially because Ant1.x "grew" rather than being designed from the start
and consequently each ant-call will completely reparse the whole build file
which bites. If thats what you mean by lacking then - yes this will go away
- if you mean something else then explain ;)

These will probably still remain in some form because users would scream
for blood if we took it out ;) For Ant2.0 there has been a number of
proposals that allow segragation of builds across multiple build files.
There has also been the XSLT for templating so in a sense the usefulness of
ant-call/ant will decrease as it now only useful for dynamic templating.
"dynamic" templating being those templates that are determined by runtime
setting of properties. I am not sure if "dynamic" templating is necessary
or even useful thou so ... ;)

>(2) I'm arguing more about Ant 2.0 than now, so this discussion is very much
>relevent.

kewl ;)

>> essentially. All procedural-ness is hidden in tasks and tasks
>> should NOT
>> interact with each other.
>
>I understand what you mean, but that's clearly not the case in one sense.
When
>I execute a <javac> task and then a <jar> task, these tasks do "interact" in
>some sense, in that the <jar> task wouldn't do anything useful if it were not
>preceeded by the <javac> task. If I switch the order of these XML
elements, it
>breaks.

right - there will be indirect interaction but I was more thinking that

<if condition="foo">
  <task1 .../>
  <task2 .../>
</if>

where if interacts with task1/2 should not be encouraged.

>I agree that there's a continuum from declarative to procedural. But some
>things are more over toward one side or the other. Anything where order
matters
>is clearly more procedural than declarative, and that's clearly true of
<javac>
>and <jar>. The minute you have both of these tasks in the same file, you're
>making an inherently procedural statement - first do this, then do that.
>There's really nothing declarative about it, and that seems like a useful
>distinction to make. And, it shows that "all procedural-ness is hidden in
>tasks" is not completely true.

right ;)

>Here's a radical idea (though I wouldn't be surprised if it's been thought of
>before and rejected). What if *all* procedural-ness had to be written in
Java,
>but that Java could go in the same file as the declarative statements? Then
>your earlier example might become something like:

eek :)

If we were going to go this path there would no longer need be a
distinction been targets and tasks because targets are essentially
sequences of tasks. Besides - do you know how much hell that would be to
program Ant - and maintain the build files ;) 

A large proportion of our target audience doesn't know java, may not know
any prorgamming language and just uses ant to do platform independent
building of websites etc.


>This idea is more of a thought experiment than an actual proposal. But I
think
>it does actually make things cleaner - the declarative code is in XML, and
the
>procedural is in Java. (JavaScript could be supported too.) You've got all
the
>scripting features you want (functions, looping, etc), without sullying the
>dependency information.

Right - we used to actually recommend the script task for precisely these
reasons but it seems to have gone out of vogue at the moment ;)


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