Fork me on GitHub
Thomas Moerman13:06:52

Hi Guys, I was wondering whether anyone can recommend a light-weight BPMN-like (doesn't have to adhere to any standards) library (preferably clojure) for keeping track of workflow data alongside domain entities. I have looked at Camunda and Flowable, but I would prefer something more lightweight that I could use alongside my own entities, using the same query mechanism etc (Crux/Datalog in our case). I'm about to roll my own implementation with a very limited scope, but perhaps there's something already out there so I don't have to?


I've seen but never used Dativity, which may be closer to what you're looking for.


almost on topic: how do I use packages tied to native deps that I have installed via the debian package manager? is there a trick to getting the classpath I should add to the java command? some maven helper?


or do I stop trying to use debian provided java packages, and just compile the code for my machine and make my own packages?


for example csound has java bindings that work with the specific binary csound version via jni, how do I portably add the jar csound offers to my deps?


You can include native libraries in jars which is what libaries like lwjgl and skija do. Usually, I just look for the jars on maven.


Does the debian package also provide a jar?


but the whole point is that it's tied to a specific app version, I don't want whatever is on maven, I want the one that came with the binary


right, the debian system has it's own thing with /user/share/java/ but the jars in that directory are not automatically added to classpath


so I assume there's some tool to gather the jars by name or something, I'm having no luck figuring this out via google


oh, there's also /usr/lib/jni/*.so for the native dep objects themselves (the part I wouldn't count on getting from maven)


oh - maybe I'm wrong to distrust maven here, maybe adding a lwjgl package will just find what my system needs?


the shared libary is included in the jar


"the shared library" - this is the part that confuses me, I'd expect there to be a different shared library for each OS/architecture combo


or in the csound case, for each csound release version even when the java side code doesn't change


maybe I'm being dense


there are different libraries for each OS. Skija's docs might be helpful to see,


to use skija, you need 1) the skija libary that has all the java classes 2) the jar that has the shared library for your OS


you can put everything into one jar, but then the jar ends up being huge


here's an example deps for lwjgl stuff:

org.lwjgl/lwjgl {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl$natives-macos {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl$natives-linux {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-glfw {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-glfw$natives-macos {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-glfw$natives-linux {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-opengl {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-opengl$natives-macos {:mvn/version "3.2.3"}
        org.lwjgl/lwjgl-opengl$natives-linux {:mvn/version "3.2.3"}}


I have seen at least one library provide separate maven artifacts for each OS/architecture combo and also provide a "everything" artifact that has the java classes + native builds for all OS's and architectures. I think it was JOGL


awesome, thanks so much