cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [VOTE] Schematron validator in Anteater (and CocoonvalidatingTransformer)
Date Mon, 10 Jun 2002 02:14:05 GMT
On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <> wrote:

> From: "Ovidiu Predescu" <>
>> On 6/7/02 9:48 PM, "Ivelin Ivanov" <> wrote:
>>> I have also asked a question about reusing steps among test cases.
>>> How do you suggest this can be done?
>> Just group the different test cases in two different targets. In a common
>> test target, just do the login, then call the two targets sequentially,
> and
>> then do the logout. If you want the two steps to happen in parallel, you
> can
>> use Ant's <parallel> element.
>> Something like this:
>> <target name="test1">
>>   // Do the steps for test case 1
>> </target>
>> <target name="test2">
>>   // Do the steps for test case 2
>> </target>
>> <target name="full-test">
>>   <http>
>>     // Do the login here
>>     <antcall target="test1"/>
>>     <antcall target="test2"/>
>>     // Do the logout here
>>   </http>
>> </target>
>> The <target> element acts as a function here, and you make use of
> <antcall>
>> to invoke it.
>> If you want to reuse functionality across multiple ant files, just define
>> the common functionality in targets in a common file, and call them using
>> the <ant> target.
> Which really slows down things sometimes and precludes the Ant dependency
> mechanism.

Why does it slow down things? Another build file should just parse and add
the targets to the pool of already existing targets. And since you're
calling the task directly, yes, you are avoiding the dependency mechanism,
but in this case this exactly what you want.

> I'm writing a simple xinclude system to patch Ant.
> Any suggestion on what to use to manage xinclude tags?

What would be the semantics of xinclude in the context of Ant? Suppose you
xinclude a target fragment inside the <project> element; this should create
a new target. But I imagine you could also xinclude a fragment inside a
target: this should only add whatever tasks are referred to that target.

If this is the semantics, then I'd say the xinclude element cannot be a
regular task. What you instead need is a special element which transparently
substitutes at _parse_ time XML fragments from other sources in the parsing


To unsubscribe, e-mail:
For additional commands, email:

View raw message