Decide on binary release strategy

[irbull]

With some help from some great contributors, we are (finally) arriving at a platform independent built strategy (See #232). This brings us towards the next big question, which binaries should the J2V8 project provide? We have several options:

1. Android (Arm, x86, x64, Arm64) with and without node support*
2. Linux (x64 and x32) likely with node support
3. Windows (x64 and x32) likely with node support
4. Mac x64 with node support
5. An All-In-One with all platforms for easy deployment
6. Node versions (we currently support 7.4, but some want 7.10)
7. Stripped and non-stripped symbols for some / all platforms (this reduces the size, but makes debugging harder)
8. Other configurations?

• Node.js support add several MB to the final build, so we may not want it in all Android archives

I won't be able to support all these platforms myself, but maybe we can find a way of crowd sourcing this, so those interested in certain configurations can handle the publishing of them. I would like the publishing to be as easy as possible, and if those who are actually using the builds are responsible for publishing them, then we can be sure that the QA will be addressed.

Does anyone have thoughts on this?

[drywolf]

I can also see this being a challenge ...
For the point of "with or without" node-support I'm thinking if it would be possible to have a split build of v8 as a shared lib and the node parts as a shared lib which could maybe allow to load the node parts separately or leave them out at runtime.

[matiwinnetou]

How about supporting most common scenarios but investing into easy compilation from source. At the moment (call me dumb), I tried to compile from source on osx but failed.

If it would be dead easy (tutorials, docker images) to compile and create own binary maybe pressure for this would decrease a bit.

[djx314]

For the server side, I prefer the all-in-one option.

[drywolf]

How about supporting most common scenarios but investing into easy compilation from source. At the moment (call me think), I tried to compile from source on osx but failed.

If it would be dead easy (tutorials, docker images) to compile and create own binary maybe pressure for this would drop a bit.

I very much agree with this being the strategy to go forward, hence why I'm working hard to make the entire build for all the platforms as easy as possible, but allow for the most flexibility at the same time (see #232).

On my fork just yesterday I got the Android builds for Arm and X86 running including the junit tests that are running within the corresponding Android emulators.

From a functional perspective, I'm almost done with my work on the build-system. Before I submit the PR I will make an effort to remove / refactor some deprecated code and also I have created many open TODOs while working, that I will also now investigate again and prioritize.

Maybe during this QA step I will try to also write out some more solid specifications what variables the build-system tries to handle or should try to handle and what are the extension points for users that want to even go beyond what is supported out of the box.

As for the original issue that @irbull raised above, I think we should work to achieve the same for the deployment as for the automation of the J2V8 build, namely make the deployment of those artifacts as autonomous as possible.

• Continous delivery (Build native JNI library with a consolidated CMake toolchain (cross-platform) #232)
• Continous deployment (Decide on binary release strategy #261)

To achieve this though, we really need to have a very clear specification of all the supported build variables and the supported deployment variables for this pipeline.

[matiwinnetou]

@drywolf 👍

[matiwinnetou]

@drywolf is there anything I can do to support you in your efforts?

[drywolf]

It's a quite busy time for me at work and privately ... nonetheless I have been working on the mentioned refactoring some ... after today we have a long weekend here, so I think I will be able to submit the PR with the final draft of the unified build-system.

After that is merged, we can look into what the right strategy / tooling for the binary releases should be.

is there anything I can do to support you in your efforts?

A well-written collection of all the requested deployment configurations (in issues) would be nice for the further discussion. Basically what @irbull meant with point 8. in the original comment.

Other than that, it would be interesting to see how well the new build-system (including the docker images) will run in Travis-CI ... so if you have access to such an instance I would welcome any feedback on that.

[muthu90ec]

@drywolf , +1 on this effort, and i would also like to support in any way i can, quick question on the PR (unified build-system) it handles Windows, MacOSx and linux right? I am very interested in using it on all three platforms.

[drywolf]

yes, the three desktop platforms (Windows, MacOSx, Linux) are supported and also Android
Are you already using the j2v8 jars in an existing application of yours (on all three platforms) ?
I'm just thinking it could be a good test to see if the artifacts produced by the new build-system are working just fine for you. All the unit-tests are passing A-ok, but a real-world test would be a nice additional ensurance.

Also now that I'm thinking of it, it would be a good idea to monitor the file-sizes of the produced JARs/AARs ... just small changes in the C++ linker settings often can make a big difference (literally) in produced file-sizes ... so I'm not entirely sure I maybe missed out on some optimizations that @irbull might have had in the original build scripts.

[muthu90ec]

Yes I am already using j2v8 jars in an existing application on all three platforms(Linux, Mac, Win).
I am definitely interested in testing on all three platforms. Let me know the instructions on how to get the latest build, and I would be happy to give it a shot! Thanks

[drywolf]

@irbull I just submitted the PR #280 for the build system code.

@muthu90ec In my fork I put the essential information for running the builds into the README.md, so you could go ahead and give it a try if you want to. Also if you find any issues or have some feedback for something that would need documentation please just let me know.

[muthu90ec]

@drywolf awesome, i will try it out and let you know! Thanks

[matiwinnetou]

Just to add a bit to this, feedback from our team is that folks wanna stay conservative use NodeJS LTS versions in production only. At the moment we use LTS/BORON but then it would be nice to be able to use NodeJS LTS BORON as well during build process. I think this is theory in a sense there could be such fundamental changes to node or V8 that this project would not compile so the goal to support any V8 or NodeJS possible may simply be impossible to be met.

[drywolf]

@matiwinnetou

At the moment we use LTS/BORON but then it would be nice to be able to use NodeJS LTS BORON as well during build process.

I think I get your point, but did you mean to name two different node versions in your example ... I am just trying to fully understand what the driver for this is to make sure I can plan & prioritize features for the build-system accordingly.

Supporting different Node versions is to a small extent already considered by some parts of the current build-system implementation, but not fully integrated nor really tested yet. In theory the current concept could also be extended to even patch the J2V8 code itself to make it compatible with vastly diverging features of the Node.js code base. However, if the API of Node.js and the one expected by J2V8 diverge too much, it would be a better idea to solve this with some kind of branching strategy where supported NodeJS versions would have their own separate branch also in the J2V8 repository.
Once I am done with my current roadmap for build-system features we could explore this idea further, depending on how valuable this would be for the J2V8 community in general.

[drywolf]

@irbull I can volunteer to take on the win32 deployment support, but I have little to no experience when it comes to deploying to maven / gradle.
I think when I will be working on #320 I will need to figure this out anyway, but I hope you can share your thoughts & experience on this a bit so I can better understand what are the important steps and nifty details.