Distribution of generated model implementation

In one of my posts I described how to transform StarUML classes structure into XML Schema implementation. I happy to announce that this approach (slightly modified) is used in the biggest bank in Poland. Main cause of replacing original version of transformation was its performance. XSLT 2.0 based implementation generator (using Saxon) is up to 50 times faster than native JavaScript.

When transformation is in place then implementation distribution policy should be defined. Of course anybody in company can generate a model by his own. However when you would like to control model versioning or provide any quality check then centralized model transformation service should be introduced.

This service can run as described in Continuous Integration practice – after each model commit. Verification results can be broadcasted and model implementation can be provided to a team. For that purpose Maven repository is perfect solution – zipped model is a regular artifact. Additionally when you decide to divide it into modules dependency between them can be easily kept.

Model transformation can be run directly using xml-maven-plugin but Maven has major disadvantage in this case. You must define number of project modules before execution. It is fine when you are building Java project. Complete and coherent model should keep also information about its subdomains. In that case we cannot define final number of modules without looking inside model itself. It is very inconvenient.

When we want to use Maven repository with number of modules controlled externally we can use plain old Apache Ant enriched with Maven Ant Tasks. These allows to resolve dependencies, handle pom files and install / deploy artifacts. Owing to it in one cycle we can transform a model, analyze subdomain definitions, zip artifacts, create poms and deploy  them into a repository.