@daviddbal Could you clarify what gave you that impression? The core dependency for that is nd4j-api.
The nd4j-native/nd4j-cuda artifacts have that as a dependency already.
All nd4j-nattive-platform does is gives you a simple way of specifying one dependency for all different platforms. If you actually look at the nd4j-native-platform, pom.xml you would see that.
Beyond that…not really sure what to say here. I already explained what each one does.
The one without the classifier has the class files in there and the classifiers themselves just contain the native artifacts compiled a specific way (like for cpu only or gpu or cpu with avx)
In that case, you will need one artifact that just has the class files and another with the artifacts for a specific platform that you want to use.
In our tutorials, maven typically does this for you. It will automatically pull the relevant classifier + the default classifier for you. Gradle does not do this.
@daviddbal if you’re wondering why we have this system it’s because all of the binaries are only able to be loaded once by any JVM runtime. Once you load a library in to memory it can’t load them again.
All of the relevant classifiers are artifacts with the same name but compiled a different way.
All of those are based on the same c++ code base underneath: deeplearning4j/libnd4j at master · eclipse/deeplearning4j · GitHub
Hopefully that helps you understand a bit more about what’s going on there.
To recap: the non classifier one has the actual java files you see, the classifier ones contain binaries compiled a certain way. That’s our way of allowing the user to specify “I want to use math libraries compiled this way” - I know it’s complicated, but people have different platforms they want to run on as well as different requirements like binary size as well as target OS and platform.