Skip to content

Create a repository for building and distributing binaries #40

Closed

Description

@bmarwell

As seen in those repositories:

… 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.

Activity

  1. added this to the Release 4.0.0 milestone on Apr 14, 2019
  2. self-assigned this
    on Apr 14, 2019
  3. tresf commented on Apr 15, 2019

    @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

  4. bmarwell commented on Apr 16, 2019

    @bmarwell
    Author

    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.

  5. tresf commented on Apr 16, 2019

    @tresf

    create a third repo

    🤦‍♂️

  6. bmarwell commented on Apr 18, 2019

    @bmarwell
    Author

    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.

  7. modified the milestones: 4.0.0, 5.0.0 on Jan 25, 2020
  8. bmarwell commented on Jan 25, 2020

    @bmarwell
    Author
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

component:mavenChanges to the java build process

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions