-
Notifications
You must be signed in to change notification settings - Fork 118
7. FAQ
This page describes the most frequent questions we face while converting projects based on subfloor to maven, using the maven parent poms as reference. It may also provide information if your creating a new project and face one of the situations listed here.
By default, every maven module defines structure or builds an artefact, and if we want it to build a jar artefact, maven already provides a default packaging system to enable this use case. If the packaging property is marked as jar, the result of what was compiled and added to the ${basedir}/target/classes will be packaged into a jar file with the name and version of the module.
We classify a complex artefact as something that groups resources and build results from various locations within a project. To help this, our maven build system already offers a plugin execution based on the maven-assembly-plugin. This plugin is defined as the standard for building assemblies using maven executions. By our design, a maven project should either be a multi module project, for holding other projects, or a module that publishes one and one alone artefact. To make sure this happens, it is important that the module that builds the complex artefact is classified with pom for the packaging property. The maven-assembly-plugin relies on assembly.xml files, located in ${basedir}/src/assembly and it will generate artefacts with the desired assembly configurations.
My project has java code with some tests classified as integration tests. What is necessary to make sure they are executed?
If you want to run ITs and filter out UTs but not fail the build when no UTs have been executed, you can use
mvn clean install -DrunITs -Dtest=none -DfailIfNoTests=false
Maven parent poms are prepared to handle javascript tests. To enable them, there are a set of things that need to be configured.
First, all our javascript tests should be executed via karma, and to do it we need to have the node/npm environment ready. For this, all you need is to place the package.json file (the file containing all the test environment dependencies) in the root of your project (we might review this in the future, since right now every project should have the same file, and we need to have a way to fetch this as an artefact). With this, the node and npm will be installed on your project and ready to be used. Later on, the npm install command is executed, fetching and installing the package.json dependencies, when the javascript test profile is activated.
The test environments sometimes requires javascript runtime dependencies. To configure them to be used in the javascript test environment use the ${js.project.list} property in conjunction with the maven dependency names. For each dependency that we need during javascript test time, we need to add its artifactId to this property (comma separated). Then, the maven dependency plugin will unzip each of this dependencies to ${basedir}/target/dependency.
Following this point, and with the fact that many of our runtime environments rely on a require-cfg file, our ant build environment has in place a target that groups all require-cfg files obtained from the declared dependencies. For maven, we also have this ready to be used, its profile is named javascript-requirecfg and can be used by having a context.js file in ${basedir}/src/main/config/javascript.
The next step is enable the javascript test profile. To enable it, all we need is to have a javascript test directory. It is defined as ${basedir}/src/test/javascript. Another important variable used in the karma execution is the karma config file. By default, it uses karma.ci.conf.js as configuration file, which can be overriden using ${karma.file.config}. This file should be located in the ${basedir}/src/test/config/javascript.
Another handy property is maven.test.skip, used to skip tests during a build. It is also applied to this profile, meaning that, javascript tests will not be executed if this property is defined.
Most of the projects in ant were set to use forkMode=perTest. In Maven this behaviour is achieved by setting false. pentaho-ce-jar-parent-pom sets to _true _(default value) both for maven-failsafe-plugin and maven-surefire-plugin. To overwrite the values configured in parent pom, you need to set _reuseForks _to false in your pom. Depending on the plugin you're using, add one of these to your pom.
<maven-surefire-plugin.reuseForks>false</maven-surefire-plugin.reuseForks>
OR
<maven-failsafe-plugin.reuseForks>false</maven-failsafe-plugin.reuseForks>
Test artifacts which are generated as part of a build should adhere to a specific naming convention. Artifact names should be appended with a '-tests' suffix.
pentaho-platform-core-tests-7.1-SNAPSHOT.jar
One of the ways to build your GWT project in maven is by using gwt-maven-plugin. You need to provide gwt <version>, gwt <module> and <webappDirectory> where it would keep the generated files. Here is an example.
<!-- Maven GWT plugin-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwt.version}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<module>org.pentaho.mantle.MantleApplication</module>
<webappDirectory>${project.build.directory}/${project.artifactId}-${project.version}</webappDirectory>
</configuration>
</execution>
</executions>
</plugin>
Occasionally some projects need to create a zip archive of the files generated by GWT build process. For this you could use maven-assembly-plugin.
The standard way to generate javascript documentation in the pentaho suite is using jsdocand the maven parent poms provide a profile to execute its generation using jsdoc-maven-plugin. All we need is provide a jsdoc configuration file in ${basedir}/src/doc/javascript/config/${docjs.config.file} . Here is an example.
This documentation execution, if configured, can be skipped using maven.jsdoc.skip, if defined in the command line arguments.