This document has been updated for JBoss Tools 4.3, but should also be valid for JBoss Tools 4.1 and 4.2.
Some tests require access to specific Java versions following the format:
jbosstools.test.jre.<major-version>
These are machine specific and provided either by command line:
mvn verify -Djbosstools.test.jre.7=/path/to/jdk1.7
or in ~/.m2/settings.xml
as a profile:
<profile> <id>jbosstools-jre</id> <properties> <jbosstools.test.jre.9>/Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home/</jbosstools.test.jre.9> <jbosstools.test.jre.8>/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/</jbosstools.test.jre.8> <jbosstools.test.jre.7>/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/</jbosstools.test.jre.7> <jbosstools.test.jre.6>/Library/Java/JavaVirtualMachines/jdk1.6.0_45.jdk/Contents/Home/</jbosstools.test.jre.6> <jbosstools.test.jre.5>/Library/Java/JavaVirtualMachines/jdk1.5.0.jdk/Contents/Home/</jbosstools.test.jre.5> </properties> </profile> <activeProfiles> <activeProfile>jbosstools-jre</activeProfile> </activeProfiles>
If not defined, you’ll erros like:
junit.framework.AssertionFailedError: Java Home provided by the jbosstools.test.jre.7 system property does not exist.
or
junit.framework.AssertionFailedError: The JRE5 location is not right
Note that for Jenkins jobs, this is set to a path similar to /qa/tools/opt/jdk1.7.0_last
.
p.s. if you do not have the right Java version installed you can reuse one of the others. But be aware your tests will not be running the exact same thing as jenkins.
Generally, you need only fetch the sources, and run mvn verify
. See How do I build via commandline or How do I build in Eclipse (with m2e) above.
Assuming your goal is to change sources in multiple projects, then build them all to verify everything still compiles, you will need to fetch sources, then build the projects in dependency order.
This workflow is useful when you’re looking to change framework code in an upstream project like Base on which Webservices or Server depends, and verify that API changes don’t break the downstream project’s code.
https://github.com/jbosstools/jbosstools-base git clone
https://github.com/jbosstools/jbosstools-server git clone
https://github.com/jbosstools/jbosstools-webservices ```
Then, publish the results of each build into your local `~/.m2` repo, use `mvn install` instead of `mvn verify`.
Thus downstream builds will use YOUR locally-built content, rather than looking to remote repositories for the latest published upstream dependencies.
```bash
cd ~/jbosstools/jbosstools-base; mvn install
cd ~/jbosstools/jbosstools-server; mvn install
cd ~/jbosstools/jbosstools-webservices; mvn verify
You could build all the individual components' update sites, and install from multiple sites. See Installing from a locally built update site.
Or, you can build your local projects into the JBoss Tools aggregate site, and install from that locally built site. This will require using -D flag overrides to ensure that you’re building the site based on the above locally built bits.
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-build-sites
cd ~/jbosstools/jbosstools-build-sites/aggregate/site; mvn install \
-Djbosstools-base-site=file://${HOME}/jbt/jbosstools-base/site/target/repository/ \
-Djbosstools-server-site=file://${HOME}/jbt/jbosstools-server/site/target/repository/ \
-Djbosstools-webservices-site=file://${HOME}/jbt/jbosstools-webservices/site/target/repository/
Then:
-
launch Eclipse and select
Help → Install New Software…
-
Click
Add…
-
Optionally, provide a name
-
Browse to the location of your locally built update site, such as
file://${HOME}/jbt/jbosstools-build-sites/aggregate/site/target/repository/
. -
Select the features you want to install
-
Click
Next>
, accept the licences, and continue until you can pressFinish
to complete the install
Use mvn install
to publish artifacts to your ~/.m2
folder. These will be checked when building anything which depends on those artifacts (in addition to checking the internet). This is also useful for doing subsequent offline builds with the -o
or --offline
flag, or chaining a series of builds together as noted in the previous question.
Use mvn verify
to build, but NOT install anything into your ~/.m2
folder.
To delete, do rm ~/.m2/repository/.meta/p2-local-metadata.properties
. Or you can simply ignore those artifacts with mvn verify -Dtycho.localArtifacts=ignore
What if I’ve already built something locally, but I want to build against the server version instead of my local repo?
You can use -Dtycho.localArtifacts=ignore
to force Tycho to ignore any locally available built artifacts that are not part of the project you build.
Thus if you just built jbosstools-server
locally, then go to jbosstools-openshift
normally this build would pick up its server
dependencies from the artifacts you just built from jbosstools-server
.
With -Dtycho.localArtifacts=ignore
the local jbosstools-server
artifacts will be ignored but all in jbosstools-openshift
will be honored since that is part of your build.
If that does not give the result you expect you can do rm ~/.m2/repository/.meta/p2-local-metadata.properties
.
This will remove all knowledge about locally built plugins - including things you might don’t want to have lost.
Thus try -Dtycho.localArtifacts=ignore
first, unless you know you don’t want to reuse any local built plugins.
Every time we make changes to the target platform, either to add/remove something, or to change the included version, we release a new version.
In order to verify we can build against the oldest version of a target platform (eg., one based on Eclipse 4.4.0, or "minimum" target platform) but also run tests against the latest for that stream (eg., based on Eclipse 4.4.2, or "maximum" target platform), we need to maintain multiple versions.
By default, your build will use the default "minimum" target platform specified in the JBoss Tools parent pom. To easily build against the default "maximum", use -Pmaximum. For a full list of build options and flags, see also Command Line Parameters.
Use -Dtpc.version=4.41.0.Final
or similar. For a full list of build options and flags, see also Command Line Parameters.
To skip running tests, you can use these Maven flags:
-
-Dmaven.test.skip=true
(also skip compilation) -
-DskipTests
(recommended)
If your reason for skipping tests is to see if everything can run without being stuck on the first test failure, you might also like these flags:
-
-fae
,--fail-at-end
: Fail at end of build only -
-fn
,--fail-never
: Never fail the build regardless of result
You can also cause test failures to result in JUnit output without failing the build using these flags:
-
-Dmaven.test.error.ignore=true
-
-Dmaven.test.failure.ignore=true
See also Maven commandline parameters.
Most of the time, you don’t need any profiles or -D properties. Here are some profiles and properties you might want to use in special cases.
-
-Pmaximum
: selects the default maximum target platform version instead of the default minimum one. Useful when running tests to verify that your code works against a newer target platform (eg., Eclipse 4.4.2 instead of 4.4.0) -
-Dtpc.version
: allows you to pick a specific target platform version from those available in Nexus.
To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here’s how to do so for Fedora, Ubuntu, Windows, OSX.
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
Note: support for -XX:PermSize
and -XX:MaxPermSize
was removed in JDK 8.0, as the flags are no longer necessary.
First, you will need VPN access.
Then, look in the build log for 2 lines like these - you need to determine the slave name, screen number (probably 0), and framebuffer directory (a path ending in xvfb):
Building remotely on ${SLAVE_NAME} in workspace /mnt/hudson/workspace/${JOB_NAME} Xvfb starting$ Xvfb :1 -screen ${SCREEN_NUM} 1024x768x24 -fbdir ${FBDIR}
Get the Xvfb_screen0 file from the remote server. If necessary, you might have to use the server’s FQDN instead of the slave name that appears in the log:
rsync -Pzrlt --rsh=ssh --protocol=28 ${USER}@${SLAVE_NAME}:${FBDIR}/Xvfb_screen${SCREEN_NUM} /tmp/
View the screen w/ xwud:
xwud /tmp/Xvfb_screen${SCREEN_NUM}
First, you will need VPN access.
Then, look in the build log for a line near the top like this:
Starting xvnc ... New 'vmg18....redhat.com:13 (hudson)' desktop is vmg18....redhat.com:13
Next, using vinagre or any VNC client, connect to the server:
vinagre vmg18....redhat.com:5913
If you’re seeing an error like this:
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
/home/rob/code/jbtools/github/jbosstools-server/archives/tests/org.jboss.ide.eclipse.archives.test/target/work/configuration/org.eclipse.osgi/136/0/.cp/libswt-pi-gtk-4509.so: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
When running a 64-bit OS, you need to install BOTH the 32- and 64-bit version of GTK2.
Thus, as root:
yum provides "*/libgtk-x11-2.0.so.0*"
# should get something like gtk2-2.24.24-2.fc20.x86_64
# but you need the .i686 version too
yum install gtk2.i686