On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
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
