I agree with Todd, and it seems we cannot use sensorshellmap on command
line. We have never encountered such reqirement before in .net world.
Cheers -Cedric
Todd Olson wrote:
Apologies...I wasn't clear.
My issue is that the .NET wrapper wraps the command-line version of
Sensorshell. I use the SensorshellMap stuff in the SVN sensor and love
it (works great!). However, in the .NET world it's not so easy. The
IKVM stuff actually enables me to use it, but the wrapper does not
appear to support it.
Philip Johnson wrote:
--On Wednesday, June 01, 2005 9:40 PM -0400 Todd Olson
<[EMAIL PROTECTED]> wrote:
1. The whole usermaps.xml. SourceSafe is of course multi-user sensor
data.
sensorshell.jar supports the current user (based on sensor.props),
and i couldn't find
a way to override. Even if I could, it would mean instantiating a
process per user.
No, it's not a process per user (which of course would be bad), it's a
SensorShell
instance per user (which is no problem at all). Basically, your
sensor (a single Java
process) keeps a table of SensorShell instances and passes the data to
the appropriate
one depending upon which user the data belongs to. See the CVS or
Jira sensors for
examples.
2. Lose the dependence on Java. Frankly, pure .NET folks are put off
by Java.
Although, I don't find this to be a great reason, it is very real. I
would think that
it's more of an issue for me though than it is for the community at
large.
I'm a little surprised that you forecast a significant difference in
sales based upon
whether there is a client-side JVM or not; I've never heard of that
purchasing criteria
before. But given the Redmond FUD-making machine, I guess anything is
possible.
Cheers,
Philip
