On 9/26/11 2:22 PM, Kathey Marsden wrote:
On 9/26/2011 11:13 AM, Rick Hillegas wrote:
Can you refresh my memory: why is sysinfo included in all of our
jars? Why can't we ask people to wire in the tools jar if they want
to run sysinfo? I think sysinfo was thought to be stable but because
it uses classes like JVMInfo that are used for other things, it is
not. How would this plan work in relation to the single sysinfo
invocation?
This practice predates me, but I am pretty sure it is because sysinfo
is/was the primary tool for verifying proper classpath settings and
collecting information for support regarding what jars and versions
are being used and for what versions, jvm, os information, etc. Many
(most?) applications do not deploy derbytools.jar, so it doesn't make
sense to require that jar be installed or the classpath you are trying
to diagnose be changed to include it in a support situation.
This use-case would be satisfied by having a separate clone of sysinfo
for each of the jar files: sysinfoEngine, sysinfoClient, sysinfoTools.
Thanks,
-Rick
I reopened DERBY-1046 to remove the JVMInfo duplication which I think
was closed accidentally. I think this class changes too frequently to
be expected to be stable and part of sysinfo. If a bit of code needs
duplication in sysinfo, then that seems the way to go.
ProductVersionHolder might need something more elaborate.
