How to organize the assembly of a project in Java but with pieces of native code?

Question

Java

Good afternoon!
I'm currently working on my open-source project Octclipse (plugin for Eclipse IDE for Octave), but there is no community yet, so I'll ask a question here.
The essence of the problem:
There is a project, mainly written in Java, but for some important features (console, debug, graphics) it requires C ++ code. I want to support the project on different platforms (Linux, Window, Mac) and architectures (32.64). I also want to have support for different versions of Octave (at the moment - 3.2.4, 3.4.3, 3.6.0). In total, for each combination, a cloud of libraries is obtained, which are very inconvenient to collect.
Question:
Do you have any ideas how to organize this without too much complexity? Below I will give the options that I thought about - I would like to hear their assessment. It is not so much the technical aspect that is important to me, but the architectural one.
Add. information:
0. Native code is not simple, but is made in the form of plugins for the octave (in my opinion, this is only necessary in the case of charts). This means that it is not going to GCC, but to the mkoctfile Octave command.
1. Now the native code is built using AutoTools and only on Linux.
2. Java code is assembled using Maven 3 and Tycho (this is still a plugin for eclipse)
Options (and my attitude towards them):
- we give users a code, we ask them to assemble it before use (it will scare away half of the users)
- we pervert a little, we drag the code along with the plugin, when the plugin is first launched, we try to call mkoctfile and collect the necessary subprojects (hard, but, it seems, feasible)
- separately collect and offer additional. packages for each platform, version and distribution (very time-consuming to maintain and ugly)
- collect native subprojects and put them into eclipse fragments (accordingly, users will immediately receive a ready-to-use environment, but they will have to save the compiled packages in the repository)
Has anyone had Any experience supporting something like this? Please advise how to be?

Answer 1

For different OS versions and different machine architectures, you still have to distribute different distributions.
So only different versions of eclipse and octave remain. Here you can simply collect all the options and shove them into the installer, and during installation, detect (or ask) the necessary software versions and, accordingly, install the one that suits.

Answer 2

An acceptable solution has been found. As I wrote in the comment above, I decided to use the duns.github.com/maven-nar-plugin plugin . It is worth noting that it is damp, and, in my opinion, is already dead to everything else (last commit in 2010). But to some extent it serves its purpose. I just had to revise its code and add the ability to distinguish packages not only by the AOL(Architecture,OS,Linker) bundle, but also by additional classifiers, in which I now write the Octave version.
I think when I implement all this, it will be possible to write an article. Although, of course, the range of applicability of the NAR plugin is very narrow.

Answer 3

Try gradle instead of maven, it is more flexible and suitable for building not only JAVA applications.