On 2/27/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
Andrew McIntyre wrote:
>On 2/27/06, Kathey Marsden < [EMAIL PROTECTED]> wrote:
>
>
>>Daniel John Debrunner wrote:
>>
>>
>>>Isn't DERBY-1019 the correct place for this?
>>>
>>>
>>Or perhaps a separate issue created to autoload derbyclient.jar with
>>derbytools.jar. I certainly did not glean that impact from the
>>DERBY-1019 description. It would be nice to see it as a separate issue.
>>
>>
>
>I've filed DERBY-1063 for this.
>
>With the patch I've attached to DERBY-1063, this is what sysinfo looks
>like with 10.2 derbytools.jar and 10.1 derbyclient in the classpath,
>but with 10.2 derby.jar and derbyclient.jar in the same location as
>the 10.2 derbytools.jar. Kathey, is this output more acceptable? To
>me, it indicates that the derbyclient.jar was found first, and reports
>its version, but also reports the other derbyclient explicitly added
>to the classpath, later.
>
>
>
So from what I understand, your patch for DERBY-1063 will reintroduce
the DERBY-1045 regression that derbytools will load a different
derbyclient.jar than the one specificed by the user CLASSPATH but will
improve the sysinfo output . Is that correct? I am really very
uncomfortable with anything that requires CLASSPATH ordering or causes
one derby installation to affect another, but I'll think about it some
more. I'd like to hear what others think. Meanwhile could you say how
this would be documented. Maybe that would better help me to understand
the impact.
Kathey
If we're talking about making something easy to use, I would think this is confusing - which derbyclient.jar will it pick up?
If possible, it would be nice to have the jar that's getting picked up first listed at the top, and then another section, marked maybe by: "also found:" ....
Myrna
