>How to Build XSL Tools with Ant4Eclipse

>Sometimes there is a need to have a local build for a particular plugin or project. However some eclipse builds can get quite robust in their path names. This is particularly an issue on Windows systems where path length limitations can get in the way. So this is one reason one might want to have local builds. Another maybe that you want to build more often or differently than what is done on the official build server. I’m going to show how one can use Ant4Eclipse to setup a local build of the main XSL Tools plugins. Here is what is going to be needed:

  • Ant4Eclipse compiled from the CVS “M_5” branch in the sourceforge repository. Thanks to Nils Hartmann a committer on Ant4Eclipse for his help debugging some compilation issues.
  • The eclipse OSGI jar from at least Eclipse 3.4.
  • The eclipse batch compiler ECJ jar from eclipse 3.4 or greater.
  • Ant 1.7.x or greater (ant 1.6.5 may work but I ran into some issues with it).
  • Your plugin projects checked out into your workspace or into a workspace for the build.
  • A target platform that contains the necessary supporting jars. In my case, it needs the WST, Orbit, Eclipse 3.5, GEF, XSS, and EMF plugins available.

If you are going to be automating these builds using a continuous integration application like Luntbuild, Hudson, Continuum, CruiseControl, or other application, then you will need to setup the appropriate checkout procedures. Luntbuild allows you to specify this when setting up the build schedule, and it does not have to be integrated into the system. The ant build that will be used here does not check out the code, it just runs a build.

Build Requirements:

This build will be the most basic of the continuous integration builds. It will do the following:

  • Compile all the Plugins.
  • Jar the Plugins.
  • Be platform independent.
  • Fast

That’s it. By platform independent this build can run through Eclipse’s Ant launcher, at the command line, or on a build server. The code does have to refactored to make the targetPlatform locations rely on an ant property instead of being hard coded. It will have no dependencies for server specific settings beyond having the necessary jar files. Speed is important because I do not want to weight 10 hours to see if it completed, the build should run no longer than a couple of minutes to compile.

The Build Script:

This should be pretty straight forward, the only gotcha with Ant4Eclipse that may need to be addressed is that it currently requires Project specific settings in order to correctly determine the appropriate JDK to be used during compilation.

<project name="Ant4Eclipse for XSL Tools">

<property name="ant4eclipse.lib" location="./lib" />
<property name="jdk_15.home" location="${java.home}" />
<property name="jdk_14.home" value="${jdk_15.home}" />
<property name="workspace" location=".." />
<property name="pluginDestination" location="${workspace}/org.eclipse.wst.xsl.releng/build" />

<taskdef resource="net/sf/ant4eclipse/antlib.xml" />

<mkdir dir="build" />
<mkdir dir="${pluginDestination}/plugin" />
<mkdir dir="${pluginDestination}/plugin/plugins" />

<targetPlatform id="eclipse-3.5">
<location dir="/home/dcarver/eclipse35TargetBuild/eclipse" />
<location dir="/home/dcarver/eclipse35TargetBuild/orbit/eclipse" />
<location dir="/home/dcarver/eclipse35TargetBuild/wst/eclipse" />
<location dir="/home/dcarver/eclipse35TargetBuild/emf/eclipse" />
<location dir="/home/dcarver/eclipse35TargetBuild/xsd/eclipse" />
<location dir="/home/dcarver/eclipse35TargetBuild/gef/eclipse" />

<jreContainer default="J2SE-1.5">
<jre id="J2SE-1.4" location="${jdk_14.home}" />
<jre id="J2SE-1.5" location="${jdk_15.home}" />

<target name="build.plugin">
<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xml.xpath2.processor" destDir="${pluginDestination}">
<targetPlatform refid="eclipse-3.5" />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xml.xpath.core" destDir="/home/dcarver/temp/test/plugin">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xml.xpath.ui" destDir="/home/dcarver/temp/test/plugin">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xsl.core" destDir="/home/dcarver/temp/test/plugin">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xsl.ui" destDir="/home/dcarver/temp/test/plugin">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xsl.doc" destDir="${pluginDestination}">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />

<buildPlugin packageAsJar="yes" workspace="${workspace}" projectname="org.eclipse.wst.xsl.saxon" destDir="${pluginDestination}">
<targetPlatform refid="eclipse-3.5"/>
<eclipseLibraryCompiler />



That’s it. Ant4Eclipse does allow for you to build based off of features, which I do not need at this time. Features are good for Products and Integration builds, but most of the time you are most concerned about getting the plugins compiled and tested. The Ant4Eclipse developers are aware of a few bugs, but the above shows a way for a developer to setup a local build using Ant4Eclipse.

Most important for me, it meets my needs for not having to launch Eclipse headless just to compile and jar eclipse plugins. The build itself is now not dependent on the Eclipse IDE to be running. An integrated eclipse with the plugins will still be needed to do testing so it can run the Plugin Tests, but that should be a matter of assembling the appropriate eclipse instance, something Custom Eclipse Builder (another sourceforge gem) can do easily.

Making the Build Continuous:

A side note here is that this same build is running on a local copy of Luntbuild. Luntbuild will check every 10 minutes to see if there are any new changes in any of the XSL Tools plugin projects in CVS. If so, it does an incremental check out and launches the build. The plan is to add the necessary unit tests for XSL Tools and run those after the compilation steps have been completed. This will then meet the last remaining requirement for a continuous integration build.

This entry was posted in agile, eclipse, release engineering. Bookmark the permalink.

2 Responses to >How to Build XSL Tools with Ant4Eclipse

  1. nickb says:

    >While I appreciate the simplicity of the <buildPlugin/> tasks, doesn't this duplicate what PDE already does when you give it a plugin or feature and ask it to build?<ant antfile="${genericTargets}" target="${target}"><property name="type" value="feature" /><property name="id" value="org.eclipse.foo.feature" /></ant>Does Ant4Eclipse handle feature and plugin nesting, or do you have to explicitly state everything you want to build?

  2. David Carver says:

    >The feature is supposed to work the same way and same dependency handling as the PDE feature task. I have not tried it and suspect i has bugs still.The buildPlugin task it self if using the eclipseCompiler task with it, will resolve all of the dependencies and imports specified in the Manifest file. It however will not currently go and compile those that aren’t compiled.I still think that Feature compilations are good for integrated builds, where the buildPlugin task is good for quick simple compiles where you may not necessarily have or want a feature to be created. It depends on what you are trying to accomplish. I could probably accomplish everything with one feature compilation.Next public version of Ant4Eclipse is supposed to support all of the compilation options that PDE provides.The complete compilation and build of XSL Tools jars takes less than a minute with Ant4Eclipse and less memory as it doesn’t launch or incure the eclipse startup time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s