Hi,
I checked the 10.2.2.0 release and all the .jar files in /lib directory
are not sealed. Do we plan to seal the jars in the future? If so, I
think that 'buildjars' target than could create the same jars twice -
one set for testing purposes only which will have the same content
except they will not be sealed.
Julo
Oystein Grovlen - Sun Norway wrote:
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.
