JBoss Tools Browser Simulator Standalone Application Build

What is JBoss Tools Browser Simulator (BrowserSim)?

Browsersim is quick and easy way to test how your web application going to look like on mobile device. Truth be told it cannot be 100% reliable and no a replacement for platform specific emulator.

BrowserSim is available as part of JBoss Tools Project, but there is simpler way to get your hand over it and try if it works for you.

How to configure your environment to get BrowserSim running

• Windows: 
• Only 32-bit Eclipse/JBDS is supported; 
• Apple QuickTime or iTunes must be installed (they contain Apple Application Support which provides WebKit engine for BrowserSim). 
• Linux: 
• WebKitGTK 1.2.0 or newer must be installed and available in the library load path. 
• This should be available on RHEL and Ubuntu by default, if not use your package manager to install libwebkitgtk 
• Mac OS X 
• It just works. 

What is required to build BrowserSim standalone application

Install prerequisites listed below:
• Java SDK 1.6
• Apache Maven 3.0.X
• Subversion client

How to build BrowserSim standalone application with maven

mkdir browsersim
cd browsersim
svn checkout https://svn.jboss.org/repos/jbosstools/workspace/dgolovin/org.jboss.tools.browsersim.app
mvn package -Dmaven.repo.local=.m2 -Declipse.p2.mirrors=false

then depending on used platform it can be started as

./target/products/org.jboss.tools.browsersim/linux/gtk/x86_64/browsersim
./target/products/org.jboss.tools.browsersim/linux/gtk/x86/browsersim

and will show iPhone2 skin by default. Use context menu on window title to:

• select device
• rotate your device
• change settings

Build XULRunner Eclipse p2 Repo with Tycho

Prerequisites

• Maven 3.0.0.alpha7
• Scala
• Subversive command line client
• Java SE 1.5+

Environment used to write this article

eskimo@desktop:~/Projects/jbt-xulrunner$ ~/Java/apache-maven-3.0-alpha-7/bin/mvn -v
Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 14:31:07-0800)
Java version: 1.6.0_0
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.31-21-generic-pae" arch: "i386" Family: "unix"

It is very simple process because Tycho does all work for you. All you need is to follow simple steps below.

Create separate folder for XULRunner build and make it current

eskimo@desktop:~/Projects$ mkdir jbt-xulrunner
eskimo@desktop:~/Projects$ cd jbt-xulrunner

Checkout XULRunner component from JBoss Tools Subversion repository. You need to use modular_build branch. It is temporary branch that is going to be merged to trunk next week, but I think it will stay here for a while after merge is happened.

First root only should be checked out from branch to avoid pulling out whole gigantic repository.

eskimo@desktop:~/Projects/jbt-xulrunner$ svn co --depth=files https://anonsvn.jboss.org/repos/jbosstools/branches/modular_build .

Then the same should be done for xulrunner component

eskimo@desktop:~/Projects/jbt-xulrunner$ svn co https://anonsvn.jboss.org/repos/jbosstools/branches/modular_build/xulrunner

After steps above it gets us to the JBoss Tools repository structure but with the only component.

Next step is pom.xml files generation, because this branch contains only parent-pom.xml in root. Scala is used to do it.

eskimo@desktop:~/Projects/jbt-xulrunner$ scala genpom.scala
Generate Agg for ./xulrunner
Modules: 8 Aggregator: 4

Now working copy is ready to build XULRunner Eclipse Feature and generate p2-repo for it. Make sure you are using maven3.

eskimo@desktop:~/Projects/jbt-xulrunner$ mvn install

In the end it should look like

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] trunk ............................................. SUCCESS [0.639s]
[INFO] xulrunner.all ..................................... SUCCESS [0.034s]
[INFO] xulrunner.plugins ................................. SUCCESS [0.006s]
[INFO] org.mozilla.xulrunner.cocoa.macosx ................ SUCCESS [5.637s]
[INFO] org.mozilla.xulrunner.gtk.linux.x86 ............... SUCCESS [3.595s]
[INFO] org.mozilla.xpcom ................................. SUCCESS [0.455s]
[INFO] org.mozilla.xulrunner.win32.win32.x86 ............. SUCCESS [3.238s]
[INFO] org.mozilla.xulrunner.gtk.linux.x86_64 ............ SUCCESS [4.083s]
[INFO] org.mozilla.xulrunner.carbon.macosx ............... SUCCESS [3.721s]
[INFO] site.all .......................................... SUCCESS [0.203s]
[INFO] org.mozilla.xulrunner.feature ..................... SUCCESS [0.563s]
[INFO] org.mozilla.xpcom.feature ......................... SUCCESS [0.571s]
[INFO] org.mozilla.xulrunner.site ........................ SUCCESS [4.045s]
[INFO] xulrunner.features ................................ SUCCESS [0.024s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:03.643s
[INFO] Finished at: Fri Apr 16 10:18:01 PDT 2010
[INFO] Final Memory: 89M/195M
[INFO] ------------------------------------------------------------------------

After that XULRunner Feature can be installed using p2repo from

xulrunner/site/org.mozilla.xulrunner.site/target/site

It should look in Eclipse Update dialog like on images below

Get Things Done with Tycho

Tycho is real Magic Wand for build engineers who supports Eclipse based projects. It just gets things done in minutes instead of weeks no matter what is size of your project. it just let it be built/tested in any way you want it:
- build and test everything at once
- build only what you needed piece by piece
It also lets any member of your team do the same and verify they local changes before commit them in source version control repository. It saves build server processor time and make continuous integration easier.

In reference to: tycho: Home (view on Google Sidewiki)

Remote Debugging for Eclipse Test Plugin Running by Tycho

When I report an issue in bug tracking system about a nightly build's JUnit test error I usually get simple answer that it is supposed to be working because it is working on developers workstation. After that routine conversation starts and it turns out that tests were running from development environment under Eclipse. Here I usually have to explain again and again that's not the same running tests from development environment and in build.

The right way to make yourself sure your tests will work in most cases without errors in nightly build is to start tests the same way as nightly build does. It was not easy for JBoss Tools tests until we created experimental branch and switched to Maven Tycho project. That means it is fairly easy to run tests now. Basically you need to change current directory and execute maven install goal. If it runs in development environment and in maven your tests are good and in most cases it should be fine in nightly build. Problems begin if it runs in development environment but it doesn't in maven. In this scenario you need to debug tests running in Tycho somehow and fix it. Fortunately it can be done using Java remote debugging support.

First of all you need to be sure you have built your sources you're going to debug and there is no differences between .java and .class files. If you're going find problem from previous build just get right tagged version and build it before debugging session.

Then open pom.xml for your Eclipse Test Plug-in and add Java VM arguments like it shown below (actual port numbers, server names and other parameters may be different, it depends from your environment)

   org.sonatype.tycho
      maven-osgi-test-plugin
      ${tycho-version}
      
      -Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=y
      
   

This snipped configured for remote debugging in OpenJDK 6, if your is different you might need to read [1] and configure it right for your java version.

Configure java projects with sources you're going to debug in Eclipse and create Remote Java Application configuration in Eclipse Debug Configuration dialog. Fill 'host' and 'port' fields with the same values from pom.xml argLine element. Press Apply button to save your changes and start your test plug-in from terminal like

$mvn install

It will go through build process and finally you ll see something like

[INFO] Expected eclipse log file: /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/data/.metadata/.log
[INFO] Command line:
/bin/sh -c cd /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test && /usr/lib/jvm/java-6-openjdk/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=linux -Dosgi.ws=gtk -Dosgi.arch=x86 -agentlib:jdwp=transport=dt_socket,address=8001,server=y,suspend=y -jar /home/eskimo/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.0.201.R35x_v20090715/org.eclipse.equinox.launcher-1.0.201.R35x_v20090715.jar -data /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/data -dev file:/home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/dev.properties -install /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work -configuration /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/work/configuration -application org.codehaus.tycho.surefire.osgibooter.uitest -testproperties /home/eskimo/Projects/jbt-modular/jst/tests/org.jboss.tools.jst.web.kb.test/target/surefire.properties
Listening for transport dt_socket at address: 8001

At this point build is waiting for you to attach remote debugger to the process because of using

suspend=y

in argLine element of your pom.xml file. So you need to return to eclipse and hit 'Debug' button in dialog opened before.

Build will continue at this point and stop on your break points so you can find out what is wrong with tests during nightly build.

[1] Java Platform Debugger Architecture - http://java.sun.com/javase/technologies/core/toolsapis/jpda/#Invocation