At the core of Skyway Builder is the Skyway Generation Framework, our Eclipse-based engine that provides extensible code generation and scaffolding capabilities. The Skyway Generation Framework takes XML models (specifically EMF) as input and produces files, or artifacts. Recently, in addition to our standard code generation and scaffolding, we have seen a growing number of Java architects using the Skyway Generation Framework to create a custom generation platform based on their company’s technical requirements.
Mentioned as #2 in Jack’s “Top 10 Principles of Code Generation” blog post, extensibility is key. We believe that a good code generation system must be extendible, configurable, and customizable at every level. The goal of this series of blog posts is to provide a deeper review of Skyway’s extension architecture and describe our capabilities for customizing the code generation process.
Skyway Generation Framework
The Skyway Generation Framework can be used to generate any type of textual file. The generation process can be triggered explicitly through a Java API or configured to automatically execute when a model changes through an Eclipse builder. Currently, the generation engine runs inside the Eclipse IDE, but plans are underway to allow headless execution.
The framework centers on artifact sets, which are composed of artifact definitions, emitters and invalidators. Since artifact sets are linked to Eclipse facets, they can easily be applied or removed from a modeling project, which allows developers to generate different versions of code from the same application model.
An artifact definition describes an artifact and consists of a template, a generator, a beautifier and a merger.
- The template is the blueprint for the artifact.
- The generator uses the template to create the artifact. Since the generators are pluggable, the framework is not coupled to any specific template technology. JET and Velocity are commonly used and different technologies can be commingled; you can use JET for some artifacts and Velocity for others.
- A beautifier cleans up the generated file. By using a beautifier, the template author does not have to worry about things like indentation. Stock beautifiers are available for Java and XML files.
- The merger controls what happens when a generated file must be merged with another version of the same file. A merger allows a user to modify a generated file without having those changes overwritten if the file is re-generated. JMerger, from EMF, is used for Java source files, but other mergers can be written and plugged in. JMerger is controlled by a rules file and Skyway Builder’s stock artifact sets define an artifact for this rules file, so it is generated into each project. Since this file is exposed and easily accessible, the Java merging rules can be adjusted on a case by case basis.
All of Skyway’s templates are developed using JET. The org.skyway.integration.java plugin provides many custom JET tags, in addition to the basic tags provided by the JET framework. These tags encapsulate reusable snippets of Java code. For example, the ThrowsListTag is used whenever a Java throws clause is emitted and a PackageTag is used whenever a Java package statement is emitted. The Skyway JET tag library can be used independently of the Generation Framework, even if you aren’t extending Skyway JET templates.
Our JET tags make heavy use of emitters, which are small pieces of code that know how to emit commonly used strings. Emitters are not coupled to JET, which allows you to leverage them in other template frameworks or inside non-generation code. And of course, emitters are pluggable and can be overridden.
The scope of what gets generated is controlled through invalidators. An invalidator is a way to mark one model dirty when another type of model changes. For example, you may want to re-generate all of your data objects when your database settings change. There are stock invalidators available for common scenarios, such as marking the project dirty.
Extending the Framework
The Skyway Generation Framework is very extensible and can be customized a number of different ways using Java. When attempting to architect a new generation framework, most users start with an existing artifact set that they need to modify in some way, allowing them to leverage existing templates and save a lot of time. For example, users wanting to generate Spring-based web applications could start with one of Skyway’s artifact sets (productized in our open source and commercial versions of Skyway Builder) and then customize the Skyway templates to meet their own specific needs.
For users choosing to modify an existing artifact set, there are 4 common ways to do it within Skyway Builder:
- Adding, removing or overriding an artifact definition
- Adding or overriding an emitter
- Adding or overriding an invalidator
- Scaffolding
My next few blog posts will go into each one of these 4 approaches in more detail.
It is also possible, however, to create a completely new artifact set and couple it with your own facet. If you choose to create your own artifact set from scratch, you would create your own Eclipse facet and link it to the new artifact definitions that you create. You could choose to use the existing Skyway application model (in EMF), or you could create your own backing model. If you use our application model, you could continue to leverage our user interface, and even if you choose to create your own artifact set, you can still benefit from many existing Skyway components for generation, merging and beautification.
Summary
Look for more blog posts on Skyway’s extension architecture and our capabilities for customizing the code generation process over the next few weeks. In the interim, you can check out and download the Skyway Builder open-source project here.
