> For background, my project uses JDO so in my dependencies I specify the SUN
> reference implementation (for building that is all that is needed). At
> runtime I need to specify an actual implementation of JDO to run against.
> Really the project is not dependent on any particular implementation of
> JDO, so I have refrained from adding an implementation like Kodo, or TJDO
> to the dependencies of the project. What I would like to do (in an ideal
> world :-) is run the tests once with Kodo, once with TJDO, etc so I can say
> that I have test coverage against particular implementations.
>
> Is there a way to add the implementation jar(s) to JUnit's classpath
> without having to put it in the project (build) dependencies ?
Having read a bit of history regarding this area I gather Michal was looking
at updating the <dependency> tags so that you could notate whether a
dependency is for build or for test (is this true ? and did this come to
anything Michal?). After more thought I feel that what would really be
required could be something like the following ...
1. Either add a new element to the POM called <test> (hence separating
<build>, and <test> into functionally separate blocks), or add an element
under <build> called <unitTests>
<unitTests>
<unitTest>
<name>Test using Kodo</name>
<resources>
<resource>
... (as now, for properties/xml files)
</resource>
</resources>
<dependencies>
<dependency>
... (for jars)
</dependency>
</dependencies>
</unitTest>
<unitTest>
...
</unitTest>
</unitTests>
With this structure the user would be able to define a series of test
configurations ... so in my case I could test 'the system' against Kodo in
configuration 1, test against TJDO in configuration 2, etc etc. In the same
way people could test a project against one particular DB in configuration 1,
test against another DB in configuration 2, etc - hence they have coverage
for several configurations. I personally favour having the above in a
separate element outside of <build> because for any project you want to build
it, and you want to unit test it, and you want to run reports on it - so they
(should) have their own sections of the POM - if you take this further you
could argue that the <dependencies> section belongs under <build>, but lets
not go there yet ;-)
2. The "maven-test-plugin" would clearly also need modifications to have an
outer loop around the test configurations, and to insert the dependencies
into the classpath for each test configuration. In fact it may be worth
leaving the maven-test-plugin alone so that people can continue to have the
<unitTest> element under <build>, and have a new plugin
"maven-testconfiguration-plugin" for the above handling.
My questions are
1. do people think this would be useful ?
2. do you feel the proposed schema changes are the optimum e.g naming of tags,
effect on older schemas, effect on other plugins (e.g clover, jcoverage) ?
3. is there a better alternative ?
4. are you all happy to just continue lumping all build and test dependencies
into the <dependencies> section as now even though you can deploy your
project in a particular configuration that would render some (test)
dependency jars irrelevant ?
--
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
