On 9/27/2011 5:21 AM, Rick Hillegas wrote:
This use-case would be satisfied by having a separate clone of sysinfo
for each of the jar files: sysinfoEngine, sysinfoClient, sysinfoTools.
I don't think that's a practical solution at this point. in addition to
support needing to ask the customer to run 5 commands to understand the
installed derby software, and confusing a lot of Derby users it breaks
a public API and the very first command we have always told users to
run with Derby.
I am sure we can find a technical solution that doesn't affect our
users. For JVMInfo I think it can safely be pulled out of use for
sysinfo and the duplication removed (DERBY-1046). I am willing to work
on that and get past the current issue. For sysinfo itself, the
separate and multiple copies should be fine.
For the others, e.g. ProductVersionHolder, I wonder if we could have
separate packages as you suggested earlier in this thread, determine
what jar the sysinfo class are using is loaded from ( I seem to recall
this is possible but can't recall the API. I also seem to recall
possible security manager concerns) and then use reflection to invoke
the correct one. I am not sure if this will all work, but just a thought.
Even if worst case we have to put everything needed for sysinfo into
the sysinfo class, we need to find a solution that keeps sysinfo and
doesn't turn it into multiple new commands.
Thanks
Kathey
