...
Using this, we have typed communication, but, it mean we must have the same DTO (Data Transfer Object or ValueObject or Pojo or whatever you wanna call it) on both sides. That mean 2 sources files with means you have to have 2 source files defining the same data structures.
Duplicating information is the first step on getting out-to-date information. A good way to avoid this is write one side DTO and generate other. Is exactly that what Granite GAS3 Generator does.
Gas 3 is a AntTask to generate .as files based on Java .class files. In other to get this behavior, flex-mojos uses Gas3's generator. It works on a similar way. But it doesn't run over a java project, it runs on a flex project.
There is a sample here.
The steps to get code generation are simple:
1 - Add generator mojo goal In order to have Flexmojos generate code you have to add the generator mojo to your pom:
| Code Block |
|---|
<build> <plugins> <plugin> <groupId>org.sonatype.flexmojos</groupId> <artifactId>flexmojos-maven-plugin</artifactId> <version>%<version>${flexmojos.version}</version> <executions> <execution> <goals> <goal>generate</goal> </goals> </execution> </executions> </plugin> </plugins> </build> |
...
No matter what generator you are using, in order to function, the Generator needs to find your Java classes in the modules dependencies (Not the plugin-dependencies).
| Code Block |
|---|
<dependencies>
<dependency>
<groupId>org<groupId>com.sonatypeacme.flexmojos.itest<utils</groupId>
<artifactId>generator<artifactId>cool-jar<libs</artifactId>
<version>1.2.0-SNAPSHOT<3</version>
<scope>provided</scope>
</dependency>
</dependencies> |
All jar dependencies will be loaded at runtime. To filter what classes to generate use includeJavaClasses/excludeJavaClasses configuration.
To view all configuration options:
| Code Block |
|---|
mvn help:describe -DgroupId=org.sonatype.flexmojos -DartifactId=flexmojos-maven-plugin -Dfull=true
|
3 - Compile your project.
At this moment, it generate the sources with GAS3 style, but, you can configure your custom template.
4 - Configure your custom templates
To use custom templates it is necessary to configure flexmojos-maven-plugin to use flexmojos-generator-graniteds version 2.0. If this is not done, the custom templates are not used properly!
...
I usually set the scope of these artifacts to "provided" and group all of these java-dependencies together at the bottom of the pom with a comment that these artifacts are needed for code generation.
You could omit the declaration of the classes, but in this case the generator would generate Model classes for any java class it finds in the projects dependencies. So if you have some default Java imports in your master pom ... be prepared to have ActionScript classes being generated for every class in those packages 
| Code Block |
|---|
<build>
<plugins>
<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<version>${flexmojos.version}</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<includeJavaClasses>
<class>com.acme.utils.coolLibs.A</class>
<class>com.acme.utils.coolLibs.B</class>
<class>com.acme.utils.coolLibs.C</class>
<class>com.acme.utils.coolLibs.D</class>
<class>com.acme.utils.coolLibs.E</class>
<class>com.acme.utils.coolLibs.F</class>
</includeJavaClasses>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build> |
Flexmojos ships with multiple generators:
- Granite 1.1.0 (graniteds1)
- Granite 2.0.0 (graniteds2)
- Granite 2.1.0 (graniteds21)
- Granite 2.2.0 (graniteds22)
- Granite 2.3.0 (graniteds23) (default)
- Constraints (constraints)
In general all of the Granite generators are configured the same way. The default generator is the Granite 2.3 generator and there is usually no reason to select an older version. If however you want to select a non-default generator, you can use the "generatorToUse" configuration option.
| Code Block |
|---|
<build>
<plugins>
<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<version>${flexmojos.version}</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<generatorToUse>graniteds21</generatorToUse>
<includeJavaClasses>
<class>com.acme.utils.coolLibs.A</class>
<class>com.acme.utils.coolLibs.B</class>
<class>com.acme.utils.coolLibs.C</class>
<class>com.acme.utils.coolLibs.D</class>
<class>com.acme.utils.coolLibs.E</class>
<class>com.acme.utils.coolLibs.F</class>
</includeJavaClasses>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build> |
Granite Generator
Using custom generation templates
The Granite generator generates classes that can be used with a GraniteDS Server without modification. If howerver you would be intending to use a BlazeDS Server for communication these classes would not be compatable with BlazeDS. In order to be able to generate code that can be used with a BlazeDS Server, you need to provide some custom templates.
The Granite generator which is used per default supports the following types of classes:
- Enum types (Enum Java types)
- Entity types (JPA Pojos)
- Bean types (Non-JPA Pojos)
- Interfaces (Java Interfaces)
- Remote types (Java POJO Services)
For "Enum" and "Interface" the generator generates exactly one ActionScript class matching the package and the Classname of the original Java class into the main source directory.
| Info |
|---|
Keep in mind that these classes are updated upon every build. So if you modify them, the next time the generation goal is executed, the changes will be lost. I am probably going to change this as soon as I find the time. |
For the other types two classes are generated. One class matching the package and the Classname of the original Java class is generated into the main source directory (usually "src/main/flex") and a second class in the same package but with the name-suffix "Base" is generated to "target/generated-sources/garanite". This Base-class contains all the properties and methods of the original classes and is generated every time the generator is executed. The class in the main source directory extends this Base-class and can be used to customize the class as this file is only generated if if didn't exist and is left unchanged, if a file with that name allready existed.
| Code Block |
|---|
<build> <plugins> <plugin> <groupId>org.sonatype.flexmojos</groupId> <artifactId>flexmojos-maven-plugin</artifactId> <version>${flexmojos.version}</version> <executions> <execution> <goals> <goal>generate</goal> </goals> <configuration> <includeJavaClasses> <beanTemplate> <template>${project.basedir}/generatorTemplates/beanBase.gsp</template><class>com.acme.utils.coolLibs.A</class> <class>com.acme.utils.coolLibs.B</class> <class>com.acme.utils.coolLibs.C</class> <template>${project.basedir}/generatorTemplates/bean.gsp</template><class>com.acme.utils.coolLibs.D</class> <class>com.acme.utils.coolLibs.E</class> <class>com.acme.utils.coolLibs.F</class> </includeJavaClasses> </beanTemplate>configuration> <templates> <entityTemplate> <template>${project.basedir}/generatorTemplates/entityBase.gsp</template><enum-template>src/main/templates/enum.gsp</enum-template> <base-entity-template>src/main/templates/beanBase.gsp</base-entity-template> <template>${project.basedir}/generatorTemplates/entity <entity-template>src/main/templates/bean.gsp</entity-template> </entityTemplate> <base-bean-template>src/main/templates/beanBase.gsp</base-bean-template> <includeJavaClasses><bean-template>src/main/templates/bean.gsp</bean-template> <includeClass>org.example.TranslationItem</includeClass><interface-template>src/main/templates/interface.gsp</interface-template> <includeClass>org.example.TranslationItems</includeClass><remote-template>src/main/templates/remote.gsp</remote-template> <includeClass>org.example.TranslationNotFoundException</includeClass> <base-remote-template>src/main/templates/remoteBase.gsp</base-remote-template> </templates> <includeClass>org.example.TranslationAlreadyExistsException</includeClass></execution> </includeJavaClasses>executions> </configuration>plugin> </execution> |
This example shows an example configuration.
- <generatorToUse> this settings configures flexmojos-maven-plugin to use the generator version 2
- <beanTemplate> here you can give your custom templates vor the bean creation. Please keep in mind the paths are only examples an must be adjusted to your project.
- <entityTemplate> same like <beanTemplate>
- <includeJavaClasses> give here all classes which shall be created
...
By default generator mojo will only support one kind of granite generator... meaning you can only use graniteds21 with flexmojos 3.6
If you need to use graniteds2 or granite1 use this new approach:
| Code Block |
|---|
<plugin> plugins> </build> |
The above configuration would make Granite use my custom templates instead.
This approach is great as long as you have only a hand full of module artifacts. If however your application consists of many modules containing generated classes you start having to maintain multiple copies of the same templates or you start having relative paths to your templates. Both solutions are not really nice. I therefore introduced a modification in Flexmojos 4.x which allowss to use templates in the classpath (This time it's the plugin dependencies).
| Code Block |
|---|
<build> <plugins> <plugin> <groupId>org.sonatype.flexmojos</groupId> <artifactId>flexmojos-generator <artifactId>flexmojos-maven-plugin</artifactId> <version>${flexmojos.version}</version> <executions> <execution> <goals> <goal>generate</goal> </goals> <configuration> <includeJavaClasses> <class>com.acme.utils.coolLibs.A</class> <class>com.acme.utils.coolLibs.B</class> <class>com.acme.utils.coolLibs.C</class> <class>com.acme.utils.coolLibs.D</class> <class>com.acme.utils.coolLibs.E</class> <generatorToUse>graniteds2</generatorToUse><class>com.acme.utils.coolLibs.F</class> </includeJavaClasses> </configuration> <templates> <enum-template>class:com/acme/utils/templates/enum.gsp</enum-template> <base-entity-template>class:com/acme/utils/templates/beanBase.gsp</base-entity-template> <entity-template>class:com/acme/utils/templates/bean.gsp</entity-template> <base-bean-template>class:com/acme/utils/templates/beanBase.gsp</base-bean-template> <bean-template>class:com/acme/utils/templates/bean.gsp</bean-template> <interface-template>class:com/acme/utils/templates/interface.gsp</interface-template> <remote-template>class:com/acme/utils/templates/remote.gsp</remote-template> <base-remote-template>class:com/acme/utils/templates/remoteBase.gsp</base-remote-template> </templates> </execution> </executions> <dependencies> <dependencies> <dependency> <groupId>org<groupId>com.sonatypeacme.flexmojos<utils</groupId> <artifactId>flexmojos-generator-graniteds-2.0.0< <artifactId>templates</artifactId> <version>${flexmojos.version}</version> <version>1.3.4</version> </dependency>dependencies> </dependencies> </plugin> |
| Info | ||
|---|---|---|
| ||
Pay attention to plugin artifactId: flexmojos-generator-maven-plugin |
The same logic goes for granite1.
| Warning |
|---|
YOU ONLY NEED TO GO DOWN THIS ROAD WHEN YOU NEED TO USE OTHER GRANITE GENERATOR BESIDES THE DEFAULT. AS USUAL YOU CAN ONLY USE ONE GRANITE GENERATOR PER REACTOR, DUE TO API INCOMPATIBILITIES BETWEEN GRANITE GENERATOR RELEASES.
</plugins>
</build> |
This allows you to define the templates in one central artifact and to use these templates throughout your application without having to worry about keeping all templates in sync.
This approach does have one minor drawback though. You have to make sure the artifact is deployed to your local repo before you start the big build. This is due to the fact that Maven varifies the availability of all plugin dependencies before executing the build. This would fail if the templates module has not yet been deployed. For this I usually have a "minimal" profile in my projects, which only builds and deploys artifacts like this. After executing one minimal build I won't have to do this again.
Constrains Generator
The constraints Generator is used for replicating constants definied in Java.
| Code Block |
|---|
<execution>
<id>const</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<generatorToUse>constraints</generatorToUse>
<includeJavaClasses>
<include>net.flexmojos.oss.test.monitor.CommConstraints</include>
</includeJavaClasses>
</configuration>
</execution> |
The above example uses the constraint generator of flexmojos to replicate the constants used in Java to ActionScript in the flexmojos-unittest-support module. When executed, the generator generates an ActionScript class with the same name and Package to "target/generated-sources/flexmojos".
Known Issues
| Jira Issues | ||||
|---|---|---|---|---|
|