Re: [VOTE] Schematron validator in Anteater (and Cocoonvalidating Transformer)

[Ovidiu Predescu <ov...@apache.org>]

On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> wrote:

> 
> I will be interested to contribute some code.
> The validator package is totally independent of Avalon.

OK, this is good.

> It only needs commons-jxpath.jar
> 
> The package is org.apache.cocoon.components.validation
> 
> I guess I can just zip up the files in the package for anteater.

Anteater currently uses Jaxen, is it possible for the validation code to use
Jaxen instead of JXPath?

> I would like us to work out the exact syntax before starting, though.

I think the syntax you proposed is reasonable for a start.

> How do we plan to generate junit reports.
> Right now I don't see a nice way to interrupt a test, if there was a
> validation error, and jump straight to the junit reporting.

How does Junit catch the interrupt? We can probably use the same mechanism
to catch the interrupt, and execute the reporting code.

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

Does this answer your question?

> Once we work out the architectural problems, I'll move to coding.
> 
> My sf.net login is "ivelin"

OK, you're in!

Ovidiu


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (andCocoonvalidatingTransformer)

[Ovidiu Predescu <ov...@apache.org>]

On 6/9/02 11:17 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

> From: "Ovidiu Predescu" <ov...@apache.org>
> To: <co...@xml.apache.org>; <af...@lists.sourceforge.net>
> Sent: Monday, June 10, 2002 4:14 AM
> Subject: Re: [VOTE] Schematron validator in Anteater
> (andCocoonvalidatingTransformer)
> 
> 
>> On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>> 
>>> From: "Ovidiu Predescu" <ov...@apache.org>
>>>> 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 referred to "reuse functionality across multiple ant files".
> Since it's a generic statemement, I gave a generic answer ;-)

;)

> <ant> is not the root of all evil, but shoudn't be used just to "call build
> functions", but call sub builds.

<ant> is the only way you can load and execute test scripts dynamically at
runtime. Even with an xinclude facility, it would be very difficult to load
arbitrary build files, since xinclude would be executed at parse time, while
<ant> is evaluated at runtime.

To understand what I mean, take a look at test/anteater/all-tests.xml in
Cocoon. The main target determines, at runtime, what are all the test files,
and executes them accordingly. I don't think this would be possible with an
xinclude target, since <xinclude> would have to refer to known URLs at parse
time.

>>> 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
>> stream.
> 
> I would make a XIncludeProjectHelper, so I would intervene in the parsing
> stage.
> 
> What I would like to know, are there any separate xinclude implementations
> already?

I don't know, better ask on ant-dev about it. Also check the Sourceforge
Antcontrib project, they have a bunch of tasks which are not part of Ant.

Cheers,
Ovidiu


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (andCocoonvalidatingTransformer)

[Nicola Ken Barozzi <ni...@apache.org>]

From: "Ovidiu Predescu" <ov...@apache.org>
To: <co...@xml.apache.org>; <af...@lists.sourceforge.net>
Sent: Monday, June 10, 2002 4:14 AM
Subject: Re: [VOTE] Schematron validator in Anteater
(andCocoonvalidatingTransformer)


> On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
> > From: "Ovidiu Predescu" <ov...@apache.org>
> >> 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 referred to "reuse functionality across multiple ant files".
Since it's a generic statemement, I gave a generic answer ;-)

<ant> is not the root of all evil, but shoudn't be used just to "call build
functions", but call sub builds.

> > 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
> stream.

I would make a XIncludeProjectHelper, so I would intervene in the parsing
stage.

What I would like to know, are there any separate xinclude implementations
already?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (and CocoonvalidatingTransformer)

[Ovidiu Predescu <ov...@apache.org>]

On 6/9/02 2:36 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:

> From: "Ovidiu Predescu" <ov...@apache.org>
> 
>> On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> 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
stream.

Regards,
Ovidiu


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Schematron validator in Anteater (and CocoonvalidatingTransformer)

[Nicola Ken Barozzi <ni...@apache.org>]

From: "Ovidiu Predescu" <ov...@apache.org>

> On 6/7/02 9:48 PM, "Ivelin Ivanov" <iv...@apache.org> 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.

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

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org