Showing posts with label Eclipse. Show all posts
Showing posts with label Eclipse. Show all posts

Mar 10, 2017

Virgo 3.7.0 Released

 Today Florian announced the availability of Virgo 3.7.0. 

Virgo 3.7.0 brings several improvements (most notably Tomcat 8.5 and Spring Framework 4.2) and is paired by release 1.5.0 of the Virgo Tools, the Eclipse IDE integration.

This is the first official Virgo release since I joined the project as a committer, and it's also my first open source release in general. I am very happy and very proud of what we achieved.

Download Virgo and get Virgo Tools from the update site!

Jan 5, 2017

Virgo Tools 1.5

Since September 2015 I am a committer of the open source Eclipse Virgo project.

I have written several posts in the past about the Eclipse Virgo OSGi application server, and after having helped the project team with patches and bug fixes I have been invited by Florian, the project lead, to join the team as a committer.

I am an individual committer, contributing to the project in my spare time. I spent almost all of my effort on the Virgo Tools, the Eclipse plug-ins that integrate Virgo as a test environment in Eclipse. The most notable improvements of the upcoming version 1.5 of the Virgo tools will be:
  1. Support for PDE Plug-in projects. This is the possibility to develop for the Virgo runtime using the Eclipse PDE Tools, Plug-in Development Environment. This was one of the most requested and long standing missing features. See here and here.
  2. Improved support for plan projects. Virgo supports deployment of a number of artifacts, including Plans. Plans are XML files listing Bundles and other Plans to be activated. The Virgo Tools now provide fair support for having Plan files in Eclipse and deploying them to the test environment.
  3. Bug fixes and documentation
  4. Compatibility fixes for Eclipse Neon
We are currently planning to release the Virgo Tools 1.5 in January 2017 to be shortly followed by Eclipse Virgo 3.7.

Stay tuned!


Oct 31, 2012

Global JNDI support in Virgo Server 3.5 for Tomcat


This rather long post analyses four solutions to the problem of using data sources, and more in general JNDI in Virgo, the 4th being the one I recommend and decided to use, which consists in leveraging Tomcat's built-in JNDI provider in Eclipse Virgo Server for Apache Tomcat.

If you are not interested in the reasons why I dropped the first three, jump directly to the fourth.

Even if the post is mostly focused on JDBC data sources, once Tomcat JNDI provider is exposed to the application it can be used for any type of resource, not only data sources.

Most of the credits for this solution go to my colleague Stefano Malimpensa.

1. JDBC data sources in OSGi

The most correct approach to obtain a JDBC data source in a pure OSGi enterprise application consists in using the OSGi JDBC Service (see the official OSGi JDBC specification).  In Virgo, that means using Gemini DBAccess.

However, in my humble opinion Gemini DBAccess is not an optimal solution for a number of  reasons:

  • Gemini DBAccess is currently available only for Derby, and to use a different database you need to write your own implementation. Not a big issue but some extra effort anyway.
  • To integrate DBAccess with EclipseLink you should probably use Gemini JPA, which is affected by a bug that prevents connection pooling from working and is therefore not usable in production https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397
  • When using DBAccess with Gemini JPA you need configure connection parameters in each bundle's persistence.xml. I find this inconvenient because it is necessary to repackage the bundles every time the connection parameters change, and due to the modular nature of OSGi one complex application may include several bundles with persistence units.
  • If DBAccess is used without GeminiJPA, DBAccess will provide only a data source factory, and it will be the responsibility of your code to instantiate and configure the data source (e.g. pass in user name, password etc). In such case you would need to support a configuration file to let system administrators easily change connnection parameters, which is again extra effort.
  • DBAccess requires the OSGi registry, which means it would not work with legacy code or third party libraries written for J2EE. 
As the name implies, Gemini DBAccess is tailored to data base resources. If you want a single, unified approach for looking up any type of resource, then it's not a good fit for you.

2. Full JNDI in OSGi

 At this point you may want to try Gemini Naming,  which implements the OSGi JNDI service specification. Even Gemini Naming is in my humble opinion not an optimal solution:
  • There is no configuration console, nor a configuration file: the only way you can bind resources in the JNDI namespace is programmatically. This implies a lot of boring initialisation code, and you probably need to support a configuration file to let system administrators easily change configuration parameters, which is again extra effort.
  • Gemini Naming requires the OSGi registry, which means it would not work with legacy code or third party libraries written for J2EE.

3. Local JNDI declared inside a Web App


Virgo supports JNDI lookups for data sources inside a Web App. To achieve this you have to:
  • Include in the Web application the JDBC driver(s) and the pool implementation (e.g. Apache DBCP or Tomcat JDBC) as jars in your WEB-INF/lib folder
  • Configure web.xml to list the usual JNDI resource-refs
  • Include a Tomcat context.xml file in the Web App and configure it as explained here and here
The above will work for JDBC data sources but has the following draw backs:
  • You must include the JDBC driver and pool in every Web App of yours. This means that each Web App will have its own pool, even if they connect to the same database, and that you must repackage the WAR if you need to update the JDBC driver
  • JNDI lookup will work only in a thread originated by a HTTP request. This means that application bundles that are not WARs will not be able to obtain the data source via a JNDI lookup, unless their code is executed by a thread started by the Web container. In fact, the JNDI lookup will fail from threads created by Equinox: this is for example the case of code that observes OSGi framework lifecycle events (BundleListener) and need access the database when a bundle is installed or uninstalled.
In my case the main show stopper to this solution is the thread issue described above, because my application must access the database (and therefore the data source) from threads that are not always started by the Web container. If you are interested in the historical roots of this apparently strange limitation, I recommend reading this post by Neil Bartlett.

4. Tomcat global JNDI registry


Another option is available, which is not affected by any of the above issues and limitations and it consists in using Tomcat's global JNDI support. You gain a general purpose well tested and well documented JNDI registry capable of deploying any type of resource, not only data-sources (can even be extended to support custom resource types http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#Adding_Custom_Resource_Factories).

Please note that this solution will make the global JNDI namespace available, disabling the Web App java:comp/env context. In order words, you cannot use the java:comp/env prefix in your JNDI lookups. This should be an acceptable limitation, given that the java:comp/env prefix in any case would work only within a Web App and not from a plain OSGi bundle.

In order to use the Tomcat  JNDI registry for data sources in Virgo the following mandatory steps are required:

  1. Create a bundle fragment for Catalina to extend Virgo's Tomcat with connection pooling support. The Virgo distribution contains in fact a stripped down version of Tomcat that removes the libraries required for JDBC pooling. Luckily enough, you can create a fragment to contribute the libraries back to Catalina. You just need to make sure that your fragments are placed in the bundle repository folder, not in pickup.
  2. Create a bundle fragment for Catalina to make the required JDBC driver(s) available to the server and the application
  3. Create a fragment that gets the JNDI context from Tomcat and that registers in the JVM a global InitialContextFactoryBuilder
  4. Edit tomcat-server.xml and define your global resources

All the above fragments are a convenient method for extending Tomcat/Catalina to use third party libraries whose Java packages were not originally imported by the Virgo bundles. For further details refer to this post by Glyn Normington, the project lead of Virgo. If you are working with Virgo his personal blog is a must read!



1. The pool bundle fragment

Here is a sample for Apache DBCP. The MANIFEST.MF below is added to the DBCP JAR, that's why there is no Bundle-Classpath. Mind the fragment host header.

Manifest-Version: 1.0
Fragment-Host: com.springsource.org.apache.catalina
Bundle-ManifestVersion: 2
Bundle-Name: Tomcat DBCP
Bundle-SymbolicName: org.apache.tomcat.dbcp
Bundle-Version: 7.0.27
Bundle-Vendor: apache
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: javax.management,
 javax.management.openmbean,
 javax.naming,
 javax.sql,
 org.apache.juli.logging


2. The JDBC driver bundle fragment

Here is a sample for PostgreSQL. The MANIFEST.MF below is added to the PostgreSQL driver JAR, that's why there is no Bundle-Classpath. Mind the fragment host header.

Manifest-Version: 1.0
Fragment-Host: com.springsource.org.apache.catalina
Bundle-ManifestVersion: 2
Bundle-Name: PostgreSQL JDBC Driver
Bundle-SymbolicName: org.postgresql.jdbc.catalina
Bundle-Version: 9.2.1000
Bundle-Vendor: postgresql
Bundle-RequiredExecutionEnvironment: JavaSE-1.6


3. JNDI bridge fragment

Create a fragment with the following MANIFEST.MF that includes the two classes below and place it in the repository folder.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: JNDITomcatBridge
Bundle-SymbolicName: jndi.tomcat.bridge
Bundle-Version: 1.0.0.qualifier
Bundle-Vendor: org.example
Fragment-Host: com.springsource.org.apache.catalina;bundle-version="7.0.26"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.apache.catalina.mbeans;version="7.0.26"

The code below consists of two classes.

The first, GlobalJNDILifecycleListener, is a GlobalResourcesLifecycleListener subclass that downcasts the server instance to get the global JNDI context and that registers in the JVM NamingManager a custom InitialContextFactoryBuilder which wraps the JNDI context obtained from Tomcat.

Other options are of course possible, including doing everything in the custom implementation of InitialContextFactoryBuilder without subclassing the listener, but whatever approach you adopt, it is important to make sure that the invocation to NamingManager.setInitialContextFactoryBuilder occurs only once in the life of a Virgo server instance, because the method will fail and raise a runtime exception if it is called more than once.


import javax.naming.Binding;
import javax.naming.Context;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
import javax.naming.spi.NamingManager;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.Server;
import org.apache.catalina.mbeans.GlobalResourcesLifecycleListener;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;

public class GlobalJNDILifecycleListener extends GlobalResourcesLifecycleListener {
    private static final Log log = LogFactory.getLog(GlobalJNDILifecycleListener.class);

    @Override
    public void lifecycleEvent(LifecycleEvent event) {
        super.lifecycleEvent(event);
        if (Lifecycle.START_EVENT.equals(event.getType())) {
            Server server = (Server) event.getLifecycle();
            Context ctx = server.getGlobalNamingContext();
            ContextFactory factory = new ContextFactory(ctx);
            try {                
                NamingManager.setInitialContextFactoryBuilder(factory);
                log.info("Published Global Naming as default InitialContext");
                logJNDIEntries(ctx, null);
            } catch (NamingException e) {
                log.error("Naming Exception:", e);
            }
        }

    }

    private void logJNDIEntries(Context context, String prefix) throws NamingException {

        NamingEnumeration<Binding> namingEnumeration = context.listBindings("");

        while (namingEnumeration.hasMoreElements()) {
            Binding binding = namingEnumeration.next();
            String nameEntry = binding.getName();
            String fullName = (prefix == null || prefix.equals("") ? nameEntry : prefix + "/" + nameEntry);
            String entryClassName = binding.getClassName();
            if (Context.class.getName().equals(entryClassName)) {
                Context ctx = (Context) binding.getObject();
                logJNDIEntries(ctx, fullName);
            } else {
                log.info("Found: " + fullName);
            }
        }
    }

}
import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.spi.InitialContextFactory;
import javax.naming.spi.InitialContextFactoryBuilder;

/**
 * Simple implementation of {@link InitialContextFactory} that returns the global {@link InitialContext}
 * obtained from Tomcat
 *
 * @author giamma, stefano
 *
 */
public class ContextFactory implements InitialContextFactoryBuilder, InitialContextFactory {

    private Context context;

    public ContextFactory(Context context) {
        this.context = context;
    }
   
    @Override
    public InitialContextFactory createInitialContextFactory(Hashtable environment) throws NamingException {
        return this;
    }

    @Override
    public Context getInitialContext(Hashtable environment) throws NamingException {
        return context;
    }

}

4. tomcat-server.xml

 

Replace the listener with yours and declare your JNDI resources:
 
 <-- Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />  -->
 <Listener className="com.example.catalina.mbeans.GlobalJNDILifecycleListener"/>
 
<GlobalNamingResources>
 <Resource name="jdbc/db"
           type="javax.sql.DataSource" username="user" 
           password="password" 
           factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" 
           driverClassName="org.postgresql.Driver" 
           url="jdbc:postgresql://127.0.0.1/db" 
           maxActive="20" maxIdle="10"/>
</GlobalNamingResources>


You can now happily perform plain old new InitialContext().lookup() from every method of every class of your OSGi application deployed in Virgo, regardless of the origin of the thread.

Oct 1, 2012

Eclipse and the Ubuntu global menu

[Originally shared on G+ the 7th of August 2012]

For those working with Eclipse on Ubuntu, if you don't like the fact that the Eclipse menu does not blend into Unity's global menubar, you may want to try this hack https://bugs.launchpad.net/eclipse/+bug/618587/comments/46

You may experience some refresh glitches from time to time, but I personally prefer the menu to be integrated in Unity, especially because I use shortcuts way more than the menu.

First contact with Virgo Server, Virgo Tools, Eclipse Link

[Updated version of a post originally shared on G+ on the 22nd of June 2012]

My team and I have been working on an OSGi enterprise prototype since April 2012. We decided to use Eclipse Virgo Tomcat Server as our application server. Here is the experience collected so far, using Virgo 3.5M4 and version 1.0.0.201205110321-MILESTONE of the Virgo tools, both pre-release versions.

Documentation and other sources of information

Virgo comes with a lot of official documentation, and the documentation quality is generally high. On the other hand, if you look over the Web for articles, blog posts, forum posts etc you won't find that much besides the official documentation and the Eclipse community forums.
And while the quality of Virgo is generally very high, keep in mind that if you experience an uncommon issue, chances are that you will have to solve it on your own.
A good knowledge of the OSGi specification is really required to work with Virgo. Even long time Eclipse plug-in developers may have troubles developing proper OSGi bundles, because Eclipse plug-in developers are typically used to requiring bundles rather than importing packages, and because of the different boot delegation of Equinox when used in Eclipse, see http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/

Error reporting

Virgo is very good in giving you precise error and diagnostic information if your OSGi bundles fail to be resolved. The Virgo error messages are much much better than Equinox's and this is very very valuable.

Attention points

Even if Virgo is an OSGi application server, and even if it is based on Equinox, Virgo does not support split packages and does not favor required bundles.
I totally agree that split packages are evil, a very dangerous pitfall of the OSGi specification. So I was originally pretty happy with this decision, till I wanted to use the Equinox Registry in my application. In fact, I found out that the org.eclipse.core.runtime package is split across multiple bundles, and could not find a way to have the Equinox Registry bundles work "as is" in Virgo. A user in the Virgo Eclipse forums advised me to create a Plan (a virgo deployment artefact) that would include the bundles with the split package, but that did not solve my issue. I eventually worked around the problem by repackaging the Equinox registry bundles in a single bundle. Maybe other solutions are possible, but this was the fastest solution. The second important attention point is that Virgo authors dislike the use of Require-Bundle manifest header. I again understand the decision and I agree that one should prefer Import-Package, but what I dislike is that Virgo offers an alternative header attribute Import-Bundle that is Virgo specific, and does not belong to the OSGi specification. It is a sort of macro which will make Virgo enhance your bundle headers at deploy time to make them import all packages of the imported bundle. While this may appear as a convenient macro, it is Virgo specific and it will prevent your application from running in other OSGi containers or OSGi application servers (unless of course you modify the MANIFEST). So I have decided not to use it.

IDE Tools

If you are a long time Eclipse plug-in developer like me you are probably used to the PDE and love it, and you may expect to be able to develop bundles for Virgo using PDE.
Unluckily this is not possible, and you have to use the Virgo Tools, a totally different toolset. You could develop bundles with PDE, export them as binaries and deploy to Virgo, and it will of course work, but if you want to be able to build and run from the workspace your projects cannot be PDE plug-in projects but must be Virgo Tools' OSGi Bundle projects. The bad thing here is that developing with Virgo Tools is not as smooth as developing with PDE tools.
Here are a few examples:
  1. Much like PDE, Virgo Tools add a container to your project build path. The container should automatically populate the classpath according to bundle dependencies. In practice, the container is often out of sync resulting in spurious build errors, and you have to open the MANIFEST, add a blank, save and build to fix them. Plus, if you don't use autobuild, you'll need to build twice: once for the container to be updated after you change the MANIFEST and a second time for the code to be compiled after the container has updated. 
  2. If you want to import a package from another bundle in the workspace, you must enlist the other bundle in your Project References property page for the container to see it, but the MANIFEST editor will not help you, you'll need to switch to the source view and manually add the imported package. 
  3. If one of your workspace bundles exports packages that are included in some embedded JARs and you need another bundle to use classes from those packages, you'll have again to manually import the package, but you'll also need to add those JARs to your Java Project Buildpath, otherwise the dependant bundle will not compile, because the container will never see the JARs. 
There are a number of other smaller issues but the above are the most annoying.

Runtime Bugs

We spotted 3 defects, two related to the EclipseLink - Gemini JPA integration:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=381369
https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397

And one in the EcilpseGemini Web component, part of Virgo Server:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=380362

As usual the Eclipse community has been great in providing support and advice to workaround the issues.

Great Virgo features

  1. Very good diagnostic tools. Logs, dumps, detailed wiring information, all those features simplify problem determination of malfunctioning OSGi applications. 
  2. User regions. You can deploy bundles in isolated user regions (exported packages and offered OSGi services will be visible and usable only by bundles in the same region). You can have the same bundles deployed more than once in different user regions, because virgo will qualify the bundle symbolic name with the region name. 
  3. Deployment artifacts galore. You can deploy to Virgo Tomcat Server bundles, plain WAR files, Plans, PARs, Web Application Bundles (WAB) and all that flexibility allows you to deploy OSGi enterprise applications and plain old Web Applications within the same Virgo instance. Plain WARs can even load classes from the deployed OSGi bundles. 
  4. Hot swapping. You can easily remove/add a deployment artefact (e.g. a bundle) from/to the server, without stopping the server and the application. Of course you need to make proper use of OSGi ServiceTrackers, the OSGi Extender pattern and write your application code to deal with such use cases. 
  5. No more issues with 3rd party libraries When working with traditional J2EE application servers a frequent issue consists in classloading problems that may originate when your application and the app server use different versions of the same third party library. In such cases, depending on the app server of use, you have different ways of bypassing the problem, but none of them is really perfect, and in general, I wish I'd never have to deal with such issues. I am glad OSGi and Virgo free me from those problems.

Conclusion

All in all Eclipse Virgo is an exciting piece of technology. It's a full featured OSGi and Web container packaged with lots of useful diagnostic features that enables blending traditional Web Applications with OSGi (enterprise) applications. True modularity is visible in Virgo itself, which comes in 3 different flavors (Nano, Kernel, Tomcat Server). I believe it's a solid product and probably the best option for OSGi enterprise applications.

How to fix unreadable Eclipse tooltips in Ubuntu 12.04

[Originally posted on G+ on May 7th 2012]

Similarly to what happened in earlier versions of Ubuntu, the default tooltip colors of the Ambiance theme (Ubuntu default) results in unreadable Eclipse tooltips (black foreground text on black background).

In earlier versions of Ubuntu you could edit the Ambiance theme via Gnome control panel and change the tooltip colors. Unluckily, the new "Appearance" settings dialog of Ubuntu 12.04 allows you to select the theme but you cannot tweak its colors anymore.

So here is how you can fix the problem.
Install gnome-color-chooser:
sudo apt-get install gnome-color-chooser 
run the tool and switch to the Specific tab. Activate the Tooltip group and set your tooltip colors (I use black foreground on white background). Then, at the bottom of the dialog select the value Theme Default for the profile combo and press apply. The next time you start Eclipse it will honour your tooltip colors.

For those who may be interested, gnome-color-chooser will change your ~/.gtkrc-2.0 file.

Sonar and PDE Build

[Originally posted on G+ on the 17th of January 2012]

I finally completed the integration of #Sonar (http://www.sonarsource.org) in our PDEBuild (http://eclipse.org/pde/pde-build/) based build system.

Requirements

I was looking for an integration approach that would allow us to run the analysis on our OSGi bundles and to globally define default values for as many configuration parameters as possible (to avoid copy/pasting the same Sonar configuration values in every project build script), but I also wanted to provide project owners with convenient means of tweaking the configuration parameters of their projects and overriding default values when appropriate.

PDEBuild customBuildCallbacks.xml

After playing a bit with the many customisation hooks that #PDEBuild offers (see http://help.eclipse.org/galileo/topic/org.eclipse.pde.doc.user/tasks/pde_customization.htm) I believe that the best option is to use per project custom build call backs
(http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_custom_callbacks.htm).
These callbacks consist in a Ant script containing a number of predefined targets (a template is included in the #PDEBuild bundle) that, if declared in the project's build.properties file, will be invoked by #PDEBuild during many steps of each bundle's build process.

Some implementation details

I want Sonar analysis to take place if and only if the source code compiles successfully, therefore I believe the most appropriate callback is the post.name target (which becomes post.@dot for those bundles that are deployed as JARs and post.<jarname.jar> for those bundles that are deployed as folders (in Eclipse the latter usually feature the BundleShape: dir header attribute in their MANIFEST.MF file).

Being PDEBuild an Ant based build process, my first try consisted in using the Sonar Ant task (http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task) but that failed because such Ant task plays some tricks with the classloader to run Sonar that are not OSGi friendly and does not work within the Eclipse Ant Runner (and therefore within PDEBuild ), even if you package the Sonar Ant task as a bundle that contributes to the Eclipse Ant runner.

Luckily enough, Sonar provides also a standalone Java application for performing the analysis called SonarRunner (http://docs.codehaus.org/display/SONAR/Analyse+with+a+simple+Java+Runner), which can be successfully executed by PDEBuild . It's basically a shell script that starts a JVM to run the Sonar analyser. SonarRunner requires a global configuration file ($SONAR_RUNNER_HOME/conf/sonar-runner.properties) where you can set database connection parameters, server URL as well as the default source and binary folder (project relative path).

Given that by convention most of our bundles have a single source folder named src/ and that the vast majority of our bundles are deployed as JARs (in which case PDEBuild automatically names the binary folder @dot during compilation), the global file was a very good location for defining good defaults for most projects.

The remaining mandatory configuration parameters will be set on a per-project basis in the PDE custom build callback, by creating a dedicated properties file in the project root folder for SonarRunner just before executing it, as documented in the SonarRunner page.

Eventually, my SonarRunner global configuration looked like this:


    #----- Default Sonar server
    sonar.host.url=http://localhost:9000

    #----- MySQL
    sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
    sonar.jdbc.driver=com.mysql.jdbc.Driver

    #----- Global database settings
    sonar.jdbc.username=<user>
    sonar.jdbc.password=<password>

    #----- Default directory layout
    sources=src/
    tests=test/
    binaries=@dot/

    sonar.sourceEncoding=UTF-8

and a project specific callback to perform the analysis looked like this:


    <target name="post.@dot">
         <antcall target="sonar"/>
    </target>

    <target name="sonar" if="run.sonar">

    <propertyfile file="${plugin.destination}/sonar-project.properties">
    <!-- ==== Common properties, should not be changed ====-->
    <entry key="sonar.projectKey" value="studio:${bundleId}"/>
    <entry key="sonar.projectName" value="${bundleId}"/>
    <entry key="sonar.projectVersion"                    
             value="${sonar.projectVersion}"/>

    <!-- ==== Project specific properties -->
    <!-- <entry key="sources" value="${plugin.destination}/src"/> -->
    <!-- <entry key="binaries" value="${plugin.destination}/@dot"/>-->

    <!-- == Additional Sonar properties. Add project specific properties here == -->
    <!-- <entry key="sonar.exclusions" value="com/mycompany/*/.java,**/*Dummy.java"/> -->
    <!-- <entry key="sonar.profile" value="MyProfile"/> -->
    </propertyfile>

    <exec spawn="false" command="${sonar.runner}" failonerror="true" />
    </target>
where the property run.sonar is set globally somewhere earlier in the main build script, to make sure that the analysis (which can be very time consuming if you enable a lot of rules) is perfomed only if the build flavour is nightly or when explicitly requested by the build master.

Final comments
Congrats to the Sonar team for writing such a great piece of software! I am really looking forward for the next release which, according to the roadmap http://www.sonarsource.org/roadmap/, should be out in January 2012 and may provide the ability to use #Sonar as a generic code review tool, as opposed to current version 2.12 which supports code review limited only to the violations reported by Sonar.