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.
You may also want to look at Tycho. http://blogs.sonatype.com/people/?p=945
There is a huge gaping hole in the community for something that will build update sites headlessly. We’ve spend more than 3 developer-months getting something that works based on PDE Build, but it is hacked together and still does not handle some things well. If you could include Update Site building in your scope, that would be a great benefit to the community.
Also, running plugin tests (JUnit) seems to be a common need; PDE Build sort-of supports it, but not for JUnit4, which is simply ridiculous if you ask me. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=153429
PDE Build is the right way and should always be preferred because it is in its mandate to support building all the runtime artifacts of eclipse (features, plugins, products, etc.). The releng script is just a layering over PDE that takes care of the complete SDK build and Buckminster also eventually calls PDE / PDE Build.
Consequently recommending people to use other technologies is fine. However potential users have to be made aware that by doing this they are buying out of the evolutions of the build technology that matches the Runtime environment (for example support for Execution Environment, or p2 metadata generation integration, …).
Excited to see you are taking a go at this, making a complicated eclipse build happen with buildr could be a great way to increase the consumability of Eclipse projects source code
Eric, would you like to join the effort ?