You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/03/14 12:06:57 UTC
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. 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 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. Is this a
candidate for a maven profile? Or is there another mechanism for runinning
the generator occasionally?
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
Re: svn move, was: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/16/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> > Ah, apollogies for that. I have to admit that I'm a cvs person at
> > heart so
> > just getting to grips with svn. I ljust ooked up svn move and got
> > that "why
> > didn't I look there first" feeling, so I'll remember that for next
> > time.
> > Thanks for taking the time to explain.
>
> If you're new to Subversion I highly recommend reading this:
> http://svnbook.red-bean.com/
>
> There's an Appendix on "Subversion for CVS Users" :-)
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Cool. Thanks Jeremy
Re: svn move, was: Databinding itest reorg proposal
Posted by Jeremy Boynes <jb...@apache.org>.
> Ah, apollogies for that. I have to admit that I'm a cvs person at
> heart so
> just getting to grips with svn. I ljust ooked up svn move and got
> that "why
> didn't I look there first" feeling, so I'll remember that for next
> time.
> Thanks for taking the time to explain.
If you're new to Subversion I highly recommend reading this:
http://svnbook.red-bean.com/
There's an Appendix on "Subversion for CVS Users" :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: svn move, was: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/15/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
> > I forgot to mention that the reason that so many XML files have
> > suddenly
> > appeared is that I've take the files that currently live in /
> > interop and
> > renamed and refactored them.
>
> Thanks for explaining as this did look a bit odd.
>
> One way to avoid that is to use "svn move" to move the files rather
> than adding them again. When you do that, SVN shows that the file was
> copied from somewhere else in the repo and so it is fairly clear that
> it isn't a new work but just a derivative. This also has the
> advantage that the history of the file is maintained so users can
> track changes even across the move. It has an even bigger benefit in
> that it makes life easier for the lawyers, and a happy lawyer is much
> nicer to have than a grumpy one :-)
>
> Some IDEs which grew up with CVS don't seem to realize that SVN
> allows them to just move things rather than delete old and add new
> (losing history in the process). If that's the case, then you can
> still get the benefits of moving through the svn command.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ah, apollogies for that. I have to admit that I'm a cvs person at heart so
just getting to grips with svn. I ljust ooked up svn move and got that "why
didn't I look there first" feeling, so I'll remember that for next time.
Thanks for taking the time to explain.
Regards
Simon
svn move, was: Databinding itest reorg proposal
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 15, 2007, at 3:34 PM, Simon Laws wrote:
> I forgot to mention that the reason that so many XML files have
> suddenly
> appeared is that I've take the files that currently live in /
> interop and
> renamed and refactored them.
Thanks for explaining as this did look a bit odd.
One way to avoid that is to use "svn move" to move the files rather
than adding them again. When you do that, SVN shows that the file was
copied from somewhere else in the repo and so it is fairly clear that
it isn't a new work but just a derivative. This also has the
advantage that the history of the file is maintained so users can
track changes even across the move. It has an even bigger benefit in
that it makes life easier for the lawyers, and a happy lawyer is much
nicer to have than a grumpy one :-)
Some IDEs which grew up with CVS don't seem to realize that SVN
allows them to just move things rather than delete old and add new
(losing history in the process). If that's the case, then you can
still get the benefits of moving through the svn command.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/15/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 3/15/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >
> > On 3/15/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > >
> > > [snip]
> > > Simon Laws wrote:
> > > >>
> > > >> >> 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?
> > > >
> > > As always, there's probably many ways to do it, but here's one way.
> > >
> > > Add this to your pom:
> > > <dependency>
> > > <groupId>...</groupId>
> > > <artifactId>common</artifactId>
> > > <version>...</version>
> > > <scope>test</scope>
> > > </dependency>
> > >
> > > Put abc.wsdl in common/src/main/resources.
> > >
> > > And in your test case:
> > > getClass().getClassLoader().getResourceAsStream(" abc.wsdl")
> > >
> > > Hope this helps.
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > Thanks Jean-Sebastien.
> >
> > This might be useful actually. The direction I took was to add a
> > dependency with common and then unpack common into the test project.
> >
> > I also decided to try out your suggestion of running the test generation
> > every time. Getting everything in the right place at the right time has been
> > interesting and I know a lot more about maven now! There must be easier ways
> > of doing this though.
> >
> > Basically the scheme is that common holds all the XSDs, generation
> > templates and a small program that reads a configuration file and runs the
> > templates. The test projects (i've only been playing with SDO at present -
> > see sdogen) have nothing in them apart from the generation configuration
> > file and the pom. The pom reads the configuration files generates the test,
> > compiles it an runs it.
> >
> > The wrinkle at the moment is that when you change the configuration file
> > to add more types to a test project you have to run maven twice in that test
> > project This is because the test generation step generates the pom itself
> > (the pom directs the SDO generation processing and has to have lines
> > generated into it). The second time you run it you pick up the newly
> > generated pom and the test should run as intended. You then check this new
> > pom and carry on.
> >
> > Looking at your suggested code above I expect we can actually do all the
> > hard work in the generate program and also drive the sdo generation step
> > from here. This would remove the need to generate the pom and hence the need
> > to run maven twice when you update the config file. Anyhow I didn't really
> > want to make a career out of building test generators so it can probably
> > stay as it is for the time being. The next task is to do the real testing.
> >
> > I haven't included this generation stuff in the databindings pom some
> > hopefully you will see no different when running tests at present. You can
> > run it though just by referencing common and sdogen.
> >
> > Regards
> >
> > Simon
> >
> >
> > I forgot to mention that the reason that so many XML files have suddenly
> appeared is that I've take the files that currently live in /interop and
> renamed and refactored them. Still needs more work but gives us plenty to
> test with. Still have more to pull in from CTS and SDO if we want also. I'm
> not committed to leaving these all in the databindings/common project
> because whatever the final set of XSDs we come up with I'm sure they have
> wider applicability. However my maven skills aren't sufficiently honed to
> get it all to hang together from /interop so we can move them to a more
> suitable place in the future. This is really something we need to do in head
> rather than the integration branch so I'm keeping an open mind at the
> moment. Primarily, having been through them once, I wanted to get a safe
> copy of them.
>
> Regards
>
> Simon
>
Have been finishing off the databinding itests in the integration branch
(just happened to be where the code was) but would rather that these were
working against the latest code in the trunk. Need to spend some time today
going through and checking which XSDs are actually going to be tested but
after that would like to move this over and try it against the trunk code
and check it in. I'm assuming it can go in the same place i.e.
tuscany/java/itest/databindings. If anyone sees any problems with doing this
let me know.
Regards
Simon
Re: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/15/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 3/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > Simon Laws wrote:
> > >>
> > >> >> 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?
> > >
> > As always, there's probably many ways to do it, but here's one way.
> >
> > Add this to your pom:
> > <dependency>
> > <groupId>...</groupId>
> > <artifactId>common</artifactId>
> > <version>...</version>
> > <scope>test</scope>
> > </dependency>
> >
> > Put abc.wsdl in common/src/main/resources.
> >
> > And in your test case:
> > getClass().getClassLoader().getResourceAsStream(" abc.wsdl")
> >
> > Hope this helps.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> Thanks Jean-Sebastien.
>
> This might be useful actually. The direction I took was to add a
> dependency with common and then unpack common into the test project.
>
> I also decided to try out your suggestion of running the test generation
> every time. Getting everything in the right place at the right time has been
> interesting and I know a lot more about maven now! There must be easier ways
> of doing this though.
>
> Basically the scheme is that common holds all the XSDs, generation
> templates and a small program that reads a configuration file and runs the
> templates. The test projects (i've only been playing with SDO at present -
> see sdogen) have nothing in them apart from the generation configuration
> file and the pom. The pom reads the configuration files generates the test,
> compiles it an runs it.
>
> The wrinkle at the moment is that when you change the configuration file
> to add more types to a test project you have to run maven twice in that test
> project This is because the test generation step generates the pom itself
> (the pom directs the SDO generation processing and has to have lines
> generated into it). The second time you run it you pick up the newly
> generated pom and the test should run as intended. You then check this new
> pom and carry on.
>
> Looking at your suggested code above I expect we can actually do all the
> hard work in the generate program and also drive the sdo generation step
> from here. This would remove the need to generate the pom and hence the need
> to run maven twice when you update the config file. Anyhow I didn't really
> want to make a career out of building test generators so it can probably
> stay as it is for the time being. The next task is to do the real testing.
>
> I haven't included this generation stuff in the databindings pom some
> hopefully you will see no different when running tests at present. You can
> run it though just by referencing common and sdogen.
>
> Regards
>
> Simon
>
>
> I forgot to mention that the reason that so many XML files have suddenly
appeared is that I've take the files that currently live in /interop and
renamed and refactored them. Still needs more work but gives us plenty to
test with. Still have more to pull in from CTS and SDO if we want also. I'm
not committed to leaving these all in the databindings/common project
because whatever the final set of XSDs we come up with I'm sure they have
wider applicability. However my maven skills aren't sufficiently honed to
get it all to hang together from /interop so we can move them to a more
suitable place in the future. This is really something we need to do in head
rather than the integration branch so I'm keeping an open mind at the
moment. Primarily, having been through them once, I wanted to get a safe
copy of them.
Regards
Simon
Re: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/15/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Simon Laws wrote:
> >>
> >> >> 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?
> >
> As always, there's probably many ways to do it, but here's one way.
>
> Add this to your pom:
> <dependency>
> <groupId>...</groupId>
> <artifactId>common</artifactId>
> <version>...</version>
> <scope>test</scope>
> </dependency>
>
> Put abc.wsdl in common/src/main/resources.
>
> And in your test case:
> getClass().getClassLoader().getResourceAsStream("abc.wsdl")
>
> Hope this helps.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Thanks Jean-Sebastien.
This might be useful actually. The direction I took was to add a dependency
with common and then unpack common into the test project.
I also decided to try out your suggestion of running the test generation
every time. Getting everything in the right place at the right time has been
interesting and I know a lot more about maven now! There must be easier ways
of doing this though.
Basically the scheme is that common holds all the XSDs, generation templates
and a small program that reads a configuration file and runs the templates.
The test projects (i've only been playing with SDO at present - see sdogen)
have nothing in them apart from the generation configuration file and the
pom. The pom reads the configuration files generates the test, compiles it
an runs it.
The wrinkle at the moment is that when you change the configuration file to
add more types to a test project you have to run maven twice in that test
project This is because the test generation step generates the pom itself
(the pom directs the SDO generation processing and has to have lines
generated into it). The second time you run it you pick up the newly
generated pom and the test should run as intended. You then check this new
pom and carry on.
Looking at your suggested code above I expect we can actually do all the
hard work in the generate program and also drive the sdo generation step
from here. This would remove the need to generate the pom and hence the need
to run maven twice when you update the config file. Anyhow I didn't really
want to make a career out of building test generators so it can probably
stay as it is for the time being. The next task is to do the real testing.
I haven't included this generation stuff in the databindings pom some
hopefully you will see no different when running tests at present. You can
run it though just by referencing common and sdogen.
Regards
Simon
Re: Databinding itest reorg proposal
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
>>
>> >> 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?
>
As always, there's probably many ways to do it, but here's one way.
Add this to your pom:
<dependency>
<groupId>...</groupId>
<artifactId>common</artifactId>
<version>...</version>
<scope>test</scope>
</dependency>
Put abc.wsdl in common/src/main/resources.
And in your test case:
getClass().getClassLoader().getResourceAsStream("abc.wsdl")
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Databinding itest reorg proposal
Posted by Simon Laws <si...@googlemail.com>.
On 3/15/07, Jean-Sebastien Delfino <js...@apache.org> 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"
> > <si...@googlemail.com>
> > To: "tuscany-dev" <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Databinding itest reorg proposal
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Simon Laws"
> <si...@googlemail.com>
> To: "tuscany-dev" <tu...@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?
>>
>> 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?
>> 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.
>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Databinding itest reorg proposal
Posted by Raymond Feng <en...@gmail.com>.
+1.
"transformers" could go under "interop" because it's there to test
transformations across databindings at the transformer level.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: "tuscany-dev" <tu...@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. 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 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. Is this
> a
> candidate for a maven profile? Or is there another mechanism for runinning
> the generator occasionally?
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org