You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create a repository for building and distributing binaries #40
… 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.
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.
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.
Activity
tresf commentedon Apr 15, 2019
Having the binaries in their own repo to keep the
.gitfolder 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
mavendependency for contributors. To do this, we can upload a generated file and then add it to.gitignoreand manually update it as needed.https://en.wikipedia.org/wiki/Occam%27s_razor
bmarwell commentedon Apr 16, 2019
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 commentedon Apr 16, 2019
🤦♂️
bmarwell commentedon Apr 18, 2019
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 commentedon Jan 25, 2020
Done
https://github.com/java-native/jssc-native