Create a repository for building and distributing binaries

[bmarwell]

As seen in those repositories:

• https://github.com/acegi/acegi-standard-project#performing-a-release
• https://github.com/lmdbjava/native/blob/master/pom.xml

… we might want to set up a repository consisting of the c++ code and the generated .h file. For now, we'd need to manually copy the generated .h file to the new repository. But that should not be a problem, as the interface rarely changes.

Suggested name: jssc-native.

If we wanted to avoid manual coupling completely, we'd also had to set up yet another repository with the name jssc-native-header, which contained ONLY the the Java file with the native methods, and the generated artifact (jssc-native-header.jar) would contain the compiled class file and the generated header file. This way, this library (jssc) and each artifact from jssc-native would need to depend on the very same version of jssc-native-header, which would help in detecting version and interface collisions.

To have everything built with the same versions (dependencies, plugins, etc.), we even might want to create a jssc-parent repository. The benefit would be that this would remove all the clutter from any other repository mentioned so far.

[tresf]

Having the binaries in their own repo to keep the .git folder manageable (albeit adding unnecessary complexity) makes sense. However, moving the native code there doesn't. The JSSC library means nothing without the C++ code.

In regards to the header, we should consider bring that back anyway to remove the maven dependency for contributors. To do this, we can upload a generated file and then add it to .gitignore and manually update it as needed.

https://en.wikipedia.org/wiki/Occam%27s_razor

[bmarwell]

Oh, thats also possible. The native repo would just be a build repo. Btw, no binaries needed to check in

That just means:
Either create a third repo or use submodules.

[tresf]

create a third repo

🤦‍♂️

[bmarwell]

Yeah for the java file with only the native methods. The jar would contain both the class file and the header file.
That way, the code in this repository could depend on the header files from a dependency.

The other possibility is to have this repo as submodule for the new repository and create the header file each time we compile the new repository. leaves the question which jar ships the generated header file.

[bmarwell]

Done

https://github.com/java-native/jssc-native