One thing I don’t like about jsp is that it looks like html. The default engine for JBake is freemarker. Like many other template engines freemarker adds expressions to the html language. I would much rather work with something that looks like groovy so I’m going to try out groovy’s MarkupTemplateEngine as the template engine for JBake.
In a previous post JBake was added to nixos. Now it is time to convert this blog to JBake. As with any user blog hosted by github the content needs to be posted to a git repository for the user. My repository is moaxcp.github.com. I’m using a second repository for the sources of the site.
Convert posts from jekyll Markdown format to JBake asciidoc format
Setup Gradle to build and publish the blog
Setup travis-ci to update the blog when sources change
To get started I had to setup gradle and JBake in a workflow for converting posts and viewing the site.
JBake is a static site/blog generator. I have been using jekyll for this blog but I would like to try something new. My main operating system is NixOS which does not have a package to install JBake. It will need to be added. I have already updated visualvm and notion for NixOS but adding a new package is something I haven’t tried yet.
After installing nixos I had some issues with the linux kernel and possibly kde. At boot I would get errors like this.
One step in installing nixos I had trouble performing was connecting to wifi. On the minimal install boot wpa_supplicant is installed but there is no service. There are a few instructions for this online but this is what I did to get it working.
I found an issue in an ivy.xml that resulted in hamcrest not being added to the test configuration. The junit dependency looked like this:
I have decided to switch from gentoo to nixos. I tried nixos over a year ago but had a lot of troubles. This was probably because I used the unstable release and couldn’t really get gradle stuff to work. This time I will only use the stable release and try to import newer stuff from unstable if I decided I need it. Hopefully I will not have as many problems as I did with the unstable release.
Codenarc is a static code analysis tool for groovy. It is the same tool sonarqube.com uses to to publish its results. The graph-dsl project is setup to use codenarc for local development and sonarqube.com for continuous integration. There is just one problem with sonarqube.com, it only uses 59 rules rather than the 353 rules available. I wanted to find a way to send all of those rules to sonarqube.com that were missing.
graph-dsl is a project I started so I could write graphs and algorithms easily. Over the past year testing has become important to the way I write code. With graph-dsl I wanted to learn more about Test Driven Development and using different tools like gradle, spock, jacoco, and sonarqube.
Older post are available in the archive