wrapper goal
This mojo is used to generate the html to open flex applications, like what is done by flex builder.
To enable it, just add this mojo on plugins section:
<build> <plugins> <plugin> <groupId>org.sonatype.flexmojos</groupId> <artifactId>flexmojos-maven-plugin</artifactId> <version>%{flexmojos.version}</version> <executions> <execution> <goals> <goal>wrapper</goal> </goals> </execution> </executions> </plugin> </plugins> </build>
A simple hello world can be view here.
It's very simple to use, and has no need of configurations do get it running.
It support all standard templates made by Adobe. Just need to define templateURI parameter. Valid values to templateURI:
- embed:client-side-detection
- embed:client-side-detection-with-history (default)
- embed:express-installation
- embed:express-installation-with-history
- embed:no-player-detection
- embed:no-player-detection-with-history
You can point to a zip file containing all resource templates using "zip:/myTemplateFolder/template.zip" or "zip:C:/myTemplateFolder/template.zip". This file must be a zip and must have index.template.html inside it.
You can point to a directory containing resource templates using "folder:/myTemplateFolder/". For example, to make it compatible with Flex Builder, "folder:/html-template" may be used.
When using custom templates you may need to set custom parameters on your index.template.html. This can be done by configuring parameters:
<build> <plugins> <plugin> <groupId>org.sonatype.flexmojos</groupId> <artifactId>flexmojos-maven-plugin</artifactId> <version>%{flexmojos.version}</version> <executions> <execution> <goals> <goal>wrapper</goal> </goals> <configuration> <parameters> <swf>${build.finalName}</swf> <width>100%</width> <height>100%</height> </parameters> </configuration> </execution> </executions> </plugin> </plugins> </build>
All required parameters to Adobe's template are defined by default. But you can overwrite they at any time.
h3. Generating Html wrappers on war project:
This is a small hack done by Juraj Burian:
<execution> <id>wrapper generation</id> <goals> <goal>wrapper</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/${project.build.finalName}</outputDirectory> <templateOutputDirectory>${project.build.directory}/templates</templateOutputDirectory> <parameters> <swf>demo1-flex-${project.version}</swf> <title>demo1</title> <width>100%</width> <height>100%</height> </parameters> <htmlName>index</htmlName> </configuration> </execution>
External Project Wrapping
As of Flexmojos version 3.3 projects outside of the swf project wrapped directly. This is mainly motivated by the needs of projects packaged by the maven war plugin. However, other projects may make use of the new functionality in a similar fashion. They just require a bit of extra work since the input/output directories do not get setup automatically in order to play nicely with other plugins.
Wrapping a stand-alone swf project should still work exactly as it has in past releases.
WAR Sample Project
A sample project showing the usage for a war project is provided here:Â https://github.com/Flexmojos/flexmojos/tree/flexmojos-3.x/flexmojos-testing/flexmojos-test-harness/projects/issues/flexmojos-102/war.
Comments are included inline, but some special points to note are provided below:
- The wrapper mojo execution is not called in the swf project
- The wrapper mojo execution is called in the war project
- The parameters configuration element is ignored in the war project as they are taken instead from the swf artifact identified by wrapperArtifact
- The following other configuration elements are ignored in a war project as they are automatically wired as follows:
- templateURIÂ is the configured webapp directory of the war project (usually src/main/webapp by default)
- templateOutputDirectory is directed to the war plugin's temporary work folder in the target directory
- outputDirectory is also directed to the war plugin's temporary work folder in the target directory
The war plugin's webapp input directory will then be re-directed to the wrapper mojo's outputDirectory value.
Benefits of the New Approach
Context Sensitive Wrapping
The swf project should not be required to know about or care about how it is deployed into a server environment. Now, all files can be wrapped in the project that does care about server deployment.
Multiple Project Wrappers
Multiple different projects, or the same project in different build modes, can wrap the same swf artifact in different ways. For instance, a large development group may have multiple development integration, QA, and production/operations environments to worry about. Each may have its own unique network setup requiring varying levels of security, the presence/lack of proxies, or any of various other possibilities. This provides a relatively simple way to split out the differences in a way that can be naturally tracked by scm and configured in a familiar, accessible way.
Known Issues
- For external projects only:Â No project archetypes yet with original pre-packaged wrapper templates that can be cited in swf packaging (i.e. templateURI=embed:client-side-detection)
Known Issues