The basic file structure of an Bioclipse manager looks like:

net.bioclipse.foo/
|--META-INF
|   |--MANIFEST.MF
|   `-- spring
|       `-- context.xml
|-- plugin.xml
|-- .classpath
|-- .project
|-- build.properties
`-- src
    `-- net
        `-- bioclipse
            `-- foo
                |-- Activator.java
                `-- business
                    |-- FooManager.java
                    |-- FooManagerFactory.java
                    |-- IFooManager.java
                    |-- IJavaFooManager.java
                    `-- IJavaScriptFooManager.java

That is twelve files which need to be just right. I used to copy/paste from an earlier (simple) manager.

But we know and understand that setting up this framework is even more challenging if you have not done this at least 10 times before. So, today we implemented a New Wizard (source available from this Git repository: bioclipse.sdk).

It just asks you a project name:

and a few other settings:

Installing the Bioclipse SDK

Installing this new plugin is fairly easy, and we have set up an Update Site at http://pele.farmbio.uu.se/sdk/. Just add this as Update site in Eclipse 3.4.x (which is still required for Bioclipse2). It depends on the JDT and PDE, which you will likely already have installed being part of the default Eclipse RCP release.

Go to the Software Updates in the Help menu:

and pick Add Site…. Enter the aforementioned update site as shown here:

Then, select the Bioclipse plugin:

After you hit Install and Eclipse install the fews tens of kBs of the plugin, the plugin should show up in your installation, like it did in mine:

Implementation Details

Writing the plugin was a challenge to me, and I am happy we were doing this in a hackaton. The Bioclipse-QSAR project already had a New Project wizard, but not for a new Plug-in Project. Some things are just slightly different then. For example, it turned out that creating a .classpath cannot be done in the regular way (it never showed up), and I had to dig up some internal code of the PDE. Actually, our current implementation is still using a few internal classes because of this:

IClasspathEntry[] entries = new IClasspathEntry[3];
String executionEnvironment = null;
ClasspathComputer.setComplianceOptions(
  project,
  ExecutionEnvironmentAnalyzer.getCompliance(executionEnvironment)
);
entries[0] = ClasspathComputer.createJREEntry(executionEnvironment);
entries[1] = ClasspathComputer.createContainerEntry();
IPath path = project.getProject().getFullPath().append("src/");
entries[2] = JavaCore.newSourceEntry(path);

Ideas are most welcome on how to clean up this code, and not make it use internal, non-exported classes. For the Java source files and even the MANIFEST.MF we are using templates, though I have seen this file being created programmatically too.

I’m sure we’ll run in some needed plumbing here and there, but that’s what update sites are for, not? Release soon, release often is an Open Source concept that works well in the Eclipse world.

add the line: -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner

This is the problem I was trying to solve: I’m running 64bit Ubuntu Jaunty with Eclipse 3.4.2 for Bioclipse development. The answer above is the correct answer. So, I added the line. To the $HOME/eclipse.ini and to the eclipse command line to start the program. But I still good not run Bioclipse plugin unit tests; I kept getting that stupid error:

org.eclipse.swt.SWTError: XPCOM error -2147467262
at org.eclipse.swt.browser.Mozilla.error(Mozilla.java :1638)
at org.eclipse.swt.browser.Mozilla.setText(Mozilla.ja va:1861)

In retrospect, I was sort of asking the wrong question. I should have asked myself not why I got that XPCOM error even though I was using the solution, but why running the unit tests was not affected by that solution. Realizing that, it became so obvious: the plugin unit testing was using a clean environment, not based on the Eclipse environment I was working in; therefore, adding that line to my Eclipse environment did not help. Instead, I only had to that line to the Run Configuration of my plugin unit tests too:

Surely, there are aspects to this which helped me overlook this solution. For example, I had installed Eclipse freshly yesterday, and then the it worked fine. Only after installing some EMF and GEF features, it stopped working again. Bitten by the correlation/causation pattern :(

I have been trying to figure out which Eclipse 3.4 feature I must install from the update site to get the org.eclipse.zest plugin in my environment.

I installed the Zest feature (which I am going to use to visualize an RDF network ), but my workspace still complained that I did not have the plugin.

Maybe I should rerun Set Target Platform for our product, but I and others in the Bioclipse development community have been wondering how we can know what feature to install via the Software Updates… to get a particular plugin on your machine?

Looking forward to hearing from you,

Kind regards,

Egon

Anyway, the key thing which ONS and CDK and Jmol share, is that they use an Open Notebook. Not every Open Source or Open Data project does. Actually, many scientific Open Source are not open Projects! They are more like the Cathedral than the wished-for Bazaar (see The Cathedral and the Bazaar). So, Open Source (science) projects are certainly not ONS projects by default!

Now, the CDK actually is ONS, it is a Bazaar. The notebooks we use include:

• open project via mailing lists
• open methods/results via subversion
• informal reporting via blogs (e.g. Rajarshi, Christoph, Thomas, mine)
• informal reporting via CDK News

What more would you wish for? That’s not a rhetorical question. Remember that every reader of this blog is in my advisory board !

Unfortunately, I do not create work at a workbench myself, so I do not produce new knowledge myself, other than extracted from existing data. That’s really a shame, and I really do hope that Jean-Claude or Cameron will send me a box to measure solubilities (see here, here, and here, here for first data exploration), even though I cannot participate in the challenge. (hint, hint :)

From Cathedral to Bazaar in Life Sciences

One Cathedral we ran into with Bioclipse was BioCatalogue, which will serve as website where people can annotate and categorize (web) services. While the project has been around for a while, the website was rather uninformative. Fortunately, the projects is going to open up, and be more Bazaar-like. For example, they now started a wiki and a mailing list. I hope these efforts will continue, so that I can contribute from my point of view!

The EMBRACE Registry is a project with similar goals and a rather nice outcome (which I learned about on Monday ). It is actually anticipate to be replaced by or merge with BioCatalogue. So, all data I entered, cheminformatics workflows (look, no ‘o’ ), will later be available from BioCatalogue too. That is already my first contribution to BioCatalogue. One enormously interesting feature of the Registry, is that is allows uploading of code to test the service. This will mean the Registry will not only poll if the service is still online (by checking the WSDL file), it will also test if the service behaves properly. Now, immediate thoughts are mashups with MyExperiment. Each WSDL entry in the Registry points to MyExperiment workflows that use them, and the workflow page would indicate the status of all used WDSL services. This integration was already anticipated long before I thought about it, as the involved Cathedrals were nicely located in the same floor in Manchester.

Below is a screenshot from the EMBRACE Registry for the ChemSpider WDSL entry for a workspace I uploaded about a year ago to MyExperiment:

BTW, ChemSpider has an Advisory Board of which I am member, but it is also a classical (and intentional) Cathedral project. We do share common interests though, which makes us collaborate.

Why Important?

One recurrent theme in Open Source is given enough eyeballs, all bugs are shallow. This surely applies to science as well. The difference between the two is that in current science the eyes only inspect with a delay of at least 6 months. Current practice is that research is finished (delay), and when decided publishable written up a paper (delay, and loosing valuable information in the process, as you can read in my blog all the time), and published (even more delay). ONS changes that, and so do Bazaar-like open source projects, such as the CDK, Jmol and Bioclipse. They bugs are present, whether we like it or not, not just in source code, but in science too. Theories get overthrown, but why should we like the long delays current scientific good practice? Hate it! Work around it. Use the Bazaar. Use ONS!

Now, ONS actually needs Open Source, allowing them to deal effectively with the data they produce; to allow extraction of new scientific knowledge from the measurements. If Rajarshi and Pierre would not have made their efforts, other could not easily join in, leading to those much hated delays. Bugs should be shallow, and openness allows us to make those bugs visible. We can prove that there is a bug, without having to reproduce data ourselves, leading to those nasty delays again. Just copy the data, compare it to your own, do your analysis.

One recent project in open source chemistry dealing with making bugs visible, is the web page set up by Andreas Tille for the DebiChem project. His page summarizes the bugs listed for the chemistry in Debian (which includes the Blue Obelisk projects Avogadro, BODR, CDK, Chemical MIME Data, Kalzium and OpenBabel):

This data analysis helps the projects being analyzed.

Packaging

This brings me to a last topic, for this blog: packaging using Open Standards. In order to allow those eyeballs to spot bugs, it is of the utmost importance to package your results in Open Standards, and not just one, but likely many. For Open Source projects this ultimately means Distribution Packages (deb or rpm). If that goal has been achieved, you know your results can be read by anyone. Software should be installable (make, ant, cmake, etc), and Data should be readable (no PDF, but RDF, XML, JSON, or whatever standard). Preferably not Excel, as this is too free format (as Rajarshi also indicated), but with some added conventions it may do well. Blue Obelisk project are generally doing well in terms of packaging.

For the CDK, which already is reasonably well packaged, I am currently working on Eclipse and Maven2 packages. The former is already being used by Bioclipse, while the second aims at Jumbo (which has just seen a new release. Jim, I’m happy to see the CMLDOM/Jumbo split!), CDK-Taverna, and possibly a third (Paula, what for do you plan to use it?). The POM export is not fully working yet, but with four research sites involved in this Open Project, I’m sure we’ll work it out.

The bottom line is, scientific progress would benefit so much from a Bazaar approach. And the key thing is not collaboration; that’s something you can do in a Cathedral-like fashion too. No, the key thing is to be Open and allow anyone, even your worst nightmare, to comment on what you do. Let him prove you wrong, openly, that is.

OK, there it is. My open notebook entry for this week. Now you know what I have been up to this week.

dimethylether = cdk.fromSMILES( "COC" );
cdk.addExplicitHydrogens( dimethylether );
cdk.generate3dCoordinates( dimethylether );

// save as CML
cdk.saveCML( dimethylether, "/Virtual/dimethylether.cml" );
ui.open( "/Virtual/dimethylether.cml" ); // this should open a JmolEditor

jmol.minimize();

You can see four of my favorite cheminformatics tools integrated: CDK is used to convert a SMILES into connection table with add explicit hydrogens, and to create initial 3D coordinates (with the code from Christian Hoppe, and thanx to Stefan for fixing that code in the CDK 1.1.x branch!). Then, CMLDOM is used to create and save a CML document, which is then opened into a Jmol editor in Bioclipse.

A variation of this script is visible in the following screenshot:

This and other Bioclipse2 scripts I will post in Gist, a sort of pastebin supporting version history, and I’ll tag them with bioclipse gist on delicious, so that you can always browse them, comment on them, or add your own gists at http://delicious.com/tag/bioclipse+gist.

• GitToDo support for Freemind
• Git mirror for the CDK
• CDK development with branches using Git
• Offline CDK development using git-svn

One concern expressed by people was the lack of integration with IDEs. Now, an Eclipse plugin seems well on its way:

With a experimental update site (http://www.jgit.org/update-site), the plugin is just an Eclipse reboot away.

Now, the plugin is still in its early stages and many open feature requests, but fortunately the bug tracker can easy be integrated with Mylyn, and is still actively developed.

Cheers to Shawn and Robin for their work!

However, SourceForge, our bug tracker, integrates, but to too limited functionality. Bugzilla, though, has excellent integration. And curious about what that would look like, I installed Bugzilla on an Ubuntu system. Which failed. Due to a bug know for two years already! Anyway, two tweaks to the system got it working!

1. Work around the password in the postinstall script (see here)
2. Set up a /bugs/ link (see here)

This is Bugzilla as viewed in Mylyn:

(The bug content is derived from Ubuntu bug #1.)

Just open the java class in your Package Explorer, right click on the JUnit method you want to run, then pick Run As or Debug As, and then JUnit test.