Daniel John Debrunner wrote:
Julius Stroffek wrote:
I have only two solutions to this:
1.) Change the visibility of required classes to public.
2.) Maintain the parallel package tree (suggested by Krisitian) with
implementation of tests of private classes. The tests will be in a
same package but different source directory. The build system will
manage to place the tests to derbyTesting.jar only. According the
docs, the class loader should choose the correct jar file to load a
class (if the jar sealing is turned off). I'll check this.
Since changing the visibility of code is not desired I see the option
2 as the preferred one. Are there any other possibilities? What are
your opinions?
Both solutions are affecting the visibility of code. Option 2) is
removing the option of sealing *all* the classes in that package, thus
defeating any package access protection.
If the testing really is just for a specific class, then it does not
matter that the class is in one of the derby "product" jars. So a couple
of variants of 2) are:
- test only when running tests from the classpath
- archive the class into another jar where it is not sealed and run the
tests against with that jar in the classpath and none of the derby
"product" jars.
How about only sealing insane jars? Then we could run such tests
against sane jars.
--
Øystein
