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.
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.
