Hi, Marco
I am writing a Clojure OpenCL library that is using JOCL. Currently, I am using 1.9.0, but would like to transfer to 0.2.0 as soon as it is available in the central repository. Do you have any expectation when would that be?
I am using Linux 64 bit, and would like to help with building JOCL if that is necessary. Thank you for creating JOCL, it saved me a lot of JNI coding 
Hi
I can only pack the JAR into the Maven repository when all native libraries are available. Currently, there is only Win64. I can also build Win32, but not really test it, because there simply are no drivers for CL2.0 on 32bit (the same for MacOS, so this may be the bottleneck in the end).
The Linux64 (and maybe 32) binaries would of course be helpful!
BTW: When you have compiled the Linux64 binaries, you can already use them (at least, for first tests) without Maven. By default, JOCL will also look for the native library in the current directory.
Is this a library for “OpenCL with Clojure”, or a library that (“only”) uses JOCL? A quick websearch shows some results for “clojure opencl”, but have not investigated this further…
bye
Marco
EDIT: BTW, I’ll split this into an own thread tomorrow. This one is primarily intended for news & updates.
I suppose you have to make all platform libs available to release to central maven repository, or it is a personal decision? Is there a possibility to release alpha or some pre-release to maven central or some other public repository with less strict rules? Clojars.org (official clojure library repository compatible with maven) accepts shapshots…
The library I am building is for OpenCL with Clojure, where host code is supposed to be written in clojure and kernels in OpenCL C. I still haven’t released anything to Github.
Well, when something is put into the Central Maven Repo, then this is one version. It is not intended to update or in any way modify the state of one version (for good reason, of course).
I could see whether publishing a SNAPSHOT version could be an option, but first have to check how this works (and whether there may be any caveats) - but even IF I deployed it now, it would not contain the Linux binaries…
I meant something like this:
Nothing needs to change. The documentation should state which binaries are supported in which alpha release. For users, it is much better to at least get something than to get nothing, I guess When new binaries come, the NEW alpha is released, with more support.
That might also help with the enthusiasm of power users and give them incentive to contribute the binaries for additional platforms, otherwise it is unclear if those 32 binaries are ever going to be available, possibly stalling 0.2.0 maven availability indefinitely.
Well, I hope that the binaries will be available soon (otherwise there is some Chicken-Egg-Problem that solves itself: If nobody with Linux/Mac is willing to compile the binaries, then one has to assume that nobody intends to use it at all -_- I should probably try to set up some Virtual Machine for building these binaries. Solely having to rely on contributors is certainly not the best solution).
However, it should (in fact: trivially) be possible to deploy a SNAPSHOT version to the snapshot repository. I’ll try to do this ASAP (tomorrow or monday), and drop a note here and on the website when it is available.
I would contribute linux 64 binaries, if the build is (mostly) automatic. Do you have some notes about building on linux?
There is a makefile, so this should not be a problem. Although, admittedly, this makefile mainly defines some basic settings (include path etc), and then refers to another makefile that was ripped from one of the NVIDIA OpenCL samples. I’ll have to check whether it has to be updated for CL 2.0 in any way, but don’t think so. Regardless of that, I’d also like to replace it with a nice, clean CMake file, maybe I can also tackle this for the 0.2.0 release.
If you are changing that anyway, may I suggest looking at nar-maven-plugin - NAR Plugin, a plugin for building AND packaging jni-based java libraries on and for many platforms.
I can help with it if needed since I used it on an jni-based project. The main benefit over make/cmake would be that if abstracts platform-based stuff pretty well, and automatically handles much boilerplate that otherwise has to be done manually in make. The added benefit is that java developers then have a platform-independent pom.xml so it is much easier for eventual testers and contributors to build JOCL themselves since they do not need to know anything beyond java and maven. It also supports maven profiles, that is, different configurations for different platforms, and activates them automatically.
You can see an example of how I used it at https://github.com/uncomplicate/neanderthal
Sorry for the typo in the previous message, the jni part of the project is at https://github.com/uncomplicate/neanderthal-atlas
I’m always open for suggestions and improvements.
But frankly, I don’t have the best experience when it comes to using Maven with native libraries (in any way). The current status is the result of a longer hassle that I went through when I first tried to provide JOCL in Maven (here - warning: contains some rants), and the whole process of getting the library into the central repo was just very, very annoying.
I already tried to use the NAR plugin there, and it plainly did not work: It’s simply not possible to create a platform-agnostic POM that takes care of the native compilation and packages the JAR appropriately, because there are 5 different target systems that need 5 different native libraries that have to be compiled with 3 different compilers, and can only be packaged into one JAR when they are all available - and this can, by definition, not be done on a single machine.
However, I’ll have another look at the NAR and the project that you linked to, maybe there have been some improvements and now the NAR is able to do magic tricks that it could not do 4 years ago 
Yes, it is a hassle, but I think it could be massaged to do something acceptable. NAR was in a bit of a limbo for some time, but now is actively maintained. I am not sure everything could be packaged in one jar (without additional copypasta), but I think that the distribution is meant to consist of one pure Java (jar) archive, and one native platform archive (nar) for each architecture. All those files are then related artifacts that maven takes care of. Nars are just jars with different extensions, and could be automatically renamed to jars if necessary. Now, the question is whether the central maven repository accepts multiple artifacts per library. I believe so but I am not sure.
One of the issues with most libraries that involve native parts is the UnsatisfiedLinkError. I’d really prefer to have a single library that contains the native parts. Of course, if Maven and the NAR plugin are now clever enough to really handle this transparently, this could be an option for the pure Maven deployment. However, I’ll definitely try to offer such a one-stop JAR at the website, at least.
However, the current version of JOCL 0.2.0-SNAPSHOT (with Win64 and Win32) has been deployed and is available at Index of /repositories/snapshots/org/jocl/jocl/0.2.0-SNAPSHOT . Quoting from „Maven: The Complete Reference“:
As a default setting, Maven will not check for SNAPSHOT releases on remote repositories. To depend on SNAPSHOT releases, users must explicitly enable the ability to download snapshots using a repository or pluginRepository element in the POM.
Great. It would be nice if they told you how to do this :twisted: However, in the other thread, someone mentioned something about this, so it might be possible with something along the lines of
<profiles>
<profile>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<snapshots>
<enabled>true</enabled>
<!-- for the heavy user (default:daily): <updatePolicy>always</updatePolicy> -->
</snapshots>
<id>sonatype</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
</repository>
</repositories>
</profile>
</profiles>
but you never know…
So I’ll try to have another look at the NAR, but at the moment, there are several other tasks in my queue: It’s once again JCuda’s turn, with an update for CUDA 7.0 in JCuda 0.7.0 (hey, I’m slowly approaching the famous „1.0.0“ version here ;))
is behaving somewhat unexpected, it works like the default branch in a switch case: If no other profile is active, this profile will be activated.
Best is never to use activeByDefault
always will just slow down your build because it forces Maven to check on every build for updates, the default is daily which should be enough, if you want to force Maven to check for updates, use the -U option.
Since you always want to use this snapshot repo, just add it as a repository instead of using a profile, it is very normal for OSS projects to include repos in their POM.
Personally, I would try to avoid having a mixed C and Java Build in Maven, your solution with adding the files as resources would be my preferred way.
You could have Maven download the compiled libs if you want to from an URL: get - Maven: downloading files from url - Stack Overflow
Also, yhou could copy your native libs to a certain folder during the build, the location will vary with the OS and this is a good use case for profiles, since they support being activated on certain OS, architecture etc.
Btw., true as default property is something that will offend Maven people
Thanks for this info. The POM-Snippet was just taken from the other thread, and I did not really understand it entirely (beyond some more-or-less educated guesses, of course).
Using a „custom“ repo is what I’m doing for my local development of not-yet-deployed stuff (unrelated to JOCL). But I wasn’t sure whether one had to use this profile thing for remote snapshot repos. Howefully, those who are reading this thread will be able to judge which solution is appropriate for them 
As I mentioned: It does not work anyhow. Collecting the native libs and packaging them in the end seems OK, but managing them individually (and thus, transparently) for pure-Maven-Deployment, by using the NAR, could have advantages as well…
[QUOTE=maki;114293]
Btw., true as default property is something that will offend Maven people ;)[/QUOTE]
I’m a Punk :frech:
(Just kidding: The current test set is not yet automated with JUnit. It’s on my „todo“ list, of course, but the complex setup/shutdown, the different memory types and regions, and the asynchronous nature of OpenCL make this a bit fiddly…)
I haven’t looked at the details/news of NAR yet, but wonder whether someone tried the snapshot version in the meantime…!?
I am not on Windows, so I didn’t use that distribution. Currently, I am using 1.9.0 for the development and testing of my clojure cl library. It seams to me that it will be a straightforward task to update it to 0.2.0 once the linux version is in the maven repos.
One point though. As far as I remember, maven refuses to build non-snapshot version of a library that uses a snapshot dependency, so I thing it would be better to version pre-releases of JOCL as alpha/beta or some similar scheme instead of SNAPSHOT.
Hm. I still wonder why nobody provided the updated Linux/Mac binaries yet. I should probably “ping” those who usually provided them…
I’ve just built the linux binary. I have not tested it, but the build went well, and I did not need to do any hacking. It’s in the attachment. Would you please add it to the maven release? And, please, if possible, release that maven lib as alpha or beta or something different than snapshot, so non-snapshot libs could use it.
OK, I’ll try to integrate this tomorrow and publish it as “alpha” (although I’m not sure whether Maven/Sonatype will “allow me to do what I want” (and not force me to do what follows (their) conventions…))