Last Thursday (1st of July), I attended JFrog’s build seminar – To build or not to be. The convention were led by some top experts on the subject – Yoav Landman (JFrog CTO), Fredric Simon (JFrog Chief Architect), Hans Dockter (founder and project leader of Gradle) and Kohsuke Kawaguchi (creator and leader of Hudson build server, i.e. Hudson-CI).
The seminar incorporated reviews and introductions from all relevant aspects of project maintenance related to build issues.
Landman spoke of modular systems and separation of concerns between different modules. As a good example, he referred to project Jigsaw and how beneficial it can be for both developers and end-users (e.g.: You don’t have to download and install the entire Java runtime – include UI libraries - when you’re running a simple console application). Landman stated that the world is gradually migrating to modular system builds, emphasizing its contribution to evolvement of greater and better services.
Dockter provided a delightful introduction to the Gradle build tool and an insights on some key features inside Gradle. As perceived by others and myself, Gradle is the legal heir of Maven. It is everything that Maven is and is not. It's refreshing approach to build issues, dependency management and incorporated DSL based on Groovy makes it a winning candidate, leaving all competitors way behind.
Another highlight was Kohsuke Kawaguchi pushing Hudson to the limit. Kawaguchi proved once again that open source projects can have a commercial and professional grade. Kohsuke reviewed some major features of Hudson CI and elaborated on distributed building process. At modern times, running through a complete build cycle (resource gathering, compilation, unit testing, integration testing, packaging, deploying ….) can consume quite a time.
Like other major-league players – Jetbrain’s TeamCity and Atlassian Bamboo – Hudson CI provides the PXE plugin that allows you to add and drop build machines in a matter of a clicks. Hudson has a true distributed build model and work-load distribution mechanism (allowing to compile the project on one machine and run tests on another), but that’s a subject for another discussion.
The finale appeared with the exotic image of Frederic Simon, a veteran in the Java landscape. Simon took us to a hands-on tour with Gradle, Hudson CI, and its excellent integration with Artifactory.
Speaking with some attendees, I realized that this presentation visualized to them how healthy builds can save your time, and thus save you money.
Final wordsArtifactory has a great integration with local build tools, such as Gradle, Maven and Ant/Ivy from one side and build server – such as Hudson and JetBrain’s TeamCity – from the other side. The seminar illustrated it both.
My personal note from this seminar, is that every organization – or even better yet – every project, must have its "build officer” (Configuration Manager), a person responsible of all build issues. I have encountered this position on some projects, but it was mainly of large companies with large-enough infrastructure to demand such a standard.
I think that every project, no matter how small, should have such an expert. As I don’t expect an enterprise-grade project to run without an architect (or even senior developer that fills that title), I wouldn’t expect to run without a Build Officer.
You can find more photos from the seminar here.