Versions Compared

Old Version 6

changes.mady.by.user Christofer Dutz

Saved on

compared with

New Version 7

changes.mady.by.user Christofer Dutz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The steps to get code generation are simple:1 -

 

 

Add generator mojo goal 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>

 

 2 -

Add a

...

dependencies to your model classes

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!

Code Block
<execution>

 

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.

List the classes

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 (smile)

 

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>

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>
              <bean-template>src/main/templates/bean.gsp</bean-template>
 <includeJavaClasses>             <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-maven-plugin</artifactId>
        <version>${flexmojos.version}</version>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <includeJavaClasses>
                <class>com.acme.utils.coolLibs.A</class>
        <generatorToUse>graniteds2</generatorToUse>        <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>
            <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>
    <dependency>      <dependencies>
            <groupId>org<groupId>com.sonatypeacme.flexmojos<utils</groupId>
           <artifactId>flexmojos-generator-graniteds-2.0.0< <artifactId>templates</artifactId>
      <version>${flexmojos.version}<      <version>1.3.4</version>
          </dependency>dependencies>
        </dependencies>
      </plugin>
Info
titleNotice

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.

Known Issues

Jira Issues
columnstype,key,summary
urlhttps://flexmojos.atlassian.net/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=project+%3D+FLEXMOJOS+AND+component+%3D+generator-mojo+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29&tempMax=1000