We’ve managed to get the install script to compile and install Jaxer in from a fresh Raspberry Pi install. We can get back to where I got ahead of myself and tried to over-simplify the install script too fast and too soon without testing intermediate step along the way. Lesson learned, so now it’s time to try and look and see what can be reduced, where, why and how it can be tested without compromising runtime.

So two things we’ve managed to reduce right off the bat is the script for adding the build number into all of the headers. At face value this is probably a cardinal sin, for programming. But we’re not too worried about the actual source files at the moment. Right now all we need to manage for the source files is that the application builds. We’re not making any changes to the binary, but the environment the resulting binary runs in.

So what’s the reason for removing the build number? The main reason is that it probably shouldn’t be in the build script. For the build script we’re strictly interested in what it takes to compile the binary and put it where it needs to be. When we get into working with the binary, we can manage the build numbers individually with Git, and only change a number when we edit something specific. So it’s for these reasons that we’ve removed it from the build process.

The other thing we’ve removed is the servlet from the build process. The servlet was for some kind of compatibility layer with Apache Tomcat, but we don’t really need to worry about compatibility with Java. Right now we really just want the Jaxer-runtime, and any compatibility with other server-side languages can be solved with either Reddis or by accessing the same database. So I think that not only can we remove the servlet from the build script, but we can also remove the source for the servlet from the repository entirely.

In terms of candidates for more content to remove from the repository entirely, we have the tools folder, which I still don’t know what it’s used for. There’s also the driver for IIS on Windows and since we’re not interested in targeting Windows, we can also likely safely remove that.

Inside the ditsro-folder it looks like there are folders for RPM and debian. As far as I can tell these were potentially intended for deploying Jaxer to package managers. While getting Jaxer back into a package manager is a goal of the EmraJs project, I think we can probably remove these two directories as well and implement them when the run time is in a more ship-able state.

Which kind of brings us to the cross-roads of what we can remove in the repository and what can be removed in the setup script, which brings us to the next target for removal and the topic of this post. Which is the following section of the install script.

So we have this big chunk of code that looks like it does a lot of things, but probably accomplishes very little. But this is one of the things that I changed when trying to over-simply the setup scrip too fast. And since there was no problem with the other changes I made, I should probably be careful with this section.

So the first block of code looks like it copies everything from distro/jam into a working folder named jam. The problem is that of all the folders in jam, jaxer is the only one that’s actually needed.

And then to make add to the mystery inside the jaxer folder, it looks like there’s very little that’s needed as well.

We don’t need the admin or aptana folder. confs, content, and default_local_jaxer are config files that we overwrite anyways. And then default_public and all of the individual files are not files that get used. So we could probably create our own version of this folder with a configs template folder in the repository that has our altered config files already prepared and then have the jaxer binaries simply copied into that.

Which brings us to the second half of the script that we can reduce. And it basically looks like it takes the resulting ff-release/dist/bin folder and copies it into the jam/jaxer folder. But then has a bunch of if-statements for stuff that can be taken out. It looks like this script can be simplified greatly by doing something like the following:

cp -rL src/mozilla/ff-release/dist/bin jam
rm -rf jam/aptana
rm -rf jam/framework
rm -rf jam/proframework
cp -r configs/* jam/
mv jam /etc/emrajs

So basically we copy everything from the compiled binary into a working folder name jam, and then we remove the folders that we don’t need, or will be provided from configs, and then we copy our static config contents into the working jam folder. And that runtime environment can then be directly relocated to /etc/emrajs.

So in terms of approach, we can create a folder named configs in our repository, which might add to the clutter a little bit, but for now it’s at least safe. Then we can make an alternative script to test the alternative python script for the setup. And then if that works we can merge the changes back into the master branch.