You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Dan Murphy <dm...@googlemail.com> on 2006/12/20 16:48:27 UTC
[SDO CTS] Testing statically generated classes
Hi,
Integrating Robbie's code (jira
http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general
problem for testing statically generated types. For example, statically
generated classes using Tuscany's SDO M2 implementation are not compatible
with the current SDO implementation (in this particular case the
org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists).
Further, the specification does not specify how to generate static classes
from schemas (it does specify what the resulting classes should looks like,
but not how to actually invoke the generator). One option would be to have a
maven task that invokes an implementations static generator prior to
compiling the code that depends on it, however this doesn't resolve all
probems.
With Tuscany it is necessary to register static type via the
SDOUtil.registerStaticTypes(staticFactory.class) or other method pending
jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this is
also necessary with other implementations.
I'd appreciate people comments on :
Whether the CTS should test static SDOs (I believe so) ?
This would mean we'd need to be able to delegate to different
implementation static class registration mechanisms (some form of
adaptor/abstraction layer)
Whether Maven'ize the SDO CTS is desired ?
How best to allow different implementations to be selected in the pom
would be interesting
This would also require additional maven plugins to allow different
implementation generators to be invoked or additional steps in the pom to
directly invoke different generators
If not maven we could automate with different ant scripts for different
implementations (or have "users" edit a general ant script)
The downside of this is that the ant script would need to know the
location of the implementation JARs
I hope we'd all agree on the first point, but I think the second two could
open up some interesting discussions.
Many thanks in advance,
Dan
Re: [SDO CTS] Testing statically generated classes
Posted by Robbie Minshall <my...@gmail.com>.
I have converted our other test cases to junit 4.1 and am in the process of
doing some cleaning up etc. Will send out a quick update tonight and can
integrate into tuscany if needed.
* * * Whether the CTS should test static SDOs (I believe so) ? * * *
Optional means to supply static class generator and/or previously generated
static classes would be good.
As a note we are moving our test cases to use a generator task rather than
checking in previously generated classes - just is not working right now so
we checked in manually generated classes for the shortterm.
? What is the outlook for spec group clarifying static SDO generation ?
? Should there be any backwards compatability requirements for static SDO
generation for tuscany implementation ( tests would not be contained within
CTS ) ?
* * * Whether Maven'ize the SDO CTS is desired ? * * *
I would imagine that the Tuscany community would like this mavenized.
Currently I just work simply using ant.
I was imaginging that one would provide a build.xml or pom.xml with an
example configuration for an implementation ( tuscany would make sense since
that is where this is getting hosted ) and other vendors could simple update
with configuration for their implementation. Other vendors could supply
their own maven plugins if necessary and we could provide a general plugin
which invokes listed generator class with command line style arguments.
If using ant then classpath can be setup in xml file and vendors can provide
their own or edit appropiately.
Robbie
On 12/20/06, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> I think the CTS should test static SDOs, but maybe it should be a separate
> optional part and maybe even a lower priority to focus on.
>
> As you point out, the SDO spec doesn't define how generators work, how
> static metadata is registered, or even how to create instances statically
> - according to the spec, the only way to create instances would be
> dynamically with DataFactory.create(MyStaticType.class). Given all the
> missing details, it will be hard to write static tests that test that much
> and are also not Tuscany specific.
>
> One thing that may be good is to just provide a mechanism for someone to
> plug in static implementations of one or more of the models used in the
> dynamic test suite, allowing them to run the same dynamic tests against
> their statically generated implementation classes.
>
> Frank.
>
> "Dan Murphy" <dm...@googlemail.com> wrote on 12/20/2006 10:48:27 AM:
>
> > Hi,
> >
> > Integrating Robbie's code (jira
> > http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general
> > problem for testing statically generated types. For example, statically
> > generated classes using Tuscany's SDO M2 implementation are not
> compatible
> > with the current SDO implementation (in this particular case the
> > org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists).
> >
> > Further, the specification does not specify how to generate static
> classes
> > from schemas (it does specify what the resulting classes should looks
> like,
> > but not how to actually invoke the generator). One option would be to
> have a
> > maven task that invokes an implementations static generator prior to
> > compiling the code that depends on it, however this doesn't resolve all
> > probems.
> >
> > With Tuscany it is necessary to register static type via the
> > SDOUtil.registerStaticTypes(staticFactory.class) or other method pending
> > jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this
> is
> > also necessary with other implementations.
> >
> > I'd appreciate people comments on :
> > Whether the CTS should test static SDOs (I believe so) ?
> > This would mean we'd need to be able to delegate to different
> > implementation static class registration mechanisms (some form of
> > adaptor/abstraction layer)
> > Whether Maven'ize the SDO CTS is desired ?
> > How best to allow different implementations to be selected in the pom
> > would be interesting
> > This would also require additional maven plugins to allow different
> > implementation generators to be invoked or additional steps in the pom
> to
> > directly invoke different generators
> > If not maven we could automate with different ant scripts for different
> > implementations (or have "users" edit a general ant script)
> > The downside of this is that the ant script would need to know the
> > location of the implementation JARs
> >
> > I hope we'd all agree on the first point, but I think the second two
> could
> > open up some interesting discussions.
> >
> > Many thanks in advance,
> > Dan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/83388211@N00/sets/
Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com
* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517
* * * Number * * *
919-225-1553
Re: [SDO CTS] Testing statically generated classes
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I think the CTS should test static SDOs, but maybe it should be a separate
optional part and maybe even a lower priority to focus on.
As you point out, the SDO spec doesn't define how generators work, how
static metadata is registered, or even how to create instances statically
- according to the spec, the only way to create instances would be
dynamically with DataFactory.create(MyStaticType.class). Given all the
missing details, it will be hard to write static tests that test that much
and are also not Tuscany specific.
One thing that may be good is to just provide a mechanism for someone to
plug in static implementations of one or more of the models used in the
dynamic test suite, allowing them to run the same dynamic tests against
their statically generated implementation classes.
Frank.
"Dan Murphy" <dm...@googlemail.com> wrote on 12/20/2006 10:48:27 AM:
> Hi,
>
> Integrating Robbie's code (jira
> http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general
> problem for testing statically generated types. For example, statically
> generated classes using Tuscany's SDO M2 implementation are not
compatible
> with the current SDO implementation (in this particular case the
> org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists).
>
> Further, the specification does not specify how to generate static
classes
> from schemas (it does specify what the resulting classes should looks
like,
> but not how to actually invoke the generator). One option would be to
have a
> maven task that invokes an implementations static generator prior to
> compiling the code that depends on it, however this doesn't resolve all
> probems.
>
> With Tuscany it is necessary to register static type via the
> SDOUtil.registerStaticTypes(staticFactory.class) or other method pending
> jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this
is
> also necessary with other implementations.
>
> I'd appreciate people comments on :
> Whether the CTS should test static SDOs (I believe so) ?
> This would mean we'd need to be able to delegate to different
> implementation static class registration mechanisms (some form of
> adaptor/abstraction layer)
> Whether Maven'ize the SDO CTS is desired ?
> How best to allow different implementations to be selected in the pom
> would be interesting
> This would also require additional maven plugins to allow different
> implementation generators to be invoked or additional steps in the pom
to
> directly invoke different generators
> If not maven we could automate with different ant scripts for different
> implementations (or have "users" edit a general ant script)
> The downside of this is that the ant script would need to know the
> location of the implementation JARs
>
> I hope we'd all agree on the first point, but I think the second two
could
> open up some interesting discussions.
>
> Many thanks in advance,
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [SDO CTS] Testing statically generated classes
Posted by Frank Budinsky <fr...@ca.ibm.com>.
I think the CTS should test static SDOs, but maybe it should be a separate
optional part and maybe even a lower priority to focus on.
As you point out, the SDO spec doesn't define how generators work, how
static metadata is registered, or even how to create instances statically
- according to the spec, the only way to create instances would be
dynamically with DataFactory.create(MyStaticType.class). Given all the
missing details, it will be hard to write static tests that test that much
and are also not Tuscany specific.
One thing that may be good is to just provide a mechanism for someone to
plug in static implementations of one or more of the models used in the
dynamic test suite, allowing them to run the same dynamic tests against
their statically generated implementation classes.
Frank.
"Dan Murphy" <dm...@googlemail.com> wrote on 12/20/2006 10:48:27 AM:
> Hi,
>
> Integrating Robbie's code (jira
> http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general
> problem for testing statically generated types. For example, statically
> generated classes using Tuscany's SDO M2 implementation are not
compatible
> with the current SDO implementation (in this particular case the
> org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists).
>
> Further, the specification does not specify how to generate static
classes
> from schemas (it does specify what the resulting classes should looks
like,
> but not how to actually invoke the generator). One option would be to
have a
> maven task that invokes an implementations static generator prior to
> compiling the code that depends on it, however this doesn't resolve all
> probems.
>
> With Tuscany it is necessary to register static type via the
> SDOUtil.registerStaticTypes(staticFactory.class) or other method pending
> jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this
is
> also necessary with other implementations.
>
> I'd appreciate people comments on :
> Whether the CTS should test static SDOs (I believe so) ?
> This would mean we'd need to be able to delegate to different
> implementation static class registration mechanisms (some form of
> adaptor/abstraction layer)
> Whether Maven'ize the SDO CTS is desired ?
> How best to allow different implementations to be selected in the pom
> would be interesting
> This would also require additional maven plugins to allow different
> implementation generators to be invoked or additional steps in the pom
to
> directly invoke different generators
> If not maven we could automate with different ant scripts for different
> implementations (or have "users" edit a general ant script)
> The downside of this is that the ant script would need to know the
> location of the implementation JARs
>
> I hope we'd all agree on the first point, but I think the second two
could
> open up some interesting discussions.
>
> Many thanks in advance,
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org