On 07/07/2013 07:30 PM, Charles Oliver Nutter wrote: > 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).
I don't think the whole jsr292-backport needs to be pushed to maven, you and others only need the jsr292-mock. Yes, the jsr292-mock doesn't change often, it change once by release, so there is one version for java 7 and one version for java 8 (Java 8 adds the MethodHandleInfo API, the way to crack constant method handles). I don't know how you generate your mock, but given the number of classses/interfaces in java.lang.invoke, I've not done this job by hand but use a script that take a valid rt.jar and extract the JSR 292 API description from it and recreate a jar using ASM. Given that there is no need to bundle the backport with the jsr292-mock, I propose you something, you create a project on github under your name, you give me the right to push the code (I will create a textual representation of the API so you will be able to re-create the jar without having the right rt.jar available) and after you are free to do what you want with it :) > > - Charlie cheers, Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
