maven support for java pulse
Most modern Java applications use a dependency manager like maven or gradle to pull in direct and transitive dependencies automatically (making the effort in #25 (closed) much easier). This means (ideally) users don't even need to download and build pulse -- they just add it as a dependency in their application, and everything needed is automatically pulled down from a public maven repo (like maven central). Indeed, I have wrapped pulse as a maven artifact for use in my application, which is what enabled me to (more) easily track down all the transitive dependencies in #25 (closed). (Note that nearly all dependency managers are compatible with maven artifacts, so the choice of maven is not forcing anything on applications.)
I'm using two files to do this:
- pom.xml: this is the actual maven configuration that defines the pulse version and direct dependencies
- setup-pulse.bat: a windows .bat file that executes the needed maven commands to install pulse in a local repo (this is a stand-in for a remote repo, like maven-central).
Note that not only does this package up the pulse jar, it also creates source and javadoc jars, which is super nice when using an IDE, as you can jump directly into the pulse java code without having to manually attach source (or even have the source separately at all).
Some additional work would be needed to make this usable in a more general environment:
- To put it on maven central (I can help with this):
- Get a maven central account -- this is actually something that someone on their end needs to do manually, but they can usually turn it around in a couple days.
- Maven central has certain requirements: the pom needs author information, the jars need to be signed, deployment repos need to be defined, etc. This is one of those things that is a pain to setup the first time, but then doesn't need to be touched after that.
- First upload to maven central: There are automatic checks that take place for the things above -- once you pass the checks, someone on their end will manually approve the jar and post it. Future updates are completely automatic.
- The native libs:
- I'm currently building those using the standard cmake process, and just making sure that they end up in the right place on my machine for pulse to to find them when I run my application (hence the
xcopy
line in setup.bat). We could require that people do this themselves. This also makes it easy to switch between release and debug versions of pulse, because you just have to make sure that the right shared libraries are in the right place.- This is not a very friendly way to deploy the pulse jar and is not in the spirit of maven (it's technically against maven central's requirements, but they have no way to enforce). The expectation is that the jar should "just work" when added as a dependency.
- The better way to do this is to package the required shared libs for all supported platforms in the pulse jar file, and at runtime the platform is detected and the correct shared libs are extracted from the jar and placed where they can be found by the jar. There's also a question of release vs. debug versions, so either you could have two different pulse jars (each deployed separately on maven central), maybe pulse and pulse-debug, or else you put both versions in the jar and allow the user to specify which one they want (e.g.,
jniBridge.initialize()
could be modified to take an argument).- An example of a java library that does this is sqlite-jdbc, which is a java wrapper for the sqlite C library. If you download the sqlite-jdbc-3.31.1.jar file (available here) and unzip it, you can see they've put native shared libraries in the
org/sqlite/native
directory. I think the main code they use to extract the libraries is here -- it looks like the primary methods of interest areloadSQLiteNativeLibrary()
andextractAndLoadLibraryFile()
. - Note that sqlite-jdbc includes support for a LOT of different platforms, and even has a pure java version in case the native versions fail to load. I think that's way overkill for you -- you could just include the 3 major platforms, all 64-bit, and if someone wants to run on something else, they can build pulse manually like is currently required.
- An example of a java library that does this is sqlite-jdbc, which is a java wrapper for the sqlite C library. If you download the sqlite-jdbc-3.31.1.jar file (available here) and unzip it, you can see they've put native shared libraries in the
- I'm currently building those using the standard cmake process, and just making sure that they end up in the right place on my machine for pulse to to find them when I run my application (hence the