Building

Note: Please have the latest version of Maven 3 installed.

To build the project from the command line after checking the code out, simply run

mvn -Dskip-ui-tests=true clean install

In Maven, the parent pom.xml serves as the central point on adding things to the build. It's also generally the most complicated piece of the build as it contains information that is shared by children pom.xml files. The first part of the parent pom.xml we'll look at contains identifying information:

Source

1. In your feature folder, add an empty sourceTemplateFeature folder to tell Tycho to generate sources for the feature. If you use git, place an empty .gitkeep file in there to ensure the folder will be checked out.

Repositories (p2)

p2 Repositories simply reference the parent pom and have a packaging attribute of eclipse-repository. The project must also include a category.xml if you want to publish features or a myProduct.product if you want to publish a product.

I didn't get a chance to adapt my orion experiment to minerva yet, but here is the pom.xml and category.xml.

UI Tests

<parent><groupId>org.aniszczyk.minerva</groupId><artifactId>minerva-parent</artifactId><version>1.0.0-SNAPSHOT</version></parent><artifactId>org.aniszczyk.minerva.ui.tests</artifactId><packaging>eclipse-test-plugin</packaging><name>Minerva UI Test Plug-in (Incubation)</name><properties><local-p2-site>file:/${basedir}/../org.aniszczyk.minerva-updatesite/target/site</local-p2-site><ui.test.vmargs>-Xmx512m -XX:MaxPermSize=256m</ui.test.vmargs></properties><repositories><repository><id>local-p2</id><layout>p2</layout><url>${local-p2-site}</url></repository></repositories><profiles><profile><id>skip-ui-tests</id><activation><property><name>skip-ui-tests</name></property></activation><properties><maven.test.skip>true</maven.test.skip></properties></profile></profiles><build><plugins><plugin><groupId>org.sonatype.tycho</groupId><artifactId>tycho-surefire-plugin</artifactId><version>${tycho-version}</version><configuration><testSuite>org.aniszczyk.minerva.tests.ui</testSuite><testClass>org.aniszczyk.minerva.tests.ui.AllTests</testClass><useUIHarness>true</useUIHarness><!-- Set UIThread to true for UI Tests that do not use SWTBot --><useUIThread>false</useUIThread><product>org.eclipse.sdk.ide</product><argLine>${ui.test.vmargs}</argLine><application>org.eclipse.ui.ide.workbench</application><dependencies><dependency><type>p2-installable-unit</type><artifactId>org.eclipse.pde.feature.group</artifactId><version>${platform-version}</version></dependency><dependency><type>p2-installable-unit</type><artifactId>org.aniszczyk.minerva.feature.group</artifactId><version>[1.0.0,2.0.0)</version></dependency><dependency><type>p2-installable-unit</type><artifactId>org.eclipse.cvs.feature.group</artifactId><version>[1.1.2,2.0.0)</version></dependency></dependencies></configuration></plugin></plugins></build>

In this case, we use the built in support in Tycho to launch an Eclipse to test the UI.

We also ensure any features are installed that we need (like our minerva feature).

Under the covers, the UI tests use SWTBot via @RunWith(SWTBotJunit4ClassRunner.class)

Documentation

WikiText

We will use Mylyn Wikitext to generate our documentation from the Eclipse wiki (Eclipsepedia)

TODO

Javadoc

TODO: GMF Tooling Example

Static Code Analysis

Manually

You can use code coverage by adding the proper maven plug-in dependencies in the parent pom.xml.

and then you can simply run a ***mvn sonar:sonar*** after your build to push reports to Sonar.

Code Coverage with Jacoco

Jacoco is the future of the Emma and EclEmma projects and allows to produce code coverage simply by setting a java.agent VM argument and without need to provide an instrumentated version of compile code. Then it does not require additional work, and a Jacoco Maven plugin is available to make configuration easier.

In the parent pom.xml of your tests, set the following stuff (see file in tree):

<projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>org.eclipse.gmf-tooling</groupId><artifactId>tests</artifactId><packaging>pom</packaging><version>2.4.1-SNAPSHOT</version><parent><groupId>org.eclipse.gmf-tooling</groupId><artifactId>parent</artifactId><version>2.4.1-SNAPSHOT</version><relativePath>../</relativePath></parent><modules><module>org.eclipse.gmf.tests</module><module>org.eclipse.gmf.tests.lite</module><module>org.eclipse.gmf.tests.xpand</module><module>org.eclipse.gmf.tests.xpand.migration</module></modules><profiles><profile><id>jacoco</id><activation><activeByDefault>true</activeByDefault></activation><properties><!-- Properties to enable jacoco code coverage analysis in Sonar --><sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin><sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis><!-- When running in children tests/* modules, all reports will be in tests/target/jacoco.exec --><sonar.jacoco.itReportPath>../target/jacoco.exec</sonar.jacoco.itReportPath></properties><build><plugins><!-- Enabling use of jacoco --><plugin><groupId>org.jacoco</groupId><artifactId>jacoco-maven-plugin</artifactId><version>0.5.3.201107060350</version><executions><execution><goals><goal>prepare-agent</goal></goals><configuration><!-- Where to put jacoco coverage report --><destFile>${sonar.jacoco.itReportPath}</destFile><includes>*.gmf.*</includes><!-- Append allows all reports from all executions to be stored in a single file --><append>true</append></configuration></execution></executions></plugin></plugins></build></profile></profiles></project>

Then all your children tests modules will inherit from this extension and they'll automatically have test coverage enabled.

WARNING: If your tests are configured with a <argLine...> element, then put into this argLine element ${tycho.testArgLine} to avoid overriding Jacoco plugin configuration:

Signing

There's a /usr/bin/sign binary on build.eclipse.org that you feed a zip file containing your binaries.

Signing is a bit complicated on hudson.eclipse.org and if your using tycho requires the usage of a special maven plugin.

The process the maven plugin goes through is comprised of 4 mojo's and the leveraging of a bit of ant with the ant-maven-plugin.

pack - run the pack operation from the embedded eclipse equinox packing tool which itself is a wrapper over the pack tooling in the jdk.

sign - copies the output from the pack over to the signer directory (should be configured for your project) and then executes the signer script. Once the signer script has finished processing the mojo will copy the signed work back to the target directory of the executing project

repack - once more packs the project

fixCheckSums - currently have to manually clean up the artifact.xml files for the new checksums of the signed and packed artifacts

deploy site somewhere

For jetty we deploy the site to a static development repository under the typical p2 repository setup and when we want to release it public we copy the development directory to a named directory for the version and then update the p2 aggregate artifact and component xml files.

Example Usage:

<profiles><profile><id>build-server</id><build><plugins><plugin><groupId>org.eclipse.dash.m4e</groupId><artifactId>eclipse-signing-maven-plugin</artifactId><version>1.0.4</version><executions><!-- Pack the p2 repository. --><execution><id>pack</id><phase>package</phase><goals><goal>pack</goal></goals></execution><!-- Sign the p2 repository --><execution><id>sign</id><configuration><signerInputDirectory>/home/data/httpd/download-staging.priv/rt/PROJECT</signerInputDirectory></configuration><phase>package</phase><goals><goal>sign</goal></goals></execution><!-- Repack the p2 repository --><execution><id>repack</id><configuration><inputFile>${project.build.directory}/signed/site_assembly.zip</inputFile><!-- this is output from signer mojo --></configuration><phase>package</phase><goals><goal>pack</goal></goals></execution><!-- Signing and packing alters checksums so fix them --><execution><id>fixCheckSums</id><phase>package</phase><goals><goal>fixCheckSums</goal></goals></execution></executions></plugin><!-- This is what I use to deploy a p2 repository someplace to test from before manually making active. --><plugin><artifactId>maven-antrun-plugin</artifactId><executions><execution><id>deploy</id><phase>install</phase><goals><goal>run</goal></goals><configuration><tasks><deleteincludeemptydirs="false"><filesetdir="/home/data/httpd/download.eclipse.org/jetty/updates/jetty-wtp/development"><includename="**"/></fileset></delete><copyincludeemptydirs="false"todir="/home/data/httpd/download.eclipse.org/jetty/updates/jetty-wtp/development"><filesetdir="target/checksumFix"><includename="**"/></fileset></copy></tasks></configuration></execution></executions></plugin></plugins></build></profile></profiles>