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
