tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Ant
Date Sun, 12 Dec 1999 00:23:40 GMT
Conor MacNeill wrote:

> I know the discussion has moved on from here but I like the concept of the
> init entity. Whilst using an "init" target may be easier to implement and
> the project is nicely reduced to just a collection of targets, you are
> making one of those targets special. 

Good point.

> You are hardcoding that "specialness"
> rather than capturing it in the XML structure. "init" becomes a special
> target name which someone using ant must remember. What if they added a
> "depends" attribute to the init target? Making init an entity makes it
> specialness obvious to the build.xml author.
> What do you think?

I think you are right. <target name="init"> breaks some not-expressed
design patterns, as you wisely point out.

Let's evaluate things further:

Costin wants to make <property> a task. Also he wants to add <propfile>.
In order to do this, a taks must be a subelement of the <target>

We agreed that making _hidden_ automatic actions in Ant is "no good".
Everything should be driven by the build file.

This said, in a "project" there are currently two items:

 - target: a collection of tasks
 - task: an encapsulator of logically similar operations

Costin proposes to make <property> a task. I think this is a design
fault: a "task" as defined in the Task interface does not have
sufficient capabilities to set a property available to the other tasks.
This requires a special interface extention and this indicates that

 property extends task

in the sent that provides encapsulation for logically similar operations
but has the ability to return a (key,value) pair (that Ant will
interpret as a property and use in the ${xxx} expansion). Also, for
<propfile> you should be able to return a collection of (key,value)

The simple "return what indicated" property generator, is just the
simplest implementation. The <propfile> is a litte more complex one.
<apache-home> still more complex. <perfomance> could perform a complete
system bench and set some properties like "min-thread", "JVM-to-use"

<java-version> could be another implementation, and we keep going.

There are a lot of generally useful tasks and there are a lot of
generally useful property generators.

The problem is mapping: if I write something like 

 <target ...>
  <propfile file="${os}-${arch}.properties"/>

how do I know what properties have been set? The build file gets a pain
to maintain since there is hidden information. And this is a "no no"

Currently, there are lots of exposed properties that are hidden and you
don't know how to use them or how portable they are.

I would like to avoid this, expecially given the dangerous approaches
that risk to increment the number of hidden things that cannot be
directly controlled inside the build file.

What do you think?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message