Over the weekend, I started a new mini project of sorts. I needed a generator for small Kotlin projects, which would come with a simple Gradle build file and could provide different dependencies, based on my choice. As a Java developer, one way to look at this would be to use Maven’s
Yeoman does not do much what a normal build system can’t. Indeed, one can use a simple Gulp / Grunt/ Ant / Maven / Gradle build file, which simply gets copied over and over and used as a starting point for new projects. The bigger problem is that though most build systems allow for scripting and file management, one needs to write a separate project generator for each build system, matching its specific syntax.
Yeoman saves all that by providing an abstract framework for generating a project structure, independent of the underlying technology. Moreover, since every Yeoman generator is basically a node module, it can easily be installed through npm. Generators can also extend other generators making for easy reuse of existing code. All in all a winning proposition.
What have I learned so far?
Aside from having an easy way for generating new Kotlin projects, part of the reason why I work on these mini things is learning. Obviously, figuring out how exactly Yeoman works was the main point, but besides that, I wanted this to be the first GitHub project, in which I use Travis as a CI server. For quite some time, I have been seeing repos featuring a
.travis.yml file among the rest of the code. Initially, I thought that open-source maintainers simply like Travis more than Jenkins or other popular CI alternatives. Then, I realized that the reason was the fact that Travis provides a free SaaS option for testing projects hosted on GitHub. Even then, I was still slightly unconvinced. The original project that I forked from, already had a Travis configuration file in it, so I decided to give it a try after all.
Coming from an environment, heavily focusing on using Jenkins with all of its job sequences and pipelining ceremony, I found the experience with Travis surprisingly simple. There is no additional overhead of creating jobs and figuring out how to check out and build your project. It is all defined with a couple of lines the
.travis.yml file. No additional overhead. I will definitely write a follow-up post on comparing Jenkins and Travis, so stay tuned.