|Image courtesy of NASA|
Maven archetypes, to me, represent some of the most useful tools in state-of-the-art Java development. Generically speaking, they are used to allow very quick and robust automatic generation of a complete development environment (in Maven project format) relating to a specific technology (e.g., Hadoop, MySQL, etc.), often including fully-functional example code, so that a developer can get right to work understanding and using the technology, while spending close to zero time in the often-frustrating task of getting a workspace within their IDE properly configured. All of that is automatically and instantaneously done for them by the archetype.
When I saw the request go out for development of HBase-oriented archetypes (as an entry in the HBase project's JIRA system), I claimed it almost immediately. The fact that it was posted by one of the most prominent members of the project's management committee suggested to me that it was no idle wish-list item, but a serious request for development. I knew absolutely nothing at that point about Maven archetypes, nor how to develop them; but neither, apparently, did anybody else among all current HBase contributors. It would be my chance to study up on a new-to-me technology and apply it in a completely new-to-the-world (but very-useful-to-the-world) way. In other words -- it was a chance to do yet again what I've successfully done so many times before in my software engineering career with other technologies, but this time in an open-source context!
Not long after beginning to acclimate myself to the Maven archetype world, I realized that if I simply created the archetypes being requested and "dropped them into" the HBase project, that in all future builds of HBase there would be no proper testing of significant components of the archetypes. Just as problematically, it would leave things difficult to manage in the future for those who would need to (1) maintain the existing archetypes and (2) create new archetypes for different purposes. The available tools for producing Maven archetypes did not seem to lend themselves to the full software development lifecycle, and they are not particularly well-documented in all necessary regards. So my additional goal became to provide a very simple and well-documented infrastructure for development, maintenance, and future additions to a collection of HBase-oriented Maven archetypes.
In the end, I have provided an infrastructure which (1) provides for ongoing testing of all components of each archetype as new HBase builds are done, (2) allows future HBase contributors to add new archetypes in a straightforward away, via brief documentation provided in the README.md text found in the hbase-archetypes subproject's root directory.
Now we proceed on with backporting HBase-oriented archetypes to an upcoming 1.x minor release (likely 1.3), and then deploying the archetypes to the Central Maven Repository, allowing for public access to them.
Besides this, I have a few other projects on my plate, all in the open-source realm, consisting of:
- a new Java-collection-oriented tool-set that I am currently finalizing, which I plan to ultimately offer up to the Apache Commons project, and
- another HBase-oriented tool-set (unrelated to archetypes) that I'll be publishing on my own and then offering up to the HBase project as a candidate for adoption into the main product.
daniel [at] commonvox [dot] org