First, fetch the sources of the project you want to build from Github. For details, see Configuring Git Workflow - Sources.
Then, switch into the directory where you checked out the sources, and run this:
cd ~/my-github-stuff/jbosstools-base
# build everything and run all tests
mvn clean install
# or, if you don't want to install built artifacts into your ~/.m2 repo,
mvn clean verify
# or, if you only want to build your tests, but not run them,
mvn clean verify -DskipTests
# or, if you want to build your tests, but only run the unit tests, not integration tests
mvn clean verify -DskipITests
Here are the options we recommend to learn (& use as needed) when running JBoss Tools builds:
-
-e
or--errors
if the build should fail, produce execution error messages (stack trace) to help determine what happened. -
-fae
or--fail-at-end
continues the build until the end even when an error is detected. It allows for having more feedback at once: you get feedback for your whole build instead of only the parts that were built before the failure. -
-fn
or--fail-never
continues the build and reports errors, but does not return a failure code. This is useful if you want your build to successfully log errors, rather than failing if errors occur. -
-q
or--quiet
produces quiet output - only shows errors. -
-X
or--debug
produces execution debug output; you should DEFINITELY log to a file if using this option. -
-l
or--log-file some-log-file.txt
defines the log file into which all build output will go. Can also pipe output throughtee
if you want to see output in console AND save to a file, eg.,mvn verify -X | tee some-log-file.txt
-
-o
or--offline
will work offline. -
-U
or--update-snapshots
forces a check for updated releases and snapshots on remote repositories.
Note
|
Setting your build to only fail at the end with Use of Use of |
For the complete list of options, see Maven Command Line Options.
The profiles listed below give you control of the dependency resolution.
These profiles and properties control which versions of 3rd-party dependencies to use (eg., from Eclipse), by selecting which target platform to use.
-
-P maximum
will use the highest version of dependency JBoss Tools must be compatible with. These versions will be the one provided along with JBoss Developer Studio RCP application. -
-P unified.target
(Default) will resolve all dependencies from a single unified site on download.jboss.org. This site does not contain sources. Its performance are better than using multiple.target. -
-P multiple.target
will use a target platform which references multiple sites. This is mainly used if trying to build with a custom target platform that does not yet have a publishedunified.target
in Nexus. Useful when doing pull requests to update a target platform. -
-Dtpc.version=…
allows you to select a specific version for the target platform for this build. This can be used to test older targets than the minimal one, or some experimental target platforms. -
-Dno-target-platform=true
will disable target-platform resolution
For the complete list of profiles and flags, see JBoss Tools parent pom.xml.
Trying to build a target platform locally and want it to include sources? See Using Target Platforms.
Each mojo can have some options. You can list them with mvn help:describe groupId:artifactId:version:mojo
. This will give details about the mojo, and you’ll notice the expression on some parameters. expression tells you the system property that can be used to set the value.
If the mojo parameter was configured directly in pom.xml, then setting the expression for this parameter will be ignore.
Here is the most useful mojo list
-
-Dmaven.test.skip=true
disable compilation and execution of test bundles -
-DskipTests=true
disable test execution (not compilation) -
-Dmaven.test.failure.ignore=true
and-Dmaven.test.error.ignore=true
will not take into account test results the test results to decide whether build is successful or not. It can be used on Continuous Integration to let Jenkins decide on the result of the build: BLUE (everything OK), RED (Build Failed), YELLOW (some tests failed) -
-DdebugPort=8000
will enable debugging during test activation on port 8000. Then you can use Eclipse Remote Java debugging to debug your tests while they’re run from surefire
-
-Dtycho.localArtifacts=ignore
will prevent Tycho from reusing bundle artifacts built and installed locally. It ensures you’ll use dependencies from upstream sites to build your component
To build with Eclipse, see Building locally in Eclipse