Greetings, Todd, Interesting approach! I see the following issues to be resolved before this would become viable in the context of the overall project:
(a) Quoting its website, IKVM is "a JVM for Mono and the .NET framework... [The goal is to] be compatible with Sun's JDK 1.4 reference implementation. At the moment we're not quite there yet" IKVM thus raises a number of risks: (a) since it doesn't really implement 1.4, we may run into problems with it; (b) we will have to monitor and test IKVM releases, and (c) within six months, I want to start rewriting Hackystat to take advantage of Java 5. There are a number of binary incompatibilities (<http://java.sun.com/j2se/1.5.0/compatibility.html#incompatibilities>) which might become problematic if we need to support a 1.4-based JVM (IKVM) as well as a 1.5-based JVM. (b) Putting the SDTs on the client side (.hackystat/sdt) will create configuration problems, since different configurations of Hackystat support different SDTs and the SDT implementations change over time. I know that we created a "wrapper" around sensorshell.jar that is used by both the Office and Visual Studio sensors. This approach does not suffer from the issues I note above. Perhaps if you explained what problems prevent you from using the wrapper-based approach, we could investigate if there is a way to make the wrapper accomodate your situation as well. Cheers, Philip --On Wednesday, June 01, 2005 6:37 PM -0400 Todd Olson <[EMAIL PROTECTED]> wrote:
Greetings Hackers, I wanted to get some feedback from the community. In an effort to implement a sensor for Visual SourceSafe, I've successfully created a native .NET sensorshell using IKVM (http://www.ikvm.net). Here is some feedback on the compilation/usage for those who are interested: -- There are a number of warnings that are generated because some sensor classes are included in sensorshell.jar despite the lack of dependent JARs. No matter -- none of this code is typically ever called. However don't call it yourself! -- The biggest challenge is loading SDTs, since the conversion of "loading from a JAR" simply didn't work. I'm not sure if there is a .NET equivalent capability, but regardless IKVM doesn't support it. I modifed SDTManager to load from ${user.home}/.hackystat/sdt...(more on this below). -- You must add a few assemblies to your GAC (see IKVM website for info). Depends on GNU Classpath (open-source Java library)...not sure if this has other negative ramifications yet... -- In your app, you'll need to write a quick converter between .NET DateTime and java.util.Date. (I'd be happy to contribute this too). Advantages ** No dependencies on JVM/JARS. ** Simply include sensorshell.exe as a reference to your project in your .NET IDE. ** Supports all the features with full control of the API, including the usermaps stuff. ** sensorshell.exe runs from the command-line just as sensorshell.jar (one small issue with the version number display in the command-line version) SDT Loading As mentioned above, I needed to make changes to Hackystat (SDTManager) to make this viable. What do people think about optionally loading SDTs from .hackystat/sdt? Any other suggestions? Is this an acceptable change to get native .NET support? I'd be happy to contribute/share my code although it is just a hack right now. If anyone would like the EXE / code, let me know. Also, the SourceSafe sensor is nearly complete. If anyone's interested, let me know as well. Thanks, Todd
