Lunar Ocean Y’a pas anguille sous roche, mais probablement baleine sous gravillon…

Dear committer, prepare your jFace-foo !

We have a case where we have a CheckBoxTreeViewer that represents a list of elements.

The list in itself is informative. The user is going to be very interested into what is selected, and what isn’t.

It’s certain that at some point he will expand the tree to look at some nodes, come back, etc.

Right now, you cannot disable the checkboxes of a CheckBoxTreeViewer without disabling the whole tree.
So that means that your users cannot check checkboxes (that was the intent), but they also cannot expand the tree.

What if you’d like to disable some checkboxes only ? That’s unsupported too.

Unfortunately, there is no solution for this problem so far. I filed 259092 earlier today to investigate the issue, and it seems you can try to add a listener to revert the check event when the user clicks on checkboxes. Users would still see the items as enabled though, and given the complexity of the interface, adding a tooltip, a new decoration is just going to be confusing.

If you have a spare vote to cast for this bug, a comment, and idea, and ideally a patch, let’s talk about it on the bug!

Somehow I had the feeling that I was in control when it came to specifying the browser I wanted to open.

Apparently, it’s true for external browsers. For internal browsers, ie those that show in a view or an editor in Eclipse, not so much.

What happens is that the information get lost. You specify the browser type when you do the call to open the browser:

PlatformUI.getWorkbench().getBrowserSupport().createBrowser(SWT.MOZILLA, ...);

But this is simply ignored by the internal editor. Not for too long though, since I attached a patch to 259171 fixes the problem.

Your feedback on this is welcome, of course please feel free to comment on the bug rather than here.

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.

Would you like to be able to be hosted on git at eclipse.org ?
Then please vote for this bug.

If you are interested into tooling support, Egit should be your deal. They are currently building an informal proposal to join Eclipse. How about having the git tooling project hosted on git ?

Thanks to rcjsuen, ketan and ijuma for the insightful IRC chat.