Plugin Documentation

Goals available for this plugin:

Goal Description
coremedia-application:find-filter-tokens This mojo parses all configuration files found below the configured outputDirectory for ant-style filter tokens. If any are found it prints out the files containing tokens and the tokens itself. In addition it creates a properties file below your projects build directory named like the output directory
coremedia-application:help Display help information on coremedia-application-maven-plugin.
Call mvn coremedia-application:help -Ddetail=true -Dgoal=<goal-name> to display parameter details.
coremedia-application:package-inplace This mojo servers two very distinct purposes:
  • Generate a single runnable CoreMedia application.
  • Aggregate multiple CoreMedia applications into a single deployable unit with shared lib,bin and configurations folders. Optionally also war artifacts can be aggregated into a common servlet-container (only tomcat is supported).
Generate a single runnable application
  1. The application is generated in the ${project.build.directory}/${project.build.finalName}/ folder by unpacking all coremedia-application or zip dependencies and copying all JAR dependencies of them in the ${project.build.directory}/${project.build.finalName}/lib folder.
  2. In the last step all file in the sourceDirectory are copied over the unpacked dependent zips to allow overwriting of configuration etc. in the last step of assembling the application.
Merge multiple applications

All dependencies of type coremedia-application and of type zip are detected as candidates to merge and they are handled as if it were base artifacts for a single coremedia application described above. Be aware that this feature cannot be used for skinny coremedia-application artifacts e.g. no dependencyManagement can be applied to the extraction of the dependencies.

Merge war artifacts

If there are also war dependencies, the mojo extracts them into a webapps folder below the configurable tomcatPath root. Be aware that this feature cannot be used for skinny war artifacts e.g. no dependencyManagement can be applied to the war extraction.

coremedia-application:package-webstart This mojo produces artifacts of type coremedia-webstart-application. It can be used in two different fashions:
  • assemble all given resources, download all jar dependencies and sign them.
  • unpack a dependency of packaging type coremedia-application and sign all contained jar artifacts.
The jnlp file for the resulting webapp will be created from a provided jnlp template using the velocity templating engine. The jars will be signed by using the maven-jarsigner-plugin internally. The artifacts that are produced by this mojo can be referenced as war dependencies, eg. for merging war and coremedia-application artifacts with the package-place goal.
coremedia-application:rpm The RpmMojo provides easy capabilities to package your applications as rpm native packages. By using the great redline-rpm library, the plugin can build rpms even on windows machines. The Mojo comes with three inbuilt preconfigured rpm configurations:
  • The default configuration packages everything below the ${outputDirectory} which is by default set to ${project.build.directory}/${project.build.finalName}
  • The coremedia-tomcat configuration packages a default tomcat layout but additionally sets execution flags to the bin directory and creates symlinks to /var/tmp/coremedia/[rmpConfig.name|artifactId] for the temp dir and a symlink /var/log/coremedia/[rmpconfig.name|artifactId] for the logs directory. The conf directory will be created using the rpm configuration directive.
  • The coremedia-application configuration packages a default coremedia-application layout but additionally sets execution flags to the bin directory and creates symlinks to /var/tmp/coremedia/[rmpconfig.name|artifactId] for the var/tmp dir and a symlink /var/log/coremedia/[rmpConfig.name|artifactId] for the var/logs directory. The config and the properties directories will be created using the rpm configuration directive.

Defaults for rpmConfig

  • [rpmConfig.name] to ${project.artifactId}
  • [rpmConfig.group to "Unspecified"
  • [rpmConfig.version] to "${project.version}"
  • [rpmConfig.release] to see extra explanation below
  • [rpmConfig.host] to the ip of the build machine if it can be determined
  • [rpmConfig.packager] to the java systemproperty "user.name"
  • [rpmConfig.type] to BINARY
  • [rpmConfig.architecture] to NOARCH
  • [rpmConfig.os] to LINUX
  • [rpmConfig.targetRoot] to /opt/coremedia
  • [rpmConfig.defaultuser] to "coremedia"
  • [rpmConfig.defaultgroup] to "coremedia"
  • [rpmConfig.defaultfilemode] to "0644"
  • [rpmConfig.defaultdirmode] to "0755"


Defaults for rpmConfig.release

Since the versioning scheme of rpm artifacts does not have a "SNAPSHOT" syntax and therefore requires an incremental integer, we have to handle a reasonable default it with more care.

  • In case of a SNAPSHOT version of ${project.version} we use the start time of the maven build in unixtime. In combination with the rpm version attributio set to ${project.version} (with SNAPSHOT suffix) we can guarantee a rpm update to take the most recent rpm.
  • In case of a release by default a 1 is used as the first release version. If however you have set a version with a number as a qualifier this number will be used for release, e.g. project.version=1.2-2 will lead to a rpm.version=1.2 and a rpm.release=2.


coremedia-application:war-it Archives the result of the package-webstart goal and attaches the war file as project artifact.
coremedia-application:zip-it Zips the result of the package-inplace goal and attaches the zip file as project artifact. There are two modes:
  • Deployable Application (default)
  • Skinny Application

The deployable application corresponds to the generated artifact in the ${project.build.directory}/${project.build.finalName}/ folder. If a skinny application is chosen all referenced jar artifacts are not included in the packaged artifact e.g. no lib/*.jar and also no ${project.build.directory}/${project.build.finalName}/config/[applicationName]/framework/*.jar.

If war artifacts are merged in, their jars won't be excluded from the zipped artifact since they are loaded by an isolated classloader and therefore no dependencyManagement can be applied on further aggregation layers.

System Requirements

The following specifies the minimum requirements to run this Maven plugin:

Maven 3.1.1
JDK 1.7
Memory No minimum requirement.
Disk Space No minimum requirement.

Usage

You should specify the version in your project's plugin configuration:

<project>
  ...
  <build>
    <!-- To define the plugin version in your parent POM -->
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>com.coremedia.maven</groupId>
          <artifactId>coremedia-application-maven-plugin</artifactId>
          <version>2.8.3</version>
        </plugin>
        ...
      </plugins>
    </pluginManagement>
    <!-- To use the plugin goals in your POM or parent POM -->
    <plugins>
      <plugin>
        <groupId>com.coremedia.maven</groupId>
        <artifactId>coremedia-application-maven-plugin</artifactId>
        <version>2.8.3</version>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>

For more information, see "Guide to Configuring Plug-ins"