On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

Comments inline

Raymond Feng wrote:
> +1.
>
> "transformers" could go under "interop" because it's there to test
> transformations across databindings at the transformer level.
>

+1 from me, I'm assuming you meant move the tests currently in
transformer to interop and not creating interop/transformer.


I'll  look at combining the transformer tests into interop

Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Laws"
> <[EMAIL PROTECTED]>
> To: "tuscany-dev" <tuscany-dev@ws.apache.org>
> Sent: Wednesday, March 14, 2007 4:06 AM
> Subject: Databinding itest reorg proposal
>
>
>> I think we need to reorg the itest directory for databinding a bit and
I
>> need some help to get the maven bit correct as I'm a bit of a maven
>> novice.
>> I'm looking at the integration branch at the moment as that is where
the
>> tests are checked in but I don't see why these tests can't go in the
>> trunk
>> also.
>>
>> Currently we have:
>>
>> itest
>>   databinding
>>       sdo
>>       jaxb
>>       transformers (not sure what this is but assume it tests the
>> data type
>> transformer logic)
>>
>> From previous threads on this subject, [1] and [2], we talked about
>> changing
>> to something like
>>
>> itest
>>   databinding
>>       generator
>>       common
>>       sdo
>>       jaxb
>>       interop
>>       transformers (not sure what this is but assume it tests the
>> data type
>> transformer logic)
>>
>> Where common holds xsd, wsdl and files generated from them that are
>> common
>> between the tests, interop holds tests that look at cross databinding
>> testing and generator holds a test generator. This chane means moving
>> most
>> of the WSDL and XML files from where they are now out into common and
>> also
>> replacing test source files with generated versions.
>>
>> Interop would depend on sdo and jaxb which in turn depend on common.
>> Can we
>> do this in maven simply by adding suitable dependency lines in the
>> module
>> poms.

Yes

>> In particular I will need to copy some schema and wsdl files from one
>> module to another.
>> I notice that various build helper plugins are used in
>> various poms. Is there a recommended one for  copying resources in from
>> dependencies.

I apologize if I missed it in an earlier thread but why would the build
need to copy the files around?


No problem. I wasn't very clear. The question was motivated by needing to
use all of the resource (XSDs etc) in the common module in  the other test
modules. I.e. I  want to use the same XSD across tests but don't want to
create manual copies=. How do the processors in each test access the common
resources?


>> I have created a test generator to build the test source and
>> configuration
>> automatically. As we have quite a number of datatypes to tests
>> (potentially
>> in the 100s) I made some velocity templates to create the 8 files
>> required
>> by the test. Initially I intended to throw the generator away having
>> run it
>> but now feel that it might be useful as we extend the tests. So I
>> want to
>> run it more than once but not every time the test is compiled/run.

Wouldn't it be simpler to just run it as part of the build and not check
in the generated tests, to make sure that they are always up to date?


I had originally though that parts of the test would have to be hand crafted
but I expect as we add more types this will be impractical so maybe you are
right.

Is this a
>> candidate for a maven profile? Or is there another mechanism for
>> runinning
>> the generator occasionally?
>>

I was looking for the generator but couldn't find it, can you point us
to it? Thanks.


Sorry about that. Am trying to check it in at the moment. Was just trying to
work out this resource dependency thing.


Regards
>>
>> Simon
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13947.html
>> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15261.html
>>
>


--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to