ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rosen, Alex" <aro...@silverstream.com>
Subject RE: Parameterized "task-function"
Date Fri, 12 Jan 2001 18:01:44 GMT
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

Mime
View raw message