|
Warning
|
This document is old and has been replaced by JBoss Tools Build FAQ |
Note that this article only discusses building from master (trunk). To work with another branch, see Learn.GitHub - Branching and Merging.
Looking for how to build our documentation? See Building JBoss Tools Documentation.
-
Java 1.6 SDK
-
Maven 3.0.3
-
About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools) - requires VPN access
-
Git client
Make sure your maven 3 is available by default and Java 1.6 is used.
mvn -version
should print out something like Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500) Maven home: /opt/maven3 Java version: 1.7.0_17, vendor: Oracle Corporation Java home: /opt/jdk1.7.0_17/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.8.3-203.fc18.x86_64", arch: "amd64", family: "unix"
See Maven Getting Started - Developers to add a reference to the JBoss Repositories into your settings.xml. You’ll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <profiles> <profile> <id>jboss-default</id> <repositories> <!-- To resolve parent artifact --> <repository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>http://repository.jboss.org/nexus/content/groups/public/</url> </repository> <repository> <id>jboss-snapshots-repository</id> <name>JBoss Snapshots Repository</name> <url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url> </repository> </repositories> <pluginRepositories> <!-- To resolve parent artifact --> <pluginRepository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>http://repository.jboss.org/nexus/content/groups/public/</url> </pluginRepository> <pluginRepository> <id>jboss-snapshots-repository</id> <name>JBoss Snapshots Repository</name> <url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>jboss-default</activeProfile> ... </activeProfiles> </settings>
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
mvn verify will perform all build and test steps, but it won’t install the bundles in your local repository. mvn install does install in you local repository. When an eclipse-plugin is installed in your repo, it is always used as default when resolving dependency. It is not possible to roll-back a local installation of a bundle, so in most cases, mvn verify is to be prefered to mvn install. However, if you want to build stuff sequentially through several maven invocations, and you want to resolve against just-built stuff, you’ll need to use mvn install.
In this page, we’ll encourage people to use mvn verify as much as possible to ensure isolation; but you can mvn install the same way if your use-case requires it.
What if I’ve already built something locally, but I want to build against the server version instead of my local repo?
There are two approaches that work here:
a) override temporarily when building, using
-Dtycho.localArtifacts=ignore
b) delete ~/.m2/repository/.meta/p2-local-metadata.properties
The target platform (TP) lists all dependencies (coming from Eclipse.or and other 3rd-party update sites) that are used by JBoss Tools. This target platform is materialized as an Eclipse p2 repository (formerly update-site) that is used during build to resolve dependencies. Target Platform is managed by JBoss Tools people, and only dependencies from this TP are allowed to be used in code.
If you need a new dependency in the TP, feel free to open a ticket to request it.
Here are several ways to build locally using this target platform. It’s up to you to choose the one that match your needs:
unified.target refers to the dependency as published in the Target Platform repository.
-
Pros:
-
Need only invoke Maven
-
Always up-to-date
-
-
Cons:
-
Evaluation is slower than when using a local target platform
-
Consume it by adding `-Punified.target`to your Maven command line
-
Pros:
-
Faster to use than a remote one
-
-
Cons:
-
Must re-fetch every time remote SNAPSHOT target platforms are updated, or a new one is released
-
Download TP as a zip and install it by yourself
You can either download the TP as a zip and unpack it into some folder on your disk. Just remember to update your ~/.m2/settings.xml file to point at the location where you unpacked it.
You can get it with a browser or a command line tool such as wget or curl at the following url:
-
current minimum Juno TP: jbosstoolstarget-4.20.6.Final-SNAPSHOT.zip
-
current maximum Juno TP: jbosstoolstarget-4.22.2.Final-SNAPSHOT.zip
-
latest Kepler TP: jbosstoolstarget-4.30.5.Final.zip
Then unzip the zip:
unzip *.target.zip -d /path/to/jbosstools-target-platforms/jbosstools/multiple/target/jbosstools-multiple.target.repo/
OR, use Maven to build it
Once you get the target platform available locally, you can use it instead of the remote sites to save time. For this, we can simply use Tycho target-platform mirroring: http://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors#Mirrors
As example, you can simply edit to your ~/.m2/settings.xml the definition of the repositories to mirror: (replace /home/hudson/static_build_env/devstudio/…. by a path where your local repository actuaaly stands)
<!-- IMPORTANT: Sites in target platforms: must not have trailing slash! -->
<settings>
<mirrors>
<mirror>
<id>jbosstools-target-platform-4.30.5.Final</id>
<mirrorOf>http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.30.5.Final/REPO</mirrorOf>
<url>file:///path/to/jbosstools-target-platforms/jbosstools/multiple/target/jbosstools-multiple.target.repo/</url>
<layout>p2</layout>
<mirrorOfLayouts>p2</mirrorOfLayouts>
</mirror>
</mirrors>
</settings>
This step is only useful if you are actually working on the parent or the target platforms and want to test local changes. Otherwise, Maven will simply retrieve parent and TP definitions from JBoss Nexus to perform your build.
Sometimes, Maven can’t find the upstream artifacts - parent pom, tycho plugins, minimum (Juno SR0) or maximum (Juno SR1 or later) target platforms. First try again with the "-U" maven option. Or maybe you want to build them locally in order to see how Tycho builds them, or contribute a fix. To work around resolution problems, just build locally:
cd /tmp; git clone https://github.com/jbosstools/jbosstools-maven-plugins.git cd /tmp; git clone https://github.com/jbosstools/jbosstools-build.git cd jbosstools-maven-plugins/tycho-plugins; mvn install; cd - cd jbosstools-build/parent; mvn install; cd - cd jbosstools-build/target-platforms; mvn install -Pjbosstools-minimum,jbosstools-maximum
-
Pros:
-
You build only your component
-
You only need source for your component
-
Speed to resolve deps is greater
-
You get generally the latest build for you component
-
-
Cons:
-
Takes some time to resolve dependencies on other component
-
Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change. More risk to get out of sync than with the staging site.
-
Tracked by https://issues.jboss.org/browse/JBIDE-11516
Example:
cd jbosstools-server mvn verify -P unified.target -Pjbosstools-staging-aggregate
-
Pros:
-
You build only your component
-
You only need source for your component
-
You get generally the latest build for you component
-
-
Cons:
-
Takes some time to resolve dependencies on other component
-
Can sometimes be out of sync if no build occured recently for a component you rely on and had some important change
-
Speed to resolve deps is worse
-
This profile is the one use for CI builds on Hudson.
Example:
cd jbosstools-server mvn verify -P unified.target -Pjbosstools-nightly-staging-composite
LINUX / MAC USERS
cd jbosstools-build mvn clean install -gs ~/.m2/settings.xml | tee build.all.log.txt
(tee is a program that pipes console output to BOTH console and a file so you can watch the build AND keep a log.)
WINDOWS USERS
cd c:\trunk\jbosstools-build
mvn3 clean verify -gs file:///$\{user.home}/.m2/settings.xml
or
mvn3 clean verify -gs file:///$\{user.home}/.m2/settings.xml >
build.all.log.txt
Remember to adjust your ~/.m2/settings.xml file to specify where you have your local target platform mirror built (or where you downloaded & unpacked a target platform zip. Windows users, if you don’t have a .m2 folder, see this article.
Each component, when built, produces a update site zip and an unpacked update site which can be used to install your freshly-built features and plugins into a running Eclipse or JBDS instance.
Simply point your Eclipse at that folder or zip, eg.,
jar:file:/home/rob/code/jbtools/jbosstools-server/site/target/server.site-*.zip!
or
file:///home/rob/code/jbtools/jbosstools-server/site/target/repository/,
and browse the site. If your component requires other upstream
components to install, eg., jbosstools-server depends on
jbosstools-base, you will also need to provide a URL from which Eclipse
can resolve these missing dependencies. In order of freshness, you can
use:
-
http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ (Nightly Trunk Site - updated every few hours or at least daily - bleeding edge)
-
http://download.jboss.org/jbosstools/builds/staging/composite/core/trunk/ (Composite Staging Site - updated every time a component respins - bleedinger edge)
-
http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/local-site/ (see the README.txt for how to use this site to refer to things you built locally - bleedingest edge)
Need to tweak a component to add a new plugin or feature? See How to add a new plugin or feature to an existing JBoss Tools 4.x project.
(To be rewritten soon…) http://lists.jboss.org/pipermail/jbosstools-dev/2012-September/005835.html
It’s fairly common to have plugins compiling in eclipse while tycho would not work. Basically you could say that tycho is far more picky compared to Eclipse PDE.
Check build.properties in your plugin. If it has warnings in Eclipse, you’ll most likely end with tycho failing to compile your sources. You’ll have to make sure that you correct all warnings.
Especially check your build.properties to have entries for source.. and output..-- these are needed to generate source plugins and features.
source.. = src/ output.. = bin/ src.includes = * src.excludes = src bin.includes = your own,files to include,in the jar
A new issue when building against juno shows that all compilation dependencies MUST be EXPLICITLY mentioned in your manifest.mf list of dependencies. A recent example of how this can cause compilation errors is the archives module, which failed to build due to the org.eclipse.ui.views plugin, and its IPropertySheetPage interface, not being found during the build. After investigation, it was discovered that the archives.ui plugin did not explicitly declare a dependency on org.eclipse.ui.views.
Inside eclipse and during Juno-based builds, however, the depencency was found and there were no compilation errors. This was because a plugin archives.ui explicitly dependend on (org.eclipse.ui.ide) had an explicit dependency on org.eclipse.ui.views. The IDE was able to see that archives.ui dependended on org.eclipse.ui.ide, and org.eclipse.ui.ide depended on org.eclipse.ui.views.
Resolving nested dependencies no longer seems to be guaranteed, and so anything you have a compilation dependency on must now be explicitly declared in your manifest.mf