Developing a Cartridge

Steps To Building Your Own Cartridge

  1. Write your andromda-cartridge.xml file.

Cartridge Descriptor

Each cartridge descriptor must comply with the following XSD Schema.

Writing templates for your cartridges

AndroMDA currently comes with multiple cartridges (i.e. BPM4Struts, Hibernate, EJB, etc.) if these cartridge don't fit your needs, you'll need to write your own and thats where understanding how to write cartridges comes into play.

The template scripting language

Apache's Velocity is the default Template Engine of AndroMDA, and for that we use the Velocity Template Language (VTL). You can find a reference of this language here.

The scripting object model

Different from AndroMDA 2.x, AndroMDA 3.x no longer places any model elements in a template context. You define the names of elements to make available to the template in your cartridge's andromda-cartridge.xml, like so:

    <modelElements variable="metafacade">
        <modelElement stereotype="metafacade"/>

Notice in the above example that the variable is defined as metafacade, on the <modelElements/> element; this means that the $metafacade variable would be made available to your template during AndroMDA model processing (if you were using the VelocityTemplateEngine, otherwise your variable notation could possibly be different of course).

Also notice the stereotype attribute on the <modelElement/> element. This stereotype tells AndroMDA to place each model element with the <<metafacade>> stereotype into a template of its own and process it. So this means, what used to be always $class in AndroMDA 2.x is now whatever you want to name it.

Another change to notice is the ouputPattern that's specified in the above example. You can see that its defined as $generatedFile. This allows us to set this variable name "$generatedFile" in our template and use the dynamic file name for the outputPattern. If you want to use the typical output notation of {0}/{1} from AndroMDA 2.x, that is also still available. If you'll remember from before: {0} represents the package name and {1} represents the name of the model element being processed.