On 2/27/06, Kathey Marsden <[EMAIL PROTECTED]> wrote: > > >derbytools.jar will automatically put derbyclient.jar in the > >classpath. Since you have derbytools.jar from trunk before > >derbyclient.jar version 10.1 in your classpath, derbyclient.jar will > >be shadowed. Sysinfo will however report that you are using the 10.1 > >version of derbyclient.jar, since it only sees the CLASSPATH variable. > > What Jira was this added under?
DERBY-1019 > Is this really a good idea? Only if you want to be able to execute one of the tools with java -jar derbytools.jar and be able to use it with a client connection without setting up the classpath. But now that I think about it, probably not since who knows how many people's applications already have classpath set up a particular way, although it's only a problem in a mixed jar environment. > It seems bad to me that I set up my CL:ASSPATH to get one client and > derbytools > decides to give me another one. Then with DERBY-668 sysinfo tells me I > have the one I want. It certainly underscores the need to get DERBY-668 fixed. And when it is fixed, we should take care that we show which jar is actually taking precedence. I hadn't considered the mixed jar environment, sorry, and I guess there's no choice but to take out the Class-Path attribute from derbytools.jar. Sadly, it cripples the spirit of 1019: there is then no direct path to using the tools and one must explain classpath before using the tools. Ah well, so it goes... andrew
