jsr292-mock: Ok Rémi, it's decision time :-)
We *need* to get jsr292-mock into maven somehow for JRuby's new build, so we don't have to version the binary anymore. We'd be happy to help set up the maven pom.xml AND get a groupId set up via sonatype's maven service, or we could just start pushing the artifact under a groupId we own (com.headius or org.jruby). Ideally we'd agree between all users where to put it and handle (as a team) getting artifacts pushed. I'm right in thinking this does not change often, right? Unless there's visible API changes in 8, the same artifact will probably get pushed once and not change for a long time. It's up to you (Rémi) and other users whether we should also push the jsr292-backport to maven. We're not using it in JRuby right now. unsafe-mock and coro-mock: I have pushed two new artifacts to maven: com.headius.unsafe-mock and com.headius.coro-mock. unsafe-mock is basically just JDK8's Unsafe.java in artifact form. You would set up your build to fetch it, stick it into bootclasspath, and compile. The intent is to provide a full Unsafe API for compilation only; you must detect in your own code whether certain methods are actually available at runtime. We created this artifact because we use the new JDK8 "fences" API (when available) for our Ruby instance variable tables, but did not want to require JDK8 to build JRuby. coro-mock is a mock of the latest coroutine API from Lukas, provided in artifact form for the same reason. Since the API does not exist in any release JDK, just adding to classpath/dependencies will allow compiling against it. We use it for the Fiber (microthread) library in JRuby (though I'd bet coro does not work anymore...still need to get a JSR going for that). - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev