Extending MyBatis Generator
MyBatis Generator (MBG) is designed for extensibility. All code generation is performed using a simple DOM representation of Java and XML elements.
The Java DOM is included in the package org.mybatis.generator.api.dom.java
The XML DOM is included in the package org.mybatis.generator.api.dom.xml
These classes are not sufficient for every conceivable code generation possibility, but they are quite useful for generating simple to moderately complex Java and XML code.
Using options in the configuration file, you can provide your own implementations of many of the key code generation interfaces. You can also subclass any of the provided implementations to provide customized behaviors. This page will describe the public APIs available and provide pointers to the source code for further investigation. If you have any difficulty understanding how to extend MBG, feel free to send a note to the support mailing list at firstname.lastname@example.org.
Although there are a number of different extension points shown on this page, in most cases it will be far easier to extend MBG through the use of a plugin. See the Implementing Plugins reference page for more information.
The primary extension point for code generation is org.mybatis.generator.api.IntrospectedTable. Implementing a code generator is a non-trivial task and should only be contemplated when you want to completely replace the code generation activities of MBG. In the years since the original release of Abator, very few enhancement requests have appeared that could not be handled by a plugin.
MBG provides a number of different extension points. The following sections list the different methods of extending MBG, and describe the types of activities that can be accomplished with the different extensions. If you need some help understanding the different options, feel free to ask a question on the user mailing list.
IntrospectedTable is an abstract class that can be extended to supply different code generators than the versions supplied with MBG. A good example of such an implementation would be a FreeMarker or Velocity template based implementation. In most other instances, coding a plugin is the better way to go.
If you choose to extend this class, you must supply code to generate Java and XML files. You may choose to generated those files with the technology of your choice. The base IntrospectedTable class holds an instance of org.mybatis.generator.internal.rules.Rules that can be queried to determine many of the rules for code generation.
MBG supplies several implementations of introspected table. The implementation is chosen based on the value of the targetRuntime attribute of the <context> element. In many cases it will be far simpler to extend one of the built in implementations, rather than creating an implementation from scratch. The following table shows the built in implementations:
If you choose to implement this extension point, specify the fully qualified class name of your implementation with the targetRuntime attribute of the <context> element.
IntrospectedColumn is a class that holds information about a column as it is returned from database metadata. In some rare circumstances it might be desirable to override this class to provide your own implementation - especially if you create a new set of code generators.
If you choose to implement this extension point, specify the fully qualified class name of your implementation with the introspectedColumnImpl attribute of the <context> element.
MBG calls methods in this interface to map JDBC types to Java types during database introspection. The default implementation of this interface is org.mybatis.generator.internal.types.JavaTypeResolverDefaultImpl. You can provide your own implementation, and the default implementation has been designed for extensibility.
To provide your own implementation, specify the fully qualified class name in the XML configuration like this:
<javaTypeResolver type="mypackage.MyImplementation"> ... </javaTypeResolver>
MBG calls methods in this interface to perform functions that it cannot do on its own. The most important of these functions are:
- Translating project/package into a directory structure
- Merging Java source files in the event that an existing Java file of the same name/package exists.
The default implementation of this interface is org.mybatis.generator.internal.DefaultShellCallback. The default implementation simply concatenates project and package together and creates the necessary package directories if needed. The default implementation does not support merging of Java files, and will either overwrite or ignore files.
You can provide your own implementation. This would be the most important class to write if you want to integrate MBG into some other environment. For example, the Eclipse plugin provides an implementation of this interface that supports Java file merging when running in the Eclipse environment.
To provide your own implementation, supply an instance of the interface on the constructor to the org.mybatis.generator.api.MyBatisGenerator object. This cannot be configured through XML. If you are providing your own implementation of this interface then we assume that you are also providing some collateral code (like a new Ant task) to run your implementation.
MBG calls methods in this interface to report progress during the generation of files (a long running process). The default implementation of this interface is org.mybatis.generator.internal.NullProgressCallback which simply ignores all progress messages. You can provide an implementation of this interface to support progress notifications and cancellation of code generation.
Implementing this interface would be important when integrating MBG into other IDE environments. The Eclipse plugin provides an implementation of this interface that hooks into Eclipse's progress notification system.
To provide your own implementation, supply an instance of the interface on one of the org.mybatis.generator.api.MyBatisGenerator.generate() method calls. This cannot be configured through XML. Again, we assume that if you are providing your own implementation of this interface then you are also providing some collateral code (like a new Ant task or an IDE integration) to run your implementation.