One way would be to effectively split the native bits and the java bits into two separate distributions.
One deb/rpm/win-installer with libjzmq (JNI bridge to libzmq), and one published jar with the higher-level JVM-only parts (identical to /usr/share/java/jzmq.jar in the debian package today). The latter will not work without the former, but it would be obvious(tm) if attempted. Not having to coordinate native builds for N platforms to ship a new release of jzmq would probably be a good thing. I suppose the alternative would be to keep archived native libs (or in the source tree) to allow shipping new jzmq releases without the overhead of muitlplatform builds. Another issue is that today the autoconf and maven builds are sort of interleaved in the same source tree. If you build a debian package you a different jzmq.jar than if you run 'mvn package', and the difference is non-obvious unless you check its contents. PS. Thought of another similar example: snappy-java. Their source tarball does indeed include binaries for supported platforms - built "elsewhere" as a separate step. On Thu, Dec 29, 2011 at 16:43, Daniel Lundin <d...@eintr.org> wrote: >> Alternatively you could package the library >> files for the various platforms as resources within the JAR and >> automagically load the right one at runtime > > This is actually already how it's done, courtesy Karl Ostendorf (kwo). > The relevant bits: > > https://github.com/zeromq/jzmq/blob/master/src/org/zeromq/EmbeddedLibraryTools.java > > I'm mostly curious how to actually build the jar itself and assemble > .so, .lib and whatnot files for all platforms in a practical and > repeatable fashion. > > I suppose we could do it manually on different platforms, merge > resources and resign the jar. > So far, this is what we've done locally, but it's not exactly elegant, > repeatable or scalable. > > Are there any other projects that do similar distribution of embedded > native libs? > > jna.jar is the only one i recall off the top of my head, and their > build file is a lovely 1000 lines of XML. > > Maybe its too high a target to go for embedding everything for all > "supported" platforms. > Perhaps it would be more practical to ship libjzmq as a separate > (platform-dependent) package, and that being an implicit dependencyfor > installing the jzmq artifact? > > On Thu, Dec 29, 2011 at 16:12, Gabriele Svelto > <gabriele.sve...@gmail.com> wrote: >> Hi Daniel, >> >> 2011/12/29 Daniel Lundin <d...@eintr.org>: >>> This will solve the hosting/distribution problem neatly, and we can >>> focus on the tricky business - i.e how to build multi-platform jars >>> w/native code. >>> >>> Any Java-heads around here familiar with how that works in practice? >> >> it depends on how you want to distribute the native libraries. If the >> JAR assumes that the native library is already installed, it would >> just be a matter of calling System.LoadLibrary() with the correct >> library for the environment you're running on within static >> initialization methods (to make sure the library is loaded before any >> object is instanced). Alternatively you could package the library >> files for the various platforms as resources within the JAR and >> automagically load the right one at runtime using System.Load() after >> detecting the system you're running on. >> >> The tricky part is really figuring out where the JAR is running >> (Windows? Linux? BSD?) and then taking appropriate action. If the JAR >> file is meant to be platform-specific on the other hand then there's >> no need for this logic but you still need to distribute the >> appropriate native library somehow (either it's pre-installed or its >> packaged within the JAR). >> >> Gabriele >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
