On 3/15/07, Simon Laws <[EMAIL PROTECTED]> wrote:
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
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
