Proposal for a (Java) community test suite for SDO

[Dan Murphy <dm...@googlemail.com>]

I would like to propose starting a community test suite for service data
objects (SDO CTS) implementations written in Java. Based on feedback from an
earlier post this seems to be the first logical step in getting
interoperable SDO implementations in all languages. I can see this leading
to an interoperability test suite to check serialisation between
implementations also works (across languages and implementations).

Proposal for Community Test Suite (CTS) for SDO
Develop a test suite to validate an SDO implementation behaves as expected,
according to the community's understanding of the SDO specification. Should
the specification appear ambiguous or unclear then the community will decide
what to do; it may decide to test the area with an agreed expected
behaviour, or decide not to test this area. Ambiguities will be fed back to
the specification group for clarification. Although we will run this against
Tuscany, the test suite will only test things that we think any
implementation should support.

The SDO CTS will enable developers to choose or switch SDO implementations
without the concern of having to re-code a significant proportion of their
application due to differences between implementations. This community test
suite will first  focus on areas identified important to developers of SDO
applications. SDO users feedback and involvement will be crucial to the
success of this effort. Over time this may grow to include a large
proportion of the SDO specification, however the suite should grow according
to the community's desire, rather than attempting to be a validation or
compliancy suite.

To encourage everyone with an interest in SDO to contribute and use the
suite, I propose we :

   1. Create a separate module in SVN to separate this from Tuscany
   components and testcases.
   2. Make use of a java package namespace that is not attributable to
   either Tuscany or any other SDO implementation: test.sdo
   3. Refactor some of the existing Tuscany SDO Java test cases to remove
   any Tuscany specific coding and re-package these to the test.sdo
   namespace.
   4. Accept tests from anyone who wishes to contribute them under normal
   Apache contribution conditions.


SDO users involvement will be crucial to this effort, developers of SDO
implementations will benefit by contributing to and consuming a community
test suite, rather than working on their own.

Who's up for working on this with me ?

If you are interested in joining this effort; have any concerns, comments or
suggestions please append them...

Thanks in advance to all those who volunteer :)
Dan

Re: Proposal for a (Java) community test suite for SDO

[Simon Laws <si...@googlemail.com>]

On 12/1/06, Dan Murphy <dm...@googlemail.com> wrote:
>
> Hi Simon,
> Yes, I do think and hope that some of this work will be useful to all &
> not
> just the Java folks :)
> I'm sure that the Java CTS would need to include tests that serialise to
> and
> from xml documents and XSDs. These could be re-used to test different
> language implementations (or based on what is in the existing interop
> suite).
> I've not done any C++ for 7 years (even then I was a novice). So, if
> you're
> volunteering to collaborate on the C++ or PHP side, I'm sure we can
> enhance
> them and get a richer set of interop tests if needed. It would be daft to
> duplicate tests in both interop and a Java SDO CTS :)
> As you say, passing serialised SDO would be core for cross language
> tests...
> I don't think we want to get into JNI from java into C++ passing SDOs 'cos
> I
> don't envisage people doing this.
>
> Cheers for the comments
> Dan
>
> yes - happy to help with any of the cross language stuff. Previously it
was really difficulty switching my mind into Java mode to run the java side
of things so having a Java SDO expert on the case will be excellent.

Simon

Re: Proposal for a (Java) community test suite for SDO

[Dan Murphy <dm...@googlemail.com>]

Hi Simon,
Yes, I do think and hope that some of this work will be useful to all & not
just the Java folks :)
I'm sure that the Java CTS would need to include tests that serialise to and
from xml documents and XSDs. These could be re-used to test different
language implementations (or based on what is in the existing interop
suite).
I've not done any C++ for 7 years (even then I was a novice). So, if you're
volunteering to collaborate on the C++ or PHP side, I'm sure we can enhance
them and get a richer set of interop tests if needed. It would be daft to
duplicate tests in both interop and a Java SDO CTS :)
As you say, passing serialised SDO would be core for cross language tests...
I don't think we want to get into JNI from java into C++ passing SDOs 'cos I
don't envisage people doing this.

Cheers for the comments
Dan

Re: Proposal for a (Java) community test suite for SDO

[Simon Laws <si...@googlemail.com>]

On 11/30/06, Dan Murphy <dm...@googlemail.com> wrote:
>
> I would like to propose starting a community test suite for service data
> objects (SDO CTS) implementations written in Java. Based on feedback from
> an
> earlier post this seems to be the first logical step in getting
> interoperable SDO implementations in all languages. I can see this leading
> to an interoperability test suite to check serialisation between
> implementations also works (across languages and implementations).
>
> Proposal for Community Test Suite (CTS) for SDO
> Develop a test suite to validate an SDO implementation behaves as
> expected,
> according to the community's understanding of the SDO specification.
> Should
> the specification appear ambiguous or unclear then the community will
> decide
> what to do; it may decide to test the area with an agreed expected
> behaviour, or decide not to test this area. Ambiguities will be fed back
> to
> the specification group for clarification. Although we will run this
> against
> Tuscany, the test suite will only test things that we think any
> implementation should support.
>
> The SDO CTS will enable developers to choose or switch SDO implementations
> without the concern of having to re-code a significant proportion of their
> application due to differences between implementations. This community
> test
> suite will first  focus on areas identified important to developers of SDO
> applications. SDO users feedback and involvement will be crucial to the
> success of this effort. Over time this may grow to include a large
> proportion of the SDO specification, however the suite should grow
> according
> to the community's desire, rather than attempting to be a validation or
> compliancy suite.
>
> To encourage everyone with an interest in SDO to contribute and use the
> suite, I propose we :
>
>    1. Create a separate module in SVN to separate this from Tuscany
>    components and testcases.
>    2. Make use of a java package namespace that is not attributable to
>    either Tuscany or any other SDO implementation: test.sdo
>    3. Refactor some of the existing Tuscany SDO Java test cases to remove
>    any Tuscany specific coding and re-package these to the test.sdo
>    namespace.
>    4. Accept tests from anyone who wishes to contribute them under normal
>    Apache contribution conditions.
>
>
> SDO users involvement will be crucial to this effort, developers of SDO
> implementations will benefit by contributing to and consuming a community
> test suite, rather than working on their own.
>
> Who's up for working on this with me ?
>
> If you are interested in joining this effort; have any concerns, comments
> or
> suggestions please append them...
>
> Thanks in advance to all those who volunteer :)
> Dan
>
> Hi Dan

"a community test suite for service data objects (SDO CTS) implementations
written in Java". I can see why you need to a test suite the test Java
implementations but do you believe that some of this work will be useful to
other language implementations also. We've talked before about the interop
schemas up on SVN in the interop directory. If, for example, in your new
effort the community decided that it would be a nice idea to test that SDO
load and saves XML files based on schema that reflect the mappings defined
in the specs (something I would imagine that you would be interested in)
then it would be good if you can take what we have and enhance or replace
them. This would then be useful in a context wider than Java because we use
these tests in C++ and PHP SDO also. If you were able to make improvements
here that would be work we wouldn't have to duplicate. Are there any other
SDO tests that you think we could collaborate on cross langauge? For
example, clearly API tests would be difficult :-) but how about
serialisation of data objects trees and/or change summaries?

Regards

Simon

Re: Maven running in Tomcat?

[Jeremy Boynes <jb...@apache.org>]

There is a context parameter "tuscany.online" which defaults to true -
if you set this to false in webapp.xml then it should disable this
behaviour.

--
Jeremy

On 11/30/06, Matthew Duftler <du...@us.ibm.com> wrote:
> Hi Folks,
>
> When I deploy a Tuscany sample to Tomcat, I see what looks like Maven
> trying to update its repository.
>
> Is there a way to disable this behavior? (Something akin to maven's '-o'
> command-line option maybe...)
>
> Thanks,
> -Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Maven running in Tomcat?

[Matthew Duftler <du...@us.ibm.com>]

Hi Folks,

When I deploy a Tuscany sample to Tomcat, I see what looks like Maven
trying to update its repository.

Is there a way to disable this behavior? (Something akin to maven's '-o'
command-line option maybe...)

Thanks,
-Matt


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org