As of now, the right way to build Eclipse plugins is to use the releng code or Buckminster.
It all comes down to an ant task that calls a JDT batch compiler (copied from the scripts of SWTBot):
<javac destdir="${temp.folder}/@dot.bin" failonerror="${javacFailOnError}" verbose="${javacVerbose}" debug="${javacDebugInfo}"
includeAntRuntime="no" bootclasspath="${bundleBootClasspath}"
source="${bundleJavacSource}" target="${bundleJavacTarget}">
<compilerarg line="${compilerArg}" compiler="${build.compiler}"/>
<classpath refid="@dot.classpath" />
<src path="src/"/>
<compilerarg value="@${basedir}/javaCompiler...args" compiler="org.eclipse.jdt.core.JDTCompilerAdapter"/>
<compilerarg line="-log '${temp.folder}/@dot.bin${logExtension}'" compiler="org.eclipse.jdt.core.JDTCompilerAdapter"/>
</javac>
This code is pretty heavy because you have to specify the classpath yourself (the @dot.classpath in there).
I have watched Buildr since its inception. I had made the wish to hack it in a way that I could build our plugins with it.
Essentially, what’s cool with Buildr is that it does what you want it to do, not more. It is written in a minimal way, so you can script and chain tasks. Think of it as make for Java.
Ketan came up to the Buildr user list some time ago with the same idea. He is maintaining SWTBot and he already hacked Buildr to make it behave for plugins.
Together, we are opening a new project Buildr4eclipse, that will take place on Google Code and Github.
We are going to provide an extension to Buildr to make it possible to build Eclipse plugins, first by plugging the JDT compiler in, then by making it even easier by using the dependencies declared in the manifest directly.
We welcome feedback and your help towards that goal.
This work takes place as SOA Tools is working on its build system to make it more adaptable and suited to our brand new sub-projects.