Event spies are Maven extensions - not a Maven plugin as such.
This one goes hand in hand with a Build Radiator site.
A build is a number of conceptual steps. Steps starting, passing and failing are events that this extension can pass to the build radiator (build cancellation is is outside the control of this tech).
In order to do the step updates on buildradiator.org ...
Go and get the JAR from Maven Central
Check that into (say) lib/
, then configure your build script to do:
mvn <phase name> -Dmaven.ext.class.path=lib/buildradiatorextension-1.1.jar
When you are using a service like "Circle CI", and you're happy to check that a 10K jar, you've avoided a bootstrap problem as those CI-as-a-service things won't let you acquire a Maven extension before launching Maven.
If you're using an on-premises Jenkins, you may prefer to simply place the same Jar in the <maven-install-root>/lib/ext/
folder.
In your project's POM, you need to identify artifactId/phases/executions where a step starts:
<properties>
<buildradiator.0>Compile=*</buildradiator.0>
<buildradiator.1>Unit Tests=buildradiator/process-test-resources/default-testResources</buildradiator.1>
<buildradiator.2>Service Tests=buildradiator/test/service-tests</buildradiator.2>
<buildradiator.3>Selenium Tests=buildradiator/test/selenium-tests</buildradiator.3>
<buildradiator.4>Package=*</buildradiator.4>
</properties>
One step can span multiple artifactId/phases/executions, of course, especially for a multi-module project.
The above was taken from the BuildRadiator
project.
See pom
If you mis-type a artifactId/phases/executions to the right-hand side of a =
, then the build will look like
this after it has finished:
It will also look like that if you mis-type a step-name on the left-hand side of a =
.
If you have hosted your own build radiator server:
<properties>
<buildradiator.baseurl>"https://buildradiator.mycompany.com"</buildradiator.baseurl>
</properties>
Be sure to get the http
vs https
right.
You need to set these for each CI initiated build, before Maven is launched:
export buildId=<the build number from Jenkin or the commit hash etc>
export radiatorCode=<radiator code from when you created the radiator>
export radiatorSecret=<radiator secret from when you created the radiator>
export buildingThisArtifact=<the name of the root level artifact>
Don't do these on your dev workstation, because updating the build radiator is the business of your CI daemon.
In your project's POM:
<properties>
<buildradiator.trace>true</buildradiator.trace>
</properties>
Artifact/Phase/Executions for BuildRaditor
itself:
- buildradiator/validate/enforce.versions
- buildradiator/process-resources/default-resources
- buildradiator/compile/default-compile
- buildradiator/process-test-resources/default-testResources
- buildradiator/test-compile/default-testCompile
- buildradiator/test/default-test
- buildradiator/test/unit-tests
- buildradiator/test/integration-tests
- buildradiator/test/functional-tests
- buildradiator/package/default-jar
- buildradiator/package/fat-jar
- buildradiator/install/default-install
Notice that JUnit has three executions - because that's how the "surefire" plugin was set up.
See pom.
Other projects may differ for artifacts, phases and executions. Here are those from an ordinary multi-module project on GitHub:
- multi/install/default-install
- core/process-resources/default-resources
- core/compile/default-compile
- core/process-test-resources/default-testResources
- core/test-compile/default-testCompile
- core/test/default-test
- core/package/default-jar
- core/install/default-install
- app/process-resources/default-resources
- app/compile/default-compile
- app/process-test-resources/default-testResources
- app/test-compile/default-testCompile
- app/test/default-test
- app/package/default-war
- app/package/default
- app/install/default-install