Version 63

    This article is superceded by How to Build JBoss Tools with Maven 3.

     

    Note that this article only discusses building from trunk. If you need to build from a branch, or switch between branches and/or trunk, see How to Build JBoss Tools With Maven3 - Working With Branches.

     

    Looking for how to build our documentation? See Building JBoss Tools Documentation.

     

     

    Environment Setup

    Prerequisistes

    1. Java 1.6 SDK
    2. Maven 3.0.3
    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
    4. subversion client 1.6.X  (should work with lower version as well, but newer versions may not work as expected)

    Maven and Java

    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.3 (r1075438; 2011-02-28 12:31:09-0500)

    Java version: 1.6.0_25, vendor: Sun Microsystems Inc.

    Java home: /usr/java/jdk1.6.0_25/jre

    Default locale: en_US, platform encoding: UTF-8

    OS name: "linux", version: "2.6.42.3-2.fc15.x86_64", arch: "amd64", family: "unix"

     

    Maven settings

    Follow these instructions to add reference to 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


    {code: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>

    {code}

     

    Maven & Java Memory Configuration

     

    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.

     

    {code}

    set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m

    {code}

     

    Verify or Install ?

    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.

     

    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:

    Using published Target Platform definition (Recommanded)

    unified.target refers to the dependency as published in the Target Platfrom repository.

    • Pros:
      • No additional thing to do than invoking Maven
      • Always up-to-date
    • Cons: Speed - (to evaluate)

    Consume it by adding -Punified.target to you Maven invocation command-line

    Or, getting a local copy of the Target Platform

    Set up

    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. For convenience, the easiest is to unzip into jbosstools/build/target-platform/REPO/, since that's where the Maven or Ant process will by default operate.

     

    You can get it with a browser or a command line tool such as wget or curl at the following url: http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.SR2/<actualFilename>.target.zip

    and then unzip it here (the default path for -Dlocal.site, which means you can call maven with -Plocal.site and not need to pass in -Dlocal.site=file:///path/to/some/other/folder/ as well):

     

    unzip *.target.zip -d jbosstools/build/target-platform/REPO/

     

    (Note that the default path used for <local.site> will change every time a new target platform is released which is a significant change over the previous (eg., SR1, SR2), so if this breaks because the default not points at an empty folder, it's time to get a new TP! Hurray for build-time notification you're using an old target platform!)

    OR, use Maven+Ant to get it

    In that case, you also need Ant 1.8.2 or later.

     

     cd jbosstools/build/target-platform
     mvn clean install -Pget.local.target
    

     

    The get.local.target profile will resolve the target platform file, multiple.target, as a p2 repository on your local disk in ~/trunk/build/target-platform/REPO/. It may take a while, so you're better off from a speed point-of-view simply fetching the latest zip [5]. However, if you want to see what actually happens to create the TP (as done in Hudson) this is the approach to take.

     

    Since the Maven profile is simply a wrapper call to Ant, you can also use Ant 1.8 or later directly:

     

     cd jbosstools/build/target-platform
     ant help # show usage instructions
    

     

    Use

    Just add -P local.site -Dlocal.site=file:///path/to/target/repository/

    NOTE: You must specify a path starting with file:/// (three or more slashes) to avoid errors such as "p2.core.ProvisionException URI has an authority component".

     

    Examples

    LINUX / MAC USERS

    cd build

    mvn clean install -U -B -fae -e -P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/| tee build.all.log.txt

     

    WINDOWS USERS

    cd c:\trunk\build

    mvn3 clean install -U -B -fae -e -Plocal.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/ > build.all.log.txt

     

    (Optional) Build parent and target platform

    This step is only useful if you are actually working on the parent or the target platform and want to test it locally. Otherwise, Maven will simply retrieve parent and TP from JBoss Nexus to perform your build.

     

    This is only necessary when the TP change, prior to 3.3.Beta3

    svn co http://svn.jboss.org/repos/jbosstools/trunk jbosstools
    cd jbosstools/build/parent
    mvn clean install
    ...
    [INFO] Reactor Summary:
    [INFO]
    [INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]
    [INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]
    ...

     

     

    NOTE: You need not fetch the entire JBoss Tools tree from SVN (or Git).

    Instead, you can just fetch the build/ folder and one or more component folders, then as before,

    build the parent pom. After that, go into the component folder and run maven there.

     

    mkdir jbosstools

    cd jbosstools

    svn co http://svn.jboss.org/repos/jbosstools/trunk/build

    svn co http://svn.jboss.org/repos/jbosstools/trunk/jmx

    cd jbosstools/build/parent

    mvn clean install

    ...

    [INFO] Reactor Summary:

    [INFO]

    [INFO] JBoss Tools Target Platform Definition ............ SUCCESS [0.724s]

    [INFO] JBoss Tools Parent ................................ SUCCESS [0.461s]

    ...

     

    Building Individual Components Locally Via Commandline

    Build a component resolving to a recent aggregation build for other JBT dependencies (Recommanded)

    • Pros:
      • You build only your component
      • You only need source for your component
      • Speed to resolve deps: +
      • 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 jmx

    mvn verify -P unified.target -Pjbosstools-staging-aggregate

    Build a component resolving to the latest CI builds for other JBT dependencies

    • 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: -

     

    This profile is the one use for CI builds on Hudson.

     

    cd jmx

    mvn verify -P unified.target -Pjbosstools-nightly-staging-composite

     

    Build a component along with all its dependencies from sources ("bootstrap" build)

    This will build exactly what you have locally

    • Pros:
      • You are sure of the version of sources that is used for your JBT dependencies
      • You don't loose time in resolving your JBT deps
    • Cons:
      • You need sources for your dependencies too
      • You often build more stuff that what you really want to test

     

    cd ~/trunk/build

    mvn verify  -P unified.target -P jmx-bootstrap

    Building Everything In One Build Locally Via Commandline

    Assuming you have a local copy of the target platform in ${HOME}/trunk/build/target-platform/REPO/ (as explained previously:

     

    LINUX / MAC USERS

     

    cd build

    mvn clean install -P local.site -Dlocal.site=file:///${HOME}/trunk/build/target-platform/REPO/ | 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\build

    mvn3 clean verify -P local.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/

       or

    mvn3 clean verify  -Plocal.site -Dlocal.site=file:///C:/trunk/build/target-platform/REPO/ > build.all.log.txt

     

    If you downloaded the zip and unpacked is somewhere else, use -Dlocal.site=file:///.../ to point at that folder instead

     

    Building Locally In Eclipse

     

    First, you must have installed m2eclipse into your Eclipse (or JBDS). You can install the currently supported version from this update site:

     

    http://download.jboss.org/jbosstools/updates/indigo/

     

    Next, start up Eclipse or JBDS and do File > Import to import the project(s) you already checked out from SVN above into your workspace.

    Screenshot.png

     

    Browse to where you have the project(s) checked out, and select a folder to import pom projects. In this case, I'm importing the parent pom (which refers to the target platform pom). Optionally, you can add these new projects to a working set to collect them in your Package Explorer view.

    Screenshot-1.png

    Once the project(s) are imported, you'll want to build them. You can either do CTRL-SHIFT-X,M (Run Maven Build), or right-click the project and select Run As > Maven Build. The following screenshots show how to configure a build job.

     

    First, on the Main tab, set a Name, Goals, Profile(s), and add a Parameter. Or, if you prefer, put everything in the Goals field for simplicity:

     

    clean install -U -B -fae -e -Plocal.site -Dlocal.site=file://home/nboldt/tmp/JBT_REPO_Indigo/

     

    Be sure to check Resolve Workspace artifacts, and, if you have a newer version of Maven installed, point your build at that Maven Runtime instead of the bundled one that ships with m2eclipse.

    Screenshot-2.png

    On the JRE tab, make sure you're using a 6.0 JDK.

    Screenshot-3.png

    On the Refresh tab, define which workspace resources you want to refresh when the build's done.

    Screenshot-4.png

     

    On the Common tab, you can store the output of the build in a log file in case it's particularly long and you need to refer back to it.

    Screenshot-5.png

    Click Run to run the build.

     

    Screenshot-6.png

    Now you can repeat the above step to build any other component or plugin or feature or update site from the JBoss Tools repo. Simply import the project(s) and build them as above.

     

    Installation Testing - making sure your stuff can be installed

    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/trunk/runtime/site/target/runtime.site.zip! or file:///home/rob/code/jbtools/jbosstools/trunk/runtime/site/target/repository/, and browse the site. If your component requires other upstream components to install, eg., Runtime Detection depends on JBoss Common, you will also need to provide a URL from which Eclipse can resolve these missing dependencies. In order of freshness, you can use:

     

    1. http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ (Nightly Trunk Site - updated every few hours or at least daily - bleeding edge)
    2. http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ (Composite Staging Site - updated every time a component respins - bleedinger edge)
    3. 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)

     

    Adding a new feature or plugin to an existing component

     

    Need to tweak a component to add a new plugin or feature? See https://community.jboss.org/wiki/AddingAPluginandorFeatureToAnExistingComponent.

    Tips and tricks for making BOTH PDE UI and headless Maven builds happy

    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 your build.properties

    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,\
        list of,\
        files for inclusion,\
        in the jar>
    

     

    Check your manifest.mf dependencies

    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 indigo 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